Soluzione
Come altri utenti, sono afflitto da questo fastidio, ma ho trovato una soluzione semi-soddisfacente:
my_hostname='your-hostname-here'; for key in LocalHostName ComputerName HostName ; do sudo scutil --set $key $my_hostname; done
Dopo aver eseguito questo comando, puoi verificare che tutti i posti in cui memorizzano il nome host siano gli stessi con questo one-liner:
for key in LocalHostName ComputerName HostName ; do sudo scutil --get $key; done
Se il Macbook continua a rinominare immediatamente ComputerNamecon un suffisso, potresti riuscire a fermarlo spegnendolo Wake for Network Access.
System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked
Una volta spento, rinominare la macchina utilizzando i comandi sopra per terminare. Puoi anche provare a forzare ComputerNameindietro usando la System Preferences→Sharing→Computer Namepreferenza del campo di testo.
Se questo non ti è stato d'aiuto, prova a svuotare la 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
Dopo aver svuotato la cache mDNS, riprovare a rinominare il computer utilizzando i comandi sopra.
Se il problema persiste , prova a eliminare il mDNSResponderservizio:
sudo killall -HUP mDNSResponder
Quindi, riprovare per ripristinare il nome del computer utilizzando i scutilcomandi sopra .
Se scopri che nulla di tutto ciò sta andando bene, ci sono alcune altre soluzioni segnalate che includono:
- Assicurarsi di disporre di una sola connessione alla rete locale
Spegni e riaccendi 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
Arrestare e ripristinare TUTTO l'hardware di rete
Discussione del problema
Nella mia esperienza, impostare il nome host in questo modo o attraverso lo standard System Preferences→Sharing→Computer Namedura solo un breve periodo di tempo. Questo di solito è <24 ore, ma a volte ComputerNameanche le modifiche pari immediatamente per avere un numero suffisso tra parentesi (N). Ho osservato che questo numero è stato impostato immediatamente su (4)o (5)recentemente dopo aver usato i scutil --setcomandi sopra.
La causa di questo comportamento è dovuta al codice demone in esecuzione su Mac OS che tenta di aggiungere un suffisso numerato (N)ogni volta che viene trovato lo stesso nome host sulla rete. In TUTTI i miei test, i nomi host che ho scelto non sono mai stati utilizzati in precedenza sulla rete e inoltre non sono mai stati utilizzati per nessun dispositivo Bluetooth.
La vera causa del "trigger" di questo comportamento è sconosciuta e non verificata. Vale a dire: attraverso tutte le mie ricerche e test online non sono stato in grado di determinare definitivamente perché Mac OS decida che il nome sia già in uso quando chiaramente NON lo è e non lo è mai stato.
La mia teoria è che in qualche modo mDNSnoto anche come Bonjour( Avahiper utenti Linux o Zero-confNetworking per utenti Windows) potrebbe essere in parte responsabile. In qualche modo, il precedente nome host del Macbook o del dispositivo Apple viene persistito da qualche parte nel mDNS, o forse qualche forma di ARPtabella + informazioni sul nome host che viene scoperto e memorizzato dal Macbook o dal dispositivo Apple. Questo potrebbe essere una specie di condizione di razza. In qualche modo la voce è vista come duplicata e attiva il comportamento di ridenominazione del suffisso Mac OS.
Il numero di nomi host con suffisso è visibile quando si utilizza l' utilità di individuazione del servizio DNS fornita da Apple dns-sd:
Ad esempio, utilizzando il nome host my-mbp-hostname, potrebbe apparire come le seguenti voci
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...]
La teoria della vera causa non è confermata in quanto è difficile trovare e osservare ciò che sta realmente accadendo senza accesso allo stato interno del Mac OS e agli strumenti di debug di Apple OS di basso livello. Le interazioni tra mdnsd, mDNSRespondere mDNSResponderHelpercon altri servizi Mac OS o anche con altri demoni Avahi sulla rete non sono ben documentate o facilmente osservabili. Lo stato corrente di alcune forme di rilevamento della rete può essere visualizzato attraverso dns-sde arp -ao forse arp -a -n. Altre teorie o potenziali luoghi in cui è possibile memorizzare queste informazioni sul nome host potrebbero essere:
- I nomi dei dispositivi Bluetooth persistono dal sistema operativo da qualche parte
- Informazioni SMB (condivisione file Windows) memorizzate periodicamente nella cache dalla rete da
smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
- Informazioni sulla condivisione AFP memorizzate nella cache dalla rete (presumibilmente anche da
smbd?)
mDNS/ Avahireflector (o altro tipo di ritrasmissione di pacchetti Bonjour / zero-conf sulla rete da un router o qualche altro dispositivo)?
- Potrebbe essere memorizzato nella cache da
mDNSRespondero mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)
Soluzione (segnaposto)
A partire dal 6 ottobre 2017, non esiste ancora una soluzione completa da parte di Apple o un rimedio per evitare il ripetersi di questo problema. Consiglio di presentare una segnalazione di bug con Apple che descriva questo problema. Puoi anche contattare l' assistenza clienti Apple .
Più persone fanno rumore su questo fastidioso problema, più rapidamente i Product Manager di Apple daranno la priorità in modo che gli ingegneri possano risolverlo.
Debugging / Future Linee di indagine
Questa discussione sul forum MacRumors contiene alcune informazioni utili oltre ad aggiungere una teoria secondo cui il Wake for Wi-Fi Network Accessdispositivo Wake / Sleep ha a che fare con questo problema. Altre teorie presentate hanno a che fare con l'utilizzo di più adattatori di rete (ad esempio: WiFi + Thunderbolt Ethernet), router con più Access Point pubblicizzati su più bande come su 802.11 b/g/n(2.4GHz) o 802.11 a/ac(5GHz). Queste combinazioni possono causare la visualizzazione temporanea di una versione "fantasma" del dispositivo Apple sulla rete, innescando il comportamento di ridenominazione.
Non sono state visualizzate righe di log utili in /var/log/system.logrelazione al fatto che questo comportamento di ridenominazione è stato attivato. Presumibilmente mDNSResponderpuò essere configurato per livelli di registro più elevati:
- Errore: messaggi di errore
- Avviso: operazioni avviate dal cliente
- Avviso: operazioni del proxy di sospensione
- Info - Messaggi informativi
/Library/Preferences/com.apple.mDNSResponder.plistNon è chiaro come impostare questi livelli di debug diversi da quelli che potrebbero essere tramite file inesistenti . Non avevo un esempio di configurazione da usare, quindi non ero in grado di ottenere ulteriori informazioni di registrazione da mDNSResponder.
Strumenti come Wireshark potrebbero essere utili per mostrare i mDNSpacchetti trasmessi sulla rete insieme ad altre informazioni sui pacchetti ARP potenzialmente rilevanti tra l'altro traffico.
Su Mac OS, dscacheutilpotrebbero esistere altri strumenti come visualizzare queste informazioni. Non è ben documentato o chiaro come visualizzare la cache definitiva di queste informazioni che viene utilizzata dal codice di rinomina del nome host. Quando ho testato questa utility, non ha prodotto alcun output utile tranne quando si utilizzava la modalità query per il nome host esatto (IP cancellati per la privacy):
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