systemdサービスがいつ開始/停止/再開されたかを確認するにはどうすればよいですか？

12

私は（自分で作成した）サービスをDebian（Jessie）サーバーで実行していて、サービスのログは、特定の時間に再起動したことを示しています。私は今、アプリケーションが何らかの形であれば把握しようとしていますので、セグメンテーション違反または他のクラッシュの兆候はありませんが、静かに失敗したとsystemdに再生成によって得た、またはユーザーが意図的に介してサービスを再起動するかどうかsystemctl。

シェルの履歴にはそのようなアクティビティは表示されませんがexport HISTCONTROL=ignoreboth、SSHセッションがタイムアウトしたため、以前のログインのbash履歴がディスクに書き込まれなかったため、これは決定的なものではありません。現時点ではサーバーは再起動されていません。

しかし、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.
systemd  systemd-journald 
— マインドリオット
ソース
「そのようなログメッセージは表示されません」-奇妙なことですか？私はたくさんいるgrep systemd /var/log/syslog
— hschou 2017年
私のシステムではStopped target Default、Starting Shutdownなどの非常に一般的なメッセージしか表示されません。個々のサービスについて何も示していません。多分それは単なる構成の問題ですか？この特定のケースでは、私はDebian Jessieを使用しています。
— mindriot 2017年
または/etc/systemd/journald.confがオーバーライドされていないことを確認し、にリストされているように、journaldを構成できる他のすべての場所を調べます。MaxLevelStoreMaxLevelSyslogman journald.conf
— meuh
先端をありがとう。残念ながら、下にあるすべての構成ファイル/etc/systemdは基本的に空です（あなたが言及したものを含め、すべてのオプションはコメント化されています）。
— mindriot 2017年

回答:

11

これをスクリプト化する必要がある場合は、systemctl show コマンドを使用して調べる必要があります。から何かを解析しようとするよりも、スクリプトにとってより便利ですstatus。たとえば、サービスが最後にいつ開始されたかを見つけるには、次のコマンドを使用できます。

$ systemctl show systemd-journald --property=ActiveEnterTimestamp
ActiveEnterTimestamp=Wed 2017-11-08 05:55:17 UTC

利用可能なすべてのプロパティを表示したい場合は、フラグを省略すれば、すべてのプロパティがダンプされます。

$ systemctl show <service_name>

これらのプロパティのドキュメントはここにあります。

— jdf
ソース
興味深いことに、私はその特性を知りませんでした。残念ながら、サービスが失敗して再起動したかどうか、またはサービスがユーザーによって意図的に再起動されたかどうかに関係なく、これらはまったく同じに設定されます。
— mindriot 2017年
1
ちなみに、プロパティのより良いリンクはdbusのドキュメントのようです。
— mindriot
ドキュメントのより良いリンクである@mindriotに感謝します、私は私の答えを更新しました。
— jdf 2017年
1
@mindriotは最初のポイントに関してですが、チェックしたことはStatusErrnoありResultますか？サービスが失敗したり、サービスが再起動したりすると、これらが変化するのではないでしょうか。本当に必要な場合はExecStopPost、ファイルをタッチしてシャットダウン時のタイムスタンプを更新するステップを追加してみてください。これは、サイレントリスタートと目的のあるリスタートを区別するのに役立ちます。
— jdf 2017年
おかげで、それも良い点です。状況を簡単に確認/再現することはできません。私の元の投稿はすでに半年近く経過しており、システムにいくつかの変更が加えられています。でも、どこかで試せるかどうか、機会があればチェックします。
— mindriot 2017年
3

Debianのデフォルト設定では、非特権ユーザーはsystemd-journaldにもsyslogログにもアクセスできません。通常のユーザーとしてログインしている場合、journalctlから次の応答を受け取ります。

$ journalctl 
No journal files were found.

これは少し混乱します。

rootとしてログインしている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すると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。

systemdとsystemd-journaldには、とで変更できるデフォルトのコンパイル済み設定が/etc/systemd/system.confあり/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.
— トム・ビエルク
ソース
ほとんどのユーザーの問題をおそらく解決する、広範囲でよく書かれた投稿をありがとう。残念ながら、私の場合は私が表示されていない任意のログの行は、に起因するsystemdジャーナルを出力するとき、あなたが説明するように、私は、rootとして全体の時間を働いているにもかかわらず、。/var/log/syslog何も表示されません。ちなみにこれはsystemd 215です。
— mindriot 2017
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
— クレイペス
ソース
1
service互換性のためにsystemdで動作する古いUpstartコマンドです。ネイティブsystemdコマンドはsystemctl status apache2です。
— Mark Stosberg、2017年
ありがとう。残念ながら、それはサービスがいつ（再）開始されたかを示すだけで、その理由は示しません。また、現在の状況、つまり最後の再起動のみが表示されます。
— mindriot 2017年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.