回避策
他のユーザーと同様に、私はこの悩みに悩まされていますが、半満足の回避策を見つけました：
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コマンドを使用して、コンピューター名のリセットを再試行します。
これらのいずれも効果がないことがわかった場合、報告されている他の解決策がいくつかあります。
- ローカルネットワークへの接続が1つだけであることを確認します
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)が、ネットワーク上で同じホスト名が見つかったときに番号付きのサフィックスを追加しようとするためです。ではALL私のテストの、私が選択したホスト名がいるNEVERネットワーク上の前に使用された、さらにいた絶対にうまくとして任意のBluetoothデバイスのために使用されました。
この動作の「トリガー」の真の原因は不明であり、未検証です。つまり、オンラインでのすべての調査とテストを通じて、明らかに名前が使用されていないことと、使用されたことがないMac OSが名前をすでに使用していると判断する理由を明確に判断できませんでした。
私の理論では、何らかの形で（Linuxユーザー、またはWindowsユーザーへのネットワーキング）とmDNSも呼ばれていることは、部分的に非難されるかもしれないということです。どういうわけか、MacbookまたはAppleデバイスの以前のホスト名は、またはMacbookまたはAppleデバイスによって検出および保存された何らかの形式のテーブル+ホスト名情報のどこかに保持されます。これはある種の競合状態である可能性があります。どういうわけか、エントリは重複していると見なされ、Mac OSサフィックスの名前変更動作をトリガーします。BonjourAvahiZero-confmDNSARP
Appleが提供するDNS Service Discoveryユーティリティを使用すると、ホスト名のサフィックスの番号が表示されますdns-sd。
たとえば、hostnameを使用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デバッグツールにアクセスせずに実際に何が起こっているのかを見つけて観察することが難しいため、未確認です。、、、および他のMac OSサービスとの相互作用mdnsd、またはネットワーク上の他のAvahiデーモンmDNSResponderとの相互作用は、mDNSResponderHelper十分に文書化されておらず、容易に観察できません。ネットワークディスカバリーのいくつかのフォームの現在の状態を見ることができますdns-sd、arp -aまたは多分arp -a -n。このホスト名情報が保存される可能性のある他の理論または潜在的な場所は次のとおりです。
- OSによってどこかで保持されたBluetoothデバイス名
smbd（/System/Library/LaunchDaemons/com.apple.smbd.plist）によってネットワークから定期的にキャッシュされるSMB（Windowsファイル共有）情報- ネットワークからキャッシュされたAFP共有情報（おそらく
smbd？）
mDNS/ Avahiリフレクター（またはルーターまたは他のデバイスによるネットワーク上のBonjour / zero-confパケットの他のタイプの再ブロードキャスト）
mDNSResponderまたはmdnsd（/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist）でキャッシュできます
ソリューション（プレースホルダー）
2017年10月6日の時点で、この問題の再発を防ぐためのAppleからの完全な解決策や救済策はまだありません。この問題についてAppleにバグレポートを提出することをお勧めします。Appleカスタマーサポートに問い合わせることもできます。
この厄介な問題について騒ぐ人が多いほど、Apple Product Managerの優先順位が上がり、エンジニアが修正できるようになります。
デバッグ/今後の調査ライン
このMacRumorsフォーラムディスカッションには、いくつかの有用な情報がWake for Wi-Fi Network Accessあり、デバイスWake / Sleepがこの問題と関係があるという理論を追加しています。提示されている他の理論は、複数のネットワークアダプター（例：WiFi + Thunderbolt Ethernet）、802.11 b/g/n（2.4GHz）や802.11 a/ac（5GHz）などの複数の帯域でアドバタイズされた複数のアクセスポイントを持つルーターの使用に関するものです。これらの組み合わせはあり Appleデバイスの「ゴースト」バージョンは、名前変更動作をトリガー、何とか一時的にネットワーク上に表示させます。
トリガーされるこの名前変更動作に関連して表示される有用なログ行はありませんでした/var/log/system.log。おそらくmDNSResponder、より高いログレベルに設定できます。
- エラー-エラーメッセージ
- 警告-クライアントが開始した操作
- 通知-スリーププロキシ操作
- 情報-情報メッセージ
おそらく存在しないファイルを介してこれらのデバッグレベルを設定する方法/Library/Preferences/com.apple.mDNSResponder.plistは明確ではありませんでした。使用する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