Bir systemd hizmetinin ne zaman başlatıldığını / durdurulduğunu / yeniden başlatıldığını nasıl görebilirim?

Bir Debian (Jessie) sunucusunda çalışan (kendim yazdım) bir hizmetim var ve hizmetin kendi günlükleri belirli bir zamanda yeniden başlatıldığını belirtiyor. Bir segfault veya başka bir kilitlenme belirtisi yoktur, bu yüzden şimdi uygulama bir şekilde sessizce başarısız oldu ve systemd tarafından yeniden doğdu ya da bir kullanıcı hizmeti kasıtlı olarak yeniden başlatıp başlamış olup olmadığını anlamaya çalışıyorum systemctl.

Kabuk geçmişi böyle bir etkinlik göstermez, ancak export HISTCONTROL=ignorebothbir SSH oturumunun zaman aşımına uğraması nedeniyle zaman aşımına uğramış olduğundan, önceki bir girişin bash geçmişinin diske yazılmasını engelleyen kesin değildir . Sunucu o sırada yeniden başlatılmadı.

Ama bir hizmet iken o systemd kendisi belirten bir günlük tutmalı beklenebilir bilerek yeniden. Şaşırtıcı bir şekilde journalctl, bu tür günlüklerin nasıl alınacağına dair herhangi bir belge (örneğin ) bulamadım .

Diğer bazı yayınlar (örn . Normal kullanıcı systemd hizmetleri için nerede / neden günlük yok? ), Bunun gibi günlük iletileri olması gerektiğini gösteriyor gibi görünüyor:

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.

Ancak sistemimde böyle günlük mesajları görmüyorum.

Systemd hizmetlerinin ne zaman başlatıldığını, durdurulduğunu veya yeniden başlatıldığını öğrenmenin bir yolu var mı?

Edit : Görünüşe göre insanların karşılaşabileceği tipik sorun, onlar journalctlayrıcalıklı olmayan bir kullanıcı olarak çalıştırmak olmasıdır . Benim için durum böyle değil root, tüm zamanlar boyunca çalışıyorum. Bir yoruma cevaben, koşmak grep systemd /var/log/syslogbana sadece şunu verir:

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.

Bunu betiğiniz gerekiyorsa, systemctl show komutu kullanmaya bakmalısınız . Komut dosyaları için herhangi bir şeyi ayrıştırmaya çalışmaktan daha yararlıdır status. Örneğin, hizmetin en son ne zaman başladığını bulmak için şunları kullanabilirsiniz:

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

Mevcut tüm özellikleri görmek istiyorsanız sadece bayrağı atlayın ve hepsini dışarı atar.

$ systemctl show <service_name>

Bu mülklerin belgelerine buradan ulaşabilirsiniz .

Debian'daki varsayılan yapılandırmayla, ayrıcalıksız bir kullanıcı ne systemd-dergi ne de syslog günlüklerine erişemez. Normal bir kullanıcı olarak giriş yaptıysanız, bu yanıtı journalctl'den alacaksınız:

$ journalctl 
No journal files were found.

Bu biraz kafa karıştırıcı.

Kök olarak oturum journalctl --unit=yourserviceaçtıysanız, aradığınız bilgileri size vermelidir. Sunucumdan sonra systemctl restart bind9, bunu sonra alırım 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.

Eğer bind9 ile açıkça öldürürsem kill -9, journalctl --unit=bind9verir:

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.

İlk satır, sürecin öldüğü için öldüğünü gösterir.

systemd-journalald ayrıca tüm günlük iletilerini syslog'a iletir, bu nedenle bu iletileri de bulmalısınız /var/log/syslog.

Systemd ve systemd-journalald, /etc/systemd/system.confve içinde değiştirilebilen bir varsayılan yapılandırmada derlenmiştir /etc/systemd/journald.conf.

Varsayılan olarak, systemd-dergi günlükleri altında depolar /run, bu da tmpfsbir yeniden başlatmadan sonra kaybolur ve bu nedenle kaybolur. Bu, günlük iletilerini son önyüklemeden daha eski hale getirmek için syslog dosyalarına bakmanız gerektiği anlamına gelir. Bu durumda journalctl size son önyüklemeden daha eski günlükler vermez. Bu /etc/systemd/journald.confayar ile değiştirilebilir Storage=persistent.

Bunu belgeleyen manuel sayfalar:

man 8 systemd-journald
man 5 journald.conf
man 5 systemd-system.conf
man 5 systemd-user.conf

Ayrıca, bir hizmetin systemd tarafından otomatik olarak yeniden başlatılması için bunun .servicedosyasında yapılandırılması gerektiğini unutmayın . Gönderen 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.

Hizmetinizin en son ne zaman başladığını veya yeniden başlatıldığını görebilirsiniz. service chatty statusVeya tuşunu kullanın systemctl status chatty. Apache2 veya httpd hizmeti için örnekler:

# 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 agohizmetin nasıl çalıştığından beri çizgi gösterisi ama tam olarak ne aradığınızı bir 'liste' gibi görüntüleyebilir misiniz bilmiyorum.

# 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

-fGünlükteki iletilere filtre uygulamak için seçeneği kullanabiliriz ( https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html ).

journalctl -f _TRANSPORT=journal example