質問: systemdサービスのstdout / stderrを表示する カスタムアプリケーション用の簡単なsystemdサービスファイルを作成しました。手動で実行するとアプリケーションは正常に動作しますが、systemdで実行するとcpuが最大になります。問題のある場所を追跡しようとしていますが、出力の場所(または出力をどこかに配置するようにsystemdを構成する方法)がわかりません。これが私のサービスファイルです:[unit] description=syncs files with a server when they change wants=network.target after=network.target [service] execstart=/usr/local/bin/filesync-client --port 2500 workingdirectory=/usr/local/lib/node_modules/filesync-client restart=always [install] wantedby=multi-user.target アプリケーション全体で、stdoutとstderrに出力します。デーモンの出力を読み取るにはどうすればよいですか?編集:man systemd.execオプションが記載されているstandardoutput=を見つけましたが、その使用方法がわかりません。 man page から: standardoutput= 実行されたプロセスのファイル記述子1(stdout)の接続先を制御します。 inherit、null、tty、syslog、kmsg、-のいずれかを取りますkmsg + console、syslog + consoleまたはsocket。 inheritに設定すると、標準入力のファイル記述子が標準出力用に複製されます。 nullに設定した場合、標準出力は/dev/nullに接続されます。つまり、そこに書き込まれたすべてが失われます。 ttyに設定すると、標準出力はttyに接続されます(ttypath=を介して構成されます。以下を参照)。 ttyが出力に使用される場合、実行されたプロセスのみが端末の制御プロセスになることはなく、失敗したり、他のプロセスが端末を解放するのを待ったりすることもありません。 syslog標準出力をsyslog(3)システムロガーに接続します。 kmsgは、dmesg(1)を介してアクセス可能なカーネルログバッファーに接続します。 syslog + consoleおよびkmsg + consoleは同様に機能しますが、出力をシステムコンソールにもコピーします。 socketソケットのアクティブ化から標準出力をソケットに接続します。セマンティクスは、standardinput=のそれぞれのオプションに似ています。この設定はデフォルトで継承されます。 これが私の唯一の選択肢ということですか?たとえば、出力を/dev/shmなどに入れたいと思います。 unixドメインソケットを使用して単純なリスナーを作成できると思いますが、これは少し不要なようです。これはデバッグに必要なだけで、ほとんどのログを削除して、出力をsyslogに変更します。
回答: 更新mikemaccanaが指摘しているように、 systemdジャーナル は現在、ほとんどのディストリビューションの標準的なロギングデバイスです。 systemdユニットのstdoutおよびstderrを表示するには、 journalctlコマンドを使用します。 sudo journalctl -u [unit] 元の回答デフォルトでは、systemdユニットのstdoutおよびstderrがsyslogに送信されます。完全なsystemdを使用している場合、これはjournalctlからアクセスできます。 fedoraでは/var/log/messagesしかし、syslogはルールが言うところにそれを置きます。投稿の日付が原因で、systemdにさらされているほとんどの人がfedoraを経由していると想定すると、おそらくここで説明されているバグに見舞われました: https://bugzilla.redhat.com/show_bug.cgi?id = 754938 すべてがどのように機能するかについても適切に説明されています=)(これは、エラーメッセージがログに記録されない原因となったselinux-policyのバグであり、selinux-policy-3.10.0-58.fc16)