私はDebian（Jessie）サーバー上でサービス（自分で書いたもの）を走らせていますが、そのサービスのログには、特定の時間に再起動したことが記録されています。セグメント違反やその他のクラッシュの兆候は見られないので、アプリケーションが何らかの理由で黙って失敗して systemd によって再起動されたか、ユーザーが を介して意図的にサービスを再起動したかによって異なりますsystemctl。
シェルの履歴にはそのようなアクティビティは表示されませんが、SSH セッションがタイムアウトした可能性があり、以前のログインの bash 履歴がディスクに書き込まれなかったため、決定的ではありませんexport HISTCONTROL=ignoreboth。その時点ではサーバーは再起動されていません。
しかし、systemd自体は、サービスがいつ実行されたかを示すログを保持するはずです。故意に再起動しました。驚いたことに、journalctlこのようなログを取得する方法に関するドキュメント (など) は見つかりませんでした。
その他の投稿（例：通常ユーザーの systemd サービスのログはどこにありますか、またなぜログがないのですか?) は、次のようなログ メッセージが表示されることを示しているようです。
Jan 15 19:28:08 qbd-x230-suse.site systemd[1]: Starting chatty.service...
Jan 15 19:28:08 qbd-x230-suse.site systemd[1]: Started chatty.service.
しかし、私のシステムではそのようなログメッセージは表示されません。
systemd サービスがいつ開始、停止、または再起動されたかを確認する方法はありますか?
編集: 人々が遭遇する典型的な問題は、journalctl非特権ユーザーとして実行することのようです。これは私の場合は当てはまりません。私はずっと非特権ユーザーとして操作してきましたroot。コメントへの返信として、実行するとgrep systemd /var/log/syslog次のメッセージが表示されます。
Jun 6 09:28:35 server systemd[22057]: Starting Paths.
Jun 6 09:28:35 server systemd[22057]: Reached target Paths.
Jun 6 09:28:35 server systemd[22057]: Starting Timers.
Jun 6 09:28:35 server systemd[22057]: Reached target Timers.
Jun 6 09:28:35 server systemd[22057]: Starting Sockets.
Jun 6 09:28:35 server systemd[22057]: Reached target Sockets.
Jun 6 09:28:35 server systemd[22057]: Starting Basic System.
Jun 6 09:28:35 server systemd[22057]: Reached target Basic System.
Jun 6 09:28:35 server systemd[22057]: Starting Default.
Jun 6 09:28:35 server systemd[22057]: Reached target Default.
Jun 6 09:28:35 server systemd[22057]: Startup finished in 59ms.
Jun 6 09:37:08 server systemd[1]: Reexecuting.
答え1
これをスクリプト化する必要がある場合は、systemctl show
コマンドの使用を検討してください。 から何かを解析しようとするよりも、スクリプトの方が便利ですstatus。たとえば、サービスが最後に開始された時刻を見つけるには、次のコマンドを使用します。
$ systemctl show systemd-journald --property=ActiveEnterTimestamp
ActiveEnterTimestamp=Wed 2017-11-08 05:55:17 UTC
利用可能なすべてのプロパティを表示する場合は、フラグを省略すると、すべてがダンプされます。
$ systemctl show <service_name>
これらのプロパティに関するドキュメントは以下にあります。ここ。
答え2
Debian のデフォルト設定では、権限のないユーザーは systemd-journald にも syslog ログにもアクセスできません。通常のユーザーとしてログインすると、journalctl から次の応答が返されます。
$ journalctl
No journal files were found.
ちょっと混乱します。
ルートとしてログインしている場合は、journalctl --unit=yourservice探している情報が表示されるはずです。systemctl restart bind9私のサーバーでは、 の後に次のメッセージが表示されますjournalctl --unit=bind9。
Jun 03 18:20:24 ns systemd[1]: Stopping BIND Domain Name Server...
Jun 03 18:20:24 ns named[27605]: received control channel command 'stop'
Jun 03 18:20:24 ns systemd[1]: Starting BIND Domain Name Server...
Jun 03 18:20:24 ns systemd[1]: Started BIND Domain Name Server.
で明示的にbind9を強制終了するとkill -9、journalctl --unit=bind9次のようになります:
Jun 03 18:46:25 ns systemd[1]: bind9.service: main process exited, code=killed, status=9/KILL
Jun 03 18:46:25 ns rndc[28028]: rndc: connect failed: 127.0.0.1#953: connection refused
Jun 03 18:46:25 ns systemd[1]: bind9.service: control process exited, code=exited status=1
Jun 03 18:46:25 ns systemd[1]: Unit bind9.service entered failed state.
Jun 03 18:46:25 ns systemd[1]: bind9.service holdoff time over, scheduling restart.
Jun 03 18:46:25 ns systemd[1]: Stopping BIND Domain Name Server...
Jun 03 18:46:25 ns systemd[1]: Starting BIND Domain Name Server...
Jun 03 18:46:25 ns systemd[1]: Started BIND Domain Name Server.
最初の行は、プロセスが強制終了されたために終了したことを示しています。
systemd-journald はすべてのログ メッセージを syslog に転送するため、これらのメッセージも で見つかるはずです/var/log/syslog。
/etc/systemd/system.confSystemd と systemd-journald には、およびで変更できるデフォルトのコンパイル済み構成があります/etc/systemd/journald.conf。
デフォルトでは、systemd-journald は の下 ( /run)にログを保存しtmpfs、再起動後に消えることを知っておくと便利です。つまり、最後の起動より古いログ メッセージを取得するには、syslog ファイルを参照する必要があります。この場合、journalctl は最後の起動より古いログを提供しません。これは を/etc/systemd/journald.conf設定することで変更できますStorage=persistent。
これを説明するマニュアルページは次のとおりです。
man 8 systemd-journald
man 5 journald.conf
man 5 systemd-system.conf
man 5 systemd-user.conf
また、サービスが systemd によって自動的に再起動されるようにするには、その.serviceファイルで設定する必要があることに注意してくださいman 5 systemd.service。
Restart=
Configures whether the service shall be
restarted when the service process exits, is
killed, or a timeout is reached. The service
process may be the main service process, but it
may also be one of the processes specified with
ExecStartPre=, ExecStartPost=, ExecStop=,
ExecStopPost=, or ExecReload=. When the death
of the process is a result of systemd operation
(e.g. service stop or restart), the service
will not be restarted. Timeouts include missing
the watchdog "keep-alive ping" deadline and a
service start, reload, and stop operation
timeouts.
Takes one of no, on-success, on-failure,
on-abnormal, on-watchdog, on-abort, or always.
If set to no (the default), the service will
not be restarted.
答え3
サービスが最後に開始または再起動された時刻を確認できます。service chatty statusまたは を使用しますsystemctl status chatty。以下は apache2 または httpd サービスの例です。
# service apache2 status
● apache2.service - LSB: Apache2 web server
Loaded: loaded (/etc/init.d/apache2)
Drop-In: /lib/systemd/system/apache2.service.d
└─forking.conf
Active: active (running) since ven. 2017-06-02 15:53:01 CEST; 21min ago
Process: 14773 ExecStop=/etc/init.d/apache2 stop (code=exited, status=0/SUCCESS)
Process: 22912 ExecReload=/etc/init.d/apache2 reload (code=exited, status=0/SUCCESS)
Process: 14880 ExecStart=/etc/init.d/apache2 start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/apache2.service
この行にはActive: active (running) since Wen. 2017-06-02 15:53:01 CEST; 21min agoサービスがどのように実行されているかが表示されますが、探しているものを正確に「リスト」のように表示できるかどうかはわかりません。
# systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2019-10-11 00:35:58 EEST; 1 weeks 3 days ago
Docs: man:httpd(8)
man:apachectl(8)
Process: 29728 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
Main PID: 10722 (httpd)
Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec"
Memory: 8.7M