Der @ zeigt wahrscheinlich einen Socket an, der in einem abstract namespace gehalten wird die zu keiner Datei im Dateisystem gehört.
Zitat aus The Linux Programming Interface von Michael Kerrisk:
57.6 Der abstrakte Linux-Socket-Namespace
Der sogenannte Abstract Namespace ist eine Linux-spezifische Funktion, die es uns ermöglicht, einen UNIX-Domain-Socket an einen Namen zu binden, ohne dass dieser Name im Dateisystem erstellt wird. Dies bietet einige potenzielle Vorteile:
- Wir müssen uns keine Gedanken über mögliche Kollisionen mit bestehenden Namen im Dateisystem machen.
- Es ist nicht notwendig, den Pfadnamen des Sockets aufzuheben, wenn wir mit der Verwendung des Sockets fertig sind. Der abstrakte Name wird automatisch entfernt, wenn der Socket geschlossen wird.
- Wir müssen keinen Dateisystem-Pfadnamen für den Socket erstellen. Dies kann in einer Chroot-Umgebung nützlich sein oder wenn wir keinen Schreibzugriff auf ein Dateisystem haben.
Um eine abstrakte Bindung zu erstellen, geben wir das erste Byte des sun_path an Feld als Nullbyte (\0).[...]
Anzeige einer vorangestellten null byte Einen solchen Socket-Typ zu bezeichnen, kann schwierig sein, daher ist dies möglicherweise der Grund für die vorangestellte @ Schild.
Gemäß man 7 unix
- abstract:Eine abstrakte Socket-Adresse zeichnet sich dadurch aus, dass sun_path[0] ein Null-Byte ist (
\0). Alle verbleibenden Bytes in sun_path definieren den "Namen" des Sockets. (Nullbytes im Namen haben keine besondere Bedeutung.) Der Name hat nichts mit Dateisystem-Pfadnamen zu tun. Die Adresse des Sockets in diesem Namensraum wird durch die restlichen Bytes in sun_path angegeben. Wenn die Adresse eines abstrakten Sockets von getsockname(2), getpeername(2) und accept(2) zurückgegeben wird, ist seine Länge sizeof(struct sockaddr_un), und sun_path enthält den abstrakten Namen. Der abstrakte Socket-Namespace ist eine nicht-portable Linux-Erweiterung.
Sieht so aus, als wären diese 'abstrakt' - also ist kein echter Pfad im Dateisystem vorhanden