タグ付けされた質問 「unix-sockets」

Unixシステムでは、パス名には通常、長さの制限はほとんどありません（Linuxでは4096文字）...ソケットファイルのパスは100文字（Linuxでは 107文字）に制限されています。 最初の質問：なぜそんなに低い制限があるのか​​？ 私はそれはいくつかのソケットが同じパスを使用して、すべてのファイルを現在の作業ディレクトリを変更し、さまざまなディレクトリに作成することによって、この制限を回避することが可能と思われることを確認しました./myfile.sockクライアントアプリケーションが正しく偶数かかわらず、期待されるサーバプロセスに接続するように見える：lsofショーのすべて同じソケットファイルパスでリッスンします。 この回避策は信頼性がありますか、それとも私は幸運でしたか？ この動作はLinux固有のものですか、またはこの回避策は他のUnixにも適用できますか？

18 filenames  socket  limit  unix-sockets 

UNIXストリームの補助データに関する多くの情報を読みましたが、すべてのドキュメントから欠落していることの1つは、部分的な読み取りがある場合に何が起こるかということです。 24バイトのバッファーに次のメッセージを受信するとします。 msg1 [20 byes] (no ancillary data) msg2 [7 bytes] (2 file descriptors) msg3 [7 bytes] (1 file descriptor) msg4 [10 bytes] (no ancillary data) msg5 [7 bytes] (5 file descriptors) recvmsgの最初の呼び出しで、msg1のすべて（およびmsg2の一部を取得しますか？OSはこれを実行しますか？）メッセージが実際にデータを処理するように言っていることを知っているとき？msg1から20バイトを解放してからrecvmsgを再度呼び出すと、msg3とmsg4を同時に配信しますか？msg3およびmsg4からの補助データは、制御メッセージ構造体で連結されますか？ これを実験的に調べるためのテストプログラムを作成することはできますが、ストリーミングコンテキストでの補助データの動作に関するドキュメントを探しています。公式なものが見つからないのは奇妙に思えます。 このテストプログラムから得た実験結果をここに追加します。 https://github.com/nrdvana/daemonproxy/blob/master/src/ancillary_test.c Linux 3.2.59、3.17.6 このrecvmsgの呼び出し中に事前の補助ペイロードを配信する必要がない限り、Linuxは補助ベアリングメッセージの一部を他のメッセージの最後に追加するようです。1つのメッセージの補助データが配信されると、次の補助データメッセージを開始するのではなく、短い読み取りを返します。したがって、上記の例では、取得する読み取りは次のとおりです。 recv1: [24 bytes] (msg1 + partial msg2 with msg2's 2 file …

18 unix-sockets 

StackOverflowには、デーモンの一般的なPIDファイルロックメカニズムに依存しない（Eduardo Fleuryから合成された）デーモンに対してより良いロックを提供するという素晴らしい回答があります。PIDロックファイルが問題を引き起こすことがある理由については、多くの良いコメントがありますので、ここではそれらを再ハッシュしません。 要するに、このソリューションはLinuxの抽象名前空間ドメインソケットに依存しています。これは、デーモンがSIGKILLされた後もファイルに依存するのではなく、名前でソケットを追跡します。この例は、プロセスが停止するとLinuxがソケットを解放するように見えることを示しています。 しかし、バインドされたプロセスがSIGKILLされたとき、Linuxが抽象ソケットで正確に何をするかを示す明確なドキュメントをLinuxで見つけることができません。誰か知っている？ 別の言い方をすると、抽象ソケットが正確に解放されて再び使用できるようになるのはいつですか？ 問題を確実に解決しない限り、PIDファイルメカニズムを抽象ソケットに置き換えたくありません。

15 socket  unix-sockets 

TCP / IPおよびUDPキャプチャはtcpdump/ dumpcapを使用して作成でき、さらなる分析のためにWiresharkに供給することができるpcap / pcapngファイルを生成します。名前付きUnixドメインソケットに同様のツールが存在しますか？（ただし、抽象ソケットで機能する一般的なソリューションもいいでしょう。） strace現状のままでは不十分であり、UnixドメインソケットI / Oをフィルタリングするのは簡単ではありません。またはを使用socatするプロキシも、既存のオープンプログラムの受動的な分析を目的としているため、適切ではありません。 Wiresharkで分析に使用できるパケットキャプチャを取得するにはどうすればよいですか？プロトコルアプリケーションの例は、X11（Xorg、私の現在のアプリケーション）およびcURL / PHP（HTTP）です。私が見たCONFIG_UNIX_DIAGのLinuxカーネルでオプションを、いくつかの使用のこれは何ですか？

13 linux  debugging  unix-sockets  pcap 

私の経験では、非特権ユーザーはxビットが設定されていないと所有していないUNIXソケットにアクセスできません。このビットは正確に何をしますか？ありがとう

11 linux  permissions  unix-sockets 

私のAndroidデバイスには、/proc/net/unix誰のコンテンツ が標準の Linuxディストリビューションのファイルに準拠していないというファイルがあります（UNIXドメインソケットを示しています）。最初の数行： Num RefCount Protocol Flags Type St Inode Path 00000000: 00000002 00000000 00000000 0002 01 5287581 /data/misc/wifi/sockets/wpa_ctrl_789-3189 00000000: 00000003 00000000 00000000 0001 03 6402 /dev/socket/qmux_radio/qmux_client_socket 297 00000000: 00000002 00000000 00010000 0001 01 7180 /dev/.secure_storage/ssd_socket 00000000: 00000002 00000000 00010000 0001 01 6424 /dev/socket/cnd 00000000: 00000002 00000000 00010000 0001 01 …

11 filesystems  android  proc  unix-sockets