Обхід
Як і інших користувачів, мене мучить ця неприємність, але я знайшов напівзадовільний спосіб вирішення:
my_hostname='your-hostname-here'; for key in LocalHostName ComputerName HostName ; do sudo scutil --set $key $my_hostname; done
Запустивши цю команду, ви можете перевірити, чи всі місця, де вони зберігають ім'я хоста, однакові з цим одноклассником:
for key in LocalHostName ComputerName HostName ; do sudo scutil --get $key; done
Якщо Macbook продовжує негайно перейменовувати ComputerNameсуфікс, можливо , ви зможете зупинити його, вимкнувши його Wake for Network Access.
System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked
Після вимкнення перейменуйте свій апарат, використовуючи команди, описані вище, щоб закінчити. Ви також можете спробувати ComputerNameповернути назад, скориставшись налаштуваннями System Preferences→Sharing→Computer Nameтекстового поля.
Якщо це не допомогло, спробуйте очистити кеш-пам'ять 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
Після промивання кеш-пам'яті mDNS, повторіть перейменування машини за допомогою команд, наведених вище.
Якщо це все-таки не вийшло, спробуйте вбити mDNSResponderслужбу:
sudo killall -HUP mDNSResponder
Потім повторіть спробу, щоб скинути ім’я комп'ютера за допомогою наведених вище scutilкоманд.
Якщо ви виявите, що жодне з цього не приносить користі, є деякі інші повідомлення, які включають:
- Переконайтеся, що у вас є лише одне підключення до локальної мережі
Вимкніть і знову ввімкніть 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
Вимкніть та скиньте ВСЕ мережеве обладнання
Обговорення проблеми
На мій досвід, встановлення імені хоста таким чином або через стандарт System Preferences→Sharing→Computer Nameтриває лише короткий проміжок часу. Зазвичай це <24 години, але іноді ComputerNameнавіть парні зміни одразу змінюються, щоб мати суфіксну кількість в дужках (N). Я помітив, що цей номер потрібно негайно встановити на (4)або (5)останнім часом після використання scutil --setкоманд вище.
Причина такої поведінки пов'язана з деяким демоновим кодом, що працює в Mac OS, який намагається додати нумерований суфікс (N)будь-коли, коли те саме ім’я хоста знайдеться в мережі. В УСІМ моїх тестуваннях імена хостів, яких я вибрав, НІКОЛИ не використовувались раніше в мережі, а також НІКОЛИ не використовувалися для будь-яких пристроїв Bluetooth.
Справжня причина «спускового механізму» такої поведінки невідома і не підтверджена. Тобто, через всі мої дослідження в Інтернеті та тестування я не зміг остаточно визначити, чому Mac OS вирішує, що це ім'я вже використовується, коли його явно НЕ і ніколи не було.
Моя теорія полягає в тому, що якимось чином mDNSтакож відомий як Bonjour( Avahiдля користувачів Linux або Zero-confМережі для користувачів Windows) може бути частково винен. Так чи інакше зберігається попереднє ім’я пристрою Macbook або Apple mDNS, або, можливо, якась форма ARPтаблиці + інформація про ім'я хоста, яка виявляється і зберігається пристроєм Macbook або Apple. Це може бути якийсь стан перегонів. Як-небудь запис вважається дублікатом і викликає поведінку суфіксів Mac OS для перейменування.
Імена хостів із суфіксами чисел видно, коли використовується утиліта DNS Service Discovery, надана Apple dns-sd:
Наприклад, використовуючи ім'я хоста my-mbp-hostname, воно може відображатися як наступні записи
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...]
Теорія справжньої причини не підтверджена, оскільки важко знайти та спостерігати за тим, що відбувається насправді без доступу до внутрішнього стану Mac OS та інструментів налагодження Apple OS низького рівня. Взаємодія між mdnsd, mDNSResponderта mDNSResponderHelperіншими службами Mac OS або навіть іншими демонами Avahi в мережі недостатньо добре зафіксована або легко спостерігається. Сучасний стан деяких форм виявлення мережі можна переглянути з допомогою dns-sdі arp -aчи можливо arp -a -n. Іншими теоріями чи потенційними місцями, де може зберігатися інформація про ім’я хоста, можуть бути:
- Імена пристроїв Bluetooth десь зберігаються в ОС
- Інформація про SMB (спільний доступ до файлів Windows) періодично кешована з мережі
smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
- Інформація про спільний доступ AFP, кешована з мережі (також, мабуть
smbd,?)
mDNS/ Avahiрефлектор (або інший тип ретрансляції пакетів Bonjour / zero-conf в мережі за допомогою маршрутизатора чи якогось іншого пристрою)?
- Може кешуватися
mDNSResponderабо mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)
Рішення (заповнювач)
Станом на 6 жовтня 2017 року досі не існує повного рішення від Apple або засобів захисту, щоб запобігти повторному виникненню цієї проблеми. Я рекомендую подати звіт про помилки в Apple, який описує цю проблему. Ви також можете звернутися в службу підтримки Apple .
Чим більше людей шумуватимуть із цієї набридливої проблеми, тим швидше менеджери продуктів Apple нададуть пріоритет, щоб інженери змогли це виправити.
Налагодження / майбутні лінії дослідження
Ця дискусія на форумі MacRumors містить корисну інформацію, а також додає теорію про те, що Wake for Wi-Fi Network Accessі пристрій Wake / Sleep має щось спільне з цим питанням. Інші представлені теорії пов'язані з використанням декількох мережевих адаптерів (наприклад, WiFi + Thunderbolt Ethernet), маршрутизаторів, які мають кілька точок доступу, розміщених у кількох діапазонах, таких як 802.11 b/g/n(2,4 ГГц) або 802.11 a/ac(5 ГГц). Ці комбінації можуть якось тимчасово відображатись у мережі версію пристрою Apple, викликаючи поведінку.
Там не було ніяких корисних ліній журналу в /var/log/system.logтому , що , здавалося , пов'язані з цим поведінка перейменуванням бути викликано. Нібито mDNSResponderможна налаштувати на більш високі рівні журналу:
- Помилка - повідомлення про помилку
- Попередження - операції, ініційовані клієнтом
- Повідомлення - Сонні операції проксі
- Інформація - Інформаційні повідомлення
Як встановити ці рівні налагодження, крім того, можливо через неіснуючий файл, /Library/Preferences/com.apple.mDNSResponder.plistбуло не ясно. У мене не було прикладу конфігурації плісту для використання, тому мені не вдалося отримати зайву інформацію про реєстрацію mDNSResponder.
Такі інструменти, як Wireshark, можуть бути корисними для показу mDNSпакетів, що транслюються в мережі разом з іншою потенційно відповідною інформацією про пакет ARP серед іншого трафіку.
У Mac OS dscacheutilможуть існувати інші інструменти, такі як перегляд цієї інформації. Недостатньо задокументовано чи зрозуміло, як переглянути остаточний кеш цієї інформації, який використовується кодом перейменування імені хоста. Коли я тестував цю утиліту, вона не дала корисного результату, за винятком випадків, коли використовувався режим запиту для точного імені хоста (IP-адреси, вичищені для конфіденційності):
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