LinuxのUNIXドメインソケットパスの先頭にある@記号は何を示していますか？

実行したとき、netstat --protocol unixまたはlsof -UいくつかのUNIXソケットパスの前に@記号が付いていることがわかります（例：@ / tmp / dbus-qj8V39Yrpa）。実行するls -l /tmpと、そこにdbus-qj8V39Yrpaという名前のファイルが表示されません。

問題は、先頭に付加された@記号が何を意味するかということです。2番目の関連する質問は、ファイルシステム上のunixソケットファイル（@ / tmp / dbus-qj8V39Yrpa）を実際にどこで見つけることができますか？

は@おそらくabstract namespace、ファイルシステム内のファイルに属さないソケットが保持されていることを示しています。

Michael KerriskによるThe Linux Programming Interfaceからの引用：

57.6 Linuxの抽象ソケット名前空間

いわゆる抽象ネームスペースはLinux固有の機能であり、ファイルシステムで作成された名前なしにUNIXドメインソケットを名前にバインドできます。これには、いくつかの潜在的な利点があります。

• ファイルシステム内の既存の名前と衝突する可能性について心配する必要はありません。
• ソケットの使用が終了したら、ソケットのパス名をリンク解除する必要はありません。抽象名は、ソケットが閉じられると自動的に削除されます。
• ソケットのファイルシステムパス名を作成する必要はありません。これは、chroot環境、またはファイルシステムへの書き込みアクセス権がない場合に便利です。

抽象バインディングを作成するには、sun_pathフィールドの最初のバイトをヌルバイト（\ 0）として指定します 。[...]

null byteそのようなタイプのソケットを示すために先頭を表示するのは難しいかもしれません@。

ごとに man 7 unix

• abstract：抽象ソケットアドレスは、sun_path [0]がヌルバイト（\0）であるという事実によって区別されます。sun_pathの残り​​のすべてのバイトは、ソケットの「名前」を定義します。（名前のヌルバイトには特別な意味はありません。）名前には、ファイルシステムのパス名との接続はありません。この名前空間のソケットのアドレスは、sun_pathの残り​​のバイトによって指定されます。getsockname（2）、getpeername（2）、およびaccept（2）によって抽象ソケットのアドレスが返される場合、その長さはsizeof（struct sockaddr_un）であり、sun_pathには抽象名が含まれます。抽象ソケット名前空間は、移植性のないLinux拡張機能です。

これらは「抽象的」のように見えるため、ファイルシステム上に実際のパスは存在しません