たとえば、@記号が前にあるいくつかのUNIXソケットパスを実行または表示するnetstat --protocol unixと、lsof -U@/tmp/dbus-qj8V39Yrpa。それから走るとls -l /tmp名前が見えません。dbus-qj8V39Yrpaそこに。
問題は、前の@記号が何を意味するのかです。 2番目の関連質問は - Unixソケットファイルをどこで見つけることができますか？@/tmp/dbus-qj8V39Yrpa）ファイルシステムにありますか？
答え1
ファイルシステムのファイルに属さないソケットを示すことができます@。abstract namespace
から引用Linuxプログラミングインターフェース渡すマイケルクリーク:
57.6 Linux抽象ソケット名前空間
いわゆる抽象名前空間は、ファイルシステムに名前を生成せずにUNIXドメインソケットを名前にバインドできるLinux固有の機能です。これはいくつかの潜在的な利点を提供します。
- ファイルシステム内の既存の名前との競合の可能性について心配する必要はありません。
- 使用が終わったら、ソケットパス名を切断する必要はありません。ソケットが閉じると、抽象名は自動的に削除されます。
- ソケットのファイルシステムパス名を作成する必要はありません。これは、chroot環境またはファイルシステムへの書き込み権限がない場合に便利です。
抽象バインディングを生成するには、最初のバイトを指定します。 ソーラーパスフィールドはNULLバイト（\ 0）です。 [...]
このタイプのソケットを表すために先行を表示するのは困難な場合があるため、null byteこれが先行表記の理由である可能性があります@。
答え2
~によるとman 7 unix
- 概要：抽象ソケットアドレスの違いは、sun_path [0]がNULLバイト（
\0）であることです。 sun_path の残りのすべてのバイトはソケットの「名前」を定義します。 （名前のヌルバイトには特別な意味はありません。） 名前はファイルシステムパス名とは関係ありません。この名前空間のソケットアドレスは、sun_pathの残りのバイトとして提供されます。 getsockname(2)、getpeername(2) および accept(2) が長さ sizeof(struct sockaddr_un) の抽象ソケットのアドレスを返す場合、sun_path には抽象名が含まれます。抽象ソケット名前空間は、移植不可能なLinux拡張です。
これは「抽象的」のようです。したがって、ファイルシステムに実際のパスは存在しません。