Gambiarra
Como outros usuários, sou atormentado por esse aborrecimento, mas encontrei uma solução alternativa semi-satisfatória:
my_hostname='your-hostname-here'; for key in LocalHostName ComputerName HostName ; do sudo scutil --set $key $my_hostname; done
Após executar este comando, você pode verificar se todos os locais onde eles armazenam o nome do host são os mesmos com esta linha única:
for key in LocalHostName ComputerName HostName ; do sudo scutil --get $key; done
Se o Macbook continuar renomeando imediatamente de ComputerNamevolta com um sufixo, você poderá fazê-lo parar ao desligar Wake for Network Access.
System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked
Uma vez desligado, renomeie sua máquina usando os comandos acima para concluir. Você também pode tentar forçar a ComputerNamevolta usando a System Preferences→Sharing→Computer Namepreferência do campo de texto.
Se isso não ajudou, tente liberar o cache mDNS :
# El Capitan (10.11) and later
# check if you have dscacheutil command with: which dscacheutil
sudo dscacheutil -flushcache
# Yosemite (10.10) and ealier
# check if you have discoveryutil command with: which discoveryutil
sudo discoveryutil mdnsflushcache
sudo discoveryutil mdnsrestartquestions
sudo discoveryutil mdnsrestartregistrations
sudo discoveryutil udnsflushcache
sudo discoveryutil udnsrestartquestions
Após liberar o cache mDNS, tente renomear sua máquina usando os comandos acima.
Se isso ainda não funcionar, tente matar o mDNSResponderserviço:
sudo killall -HUP mDNSResponder
Em seguida, tente novamente para redefinir o nome do computador usando os scutilcomandos acima .
Se você achar que nada disso está sendo bom, existem outras soluções relatadas que incluem:
- Verifique se você possui apenas uma conexão com a rede local
Desligue e ligue o Bonjour
# Yosemite (10.10) (and other versions with discoveryd?)
# Check for discoveryd with: ps auxww | grep -i discoveryd
sudo killall discoveryd
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
# Mac OS versions without discoveryd
# Check for mDNSResponder with: ps auxww | grep -i mDNSResponder
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
Desligar e redefinir TODO o hardware de rede
Discussão do problema
Na minha experiência, definir o nome do host dessa maneira ou através do padrão System Preferences→Sharing→Computer Namedura apenas um curto período de tempo. Isso geralmente é <24 horas, mas às vezes o ComputerNamepar muda imediatamente para ter um número com sufixo entre parênteses (N). Observei que esse número foi definido imediatamente (4)ou (5)recentemente após o uso dos scutil --setcomandos acima.
A causa desse comportamento ocorre devido a algum código de daemon em execução no Mac OS, que tenta adicionar um sufixo numerado (N)sempre que o mesmo nome de host é encontrado na rede. Em TODOS os meus testes, os nomes de host que eu escolhi NUNCA foram usados antes na rede e NUNCA foram usados também para qualquer dispositivo Bluetooth.
A verdadeira causa do "gatilho" desse comportamento é desconhecida e não verificada. Ou seja: Através de todas as minhas pesquisas e testes on-line, não consegui determinar definitivamente por que o Mac OS decide que o nome já está sendo usado quando claramente NÃO é e nunca foi.
Minha teoria é que, de alguma forma, mDNStambém conhecido como Bonjour( Avahipara usuários de Linux ou Zero-confNetworking para usuários de Windows) pode ser parcialmente culpado. De alguma forma, o nome do host anterior do dispositivo Macbook ou Apple é mantido em algum lugar mDNS, ou talvez alguma forma de ARPinformação da tabela + nome do host é descoberta e armazenada pelo dispositivo Macbook ou Apple. Isso pode ser algum tipo de condição de corrida. De alguma forma, a entrada é vista como duplicada e aciona o comportamento de renomeação do sufixo do Mac OS.
O número de nomes de host com sufixo é visível ao usar o utilitário DNS Service Discovery fornecido pela Apple dns-sd:
Por exemplo, usando o nome do host my-mbp-hostname, ele pode aparecer como as seguintes entradas
dns-sd -Z _ssh._tcp
; To direct clients to browse a different domain, substitute that domain in place of '@'
lb._dns-sd._udp PTR @
; In the list of services below, the SRV records will typically reference dot-local Multicast DNS names.
; When transferring this zone file data to your unicast DNS server, you'll need to replace those dot-local
; names with the correct fully-qualified (unicast) domain name of the target host offering the service.
_ssh._tcp PTR my-mbp-hostname\032(5)._ssh._tcp
my-mbp-hostname\032(5)._ssh._tcp SRV 0 0 22 my-mbp-hostname.local. ; Replace with unicast FQDN of target host
my-mbp-hostname\032(5)._ssh._tcp TXT ""
[...SNIP...]
[...OTHER SSH HOSTS HERE...]
[...SNIP...]
A teoria da verdadeira causa não é confirmada, pois é difícil encontrar e observar o que realmente está acontecendo sem acesso ao estado interno do Mac OS e às ferramentas de depuração de baixo nível do Apple OS. As interações entre mdnsd, mDNSRespondere mDNSResponderHelpercom outros serviços do Mac OS ou até outros daemons da Avahi na rede não são bem documentadas ou facilmente observáveis. O estado atual de algumas formas de descoberta de rede pode ser visualizado através dns-sde arp -aou talvez arp -a -n. Outras teorias ou locais em potencial onde essas informações de nome de host podem ser armazenadas podem ser:
- Os nomes de dispositivos Bluetooth persistiram em algum lugar do SO
- Informações SMB (compartilhamento de arquivos do Windows) armazenadas em cache da rede periodicamente por
smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
- Informações de compartilhamento do AFP armazenadas em cache da rede (também presumivelmente por
smbd?)
mDNS/ Avahireflector (ou outro tipo de retransmissão de pacotes Bonjour / zero-conf na rede por um roteador ou outro dispositivo)?
- Pode ser armazenado em cache por
mDNSResponderou mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)
Solução (espaço reservado)
A partir de 6 de outubro de 2017, ainda não havia uma solução ou solução completa da Apple para impedir que esse problema ocorra novamente. Eu recomendo arquivar um relatório de bug na Apple descrevendo esse problema. Você também pode entrar em contato com o Suporte ao cliente Apple .
Quanto mais pessoas fizerem barulho sobre esse problema irritante, mais rápido os gerentes de produto da Apple priorizarão para que os engenheiros possam corrigi-lo.
Depuração / futuras linhas de investigação
Esta discussão no fórum MacRumors tem algumas informações úteis, além de adicionar uma teoria de que o Wake for Wi-Fi Network Accessdispositivo Wake / Sleep tem algo a ver com esse problema. Outras teorias apresentadas têm a ver com o uso de vários adaptadores de rede (por exemplo: WiFi + Thunderbolt Ethernet), roteadores que possuem vários pontos de acesso anunciados em várias bandas, como em 802.11 b/g/n(2,4 GHz) ou 802.11 a/ac(5 GHz). Essas combinações podem fazer com que uma versão "fantasma" do dispositivo Apple seja exibida temporariamente na rede de alguma forma, acionando o comportamento de renomeação.
Havia há linhas de registo úteis em /var/log/system.logque apareceu relacionadas com este comportamento renomeação sendo acionado. Supostamente mDNSResponderpode ser configurado para níveis mais altos de log:
- Erro - mensagens de erro
- Aviso - Operações iniciadas pelo cliente
- Aviso - Operações de proxy de suspensão
- Info - Mensagens informativas
Como definir esses níveis de depuração além de talvez por um arquivo inexistente /Library/Preferences/com.apple.mDNSResponder.plistnão estava claro. Eu não tinha um exemplo de configuração do plist para usar, então não consegui obter nenhuma informação extra de log mDNSResponder.
Ferramentas como o Wireshark podem ser úteis para mostrar mDNSpacotes sendo transmitidos na rede, juntamente com outras informações de pacotes ARP potencialmente relevantes, entre outros tráfegos.
No Mac OS, outras ferramentas, como dscacheutilpodem existir, para exibir essas informações. Não está bem documentado ou claro como visualizar o cache definitivo dessas informações, que é usado pelo código de renomeação do nome do host. Quando testei esse utilitário, ele não produziu nenhuma saída útil, exceto ao usar o modo de consulta para o nome do host exato (IPs eliminados por privacidade):
sudo dscacheutil -cachedump -entries host
Unable to get details from the cache node
sudo dscacheutil -cachedump
Unable to get details from the cache node
dscacheutil -cachedump
Unable to get details from the cache node
dscacheutil -cachedump -entries host
Unable to get details from the cache node
dscacheutil -q host -a name my-mbp-hostname.local
name: my-mbp-hostname.local
ipv6_address: fe80:4::1a:1234:abcd:ef01
ipv6_address: 2601:280:1b00:1234:567:abcd:ef01:1234
name: my-mbp-hostname.local
ip_address: 192.168.1.123