起動時にさまざまなプログラムが実行される組み込みLinuxシステムがあります。これらのプログラムのいくつかは printf() を使って stdout と stderr に書き込みます。
SSHを介して初めてシステムにログインすると、端末にこれらのすべてのメッセージが表示されることがわかります。
しかし、後で別のSSHセッションを開くと、もちろんプロセスはまだ実行中ですが、端末には何も記録されません。これはstdoutとstderrが実際にどのように機能するのか混乱しました。私は彼らがすべてのオープンターミナルに書き込むと思いましたか？
ベストアンサー1
あなたのコメントで述べたように、最初のSSHログインを使用して「シリアルデバッグインターフェイス」に接続する場合、組み込みデバイスは単にシリアルポートをコンソールデバイスとして使用するだけです。これは、ビデオディスプレイデバイスがまったくないLinuxシステムの一般的なソリューションであり、実際にはクラシックUnixコンピュータが動作する基本的な方法です。
起動時に起動メッセージがとして出力され/dev/console、起動された一部のプログラムは起動した端末デバイスから完全に切り離されずにメッセージを送信し続けます。
技術的には、アプリケーションメッセージが不要な場合はアプリケーション部分の「フルデーモンの失敗」、メッセージが役に立ち、システム管理者が起動スクリプトを作成する必要がある場合は「アプリケーションロギングの実装」です。メッセージをログファイルまたはその他の便利な宛先に送信します。残念ながら、これは比較的一般的なことです。アプリケーションメッセージは、コンソールデバイスを複雑にし、システム管理者がコンソールを使用してネットワーク接続エラーを引き起こす問題を解決することを困難にする可能性があります。
（次のセクションは、最初のSSHセッションにシリアルデバッグインターフェイスが含まれていることに言及する前に作成されました...）
標準入力、出力、およびエラーストリームは通常、1 つの端末デバイスにのみ接続されます。唯一の明白な特別なケースは、/dev/consoleこれがすべての物理コンソールデバイスから出力されるべきです...しかし、擬似TTYではありません。そして、SSH接続は常に疑似TTY（またはTTYはまったく使用されていません）を使用し、「実際の」「TTYデバイスは使用しません。
「起動時に実行されるプログラム」が実際に初めてログインするのではなく、起動時に起動される場合は興味深い謎です。
組み込みシステムが古い（BSDスタイル）擬似TTYデバイスを使用している場合、これがどのように可能かを知っているようです。 （つまり、システムにそれぞれおよび/dev/pty??という名前のデバイスノードペアがありますか、それとも/tty??などの最新のUnix98スタイルPTYデバイスがありますか？）/dev/ptmx/dev/pts/<number>
起動時に起動プロセスを管理するスクリプトまたはシステムは、すべてのサービスのstdoutとエラーを最初の疑似TTYに割り当てる可能性があります。ここで、いくつかのスタートアップロギングプロセスはロギングのためにそれをキャプチャし、それを実際のコンソールTTYデバイスに渡します。ブートプロセスが完了すると、ブートロギングプロセスが終了し、擬似TTYマスタが解放されます。ただし、一部の実行プログラムは、疑似TTY側を解放せずに出力を送信できます。
最初のSSHセッションが確立されると、sshdデーモンは接続に使用される最初の割り当てられていない疑似TTYマスターデバイスを取得しますが、BSDスタイルの擬似TTYデバイスの場合は起動時に記録されます。したがって、第１のＳＳＨセッションは、スレーブにイニシエータプログラムが接続された擬似ＴＴＹデバイスをもたらすので、これらのプログラムの出力はＳＳＨセッションに現れる。他のSSHセッションは「きれいな」疑似TTYデバイスをインポートするため、問題はありません。
最新のUnix98スタイルの擬似TTYデバイスを使用すると、PTYデバイスの新しいユーザーのそれぞれが保証された一意のPTYデバイスペアを取得するため、この種の作業はBSDスタイルPTYデバイスでのみ発生します。