Estou executando o Arch-ARM no RPi3. Percebi que, quando o sistema trava, não consigo encontrar nenhum log de travamento relacionado nos registros de diário.
Arch Linux ARM no RPi3: Linux 4.4.37-1-ARCH #1 SMP armv7l GNU/Linux
Systemd: systemd 232
/etc/systemd/journald.conf :
[Journal]
Storage=persistent
Compress=yes
#Seal=yes
#SplitMode=uid
SyncIntervalSec=1
#RateLimitIntervalSec=30s
#RateLimitBurst=1000
SystemMaxUse=1.5G
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
MaxRetentionSec=1month
MaxFileSec=3hour
#ForwardToSyslog=no
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
Log de falhas recente:
Dec 29 03:43:48 sudo[21861]: my_user : TTY=unknown ; PWD=/opt/my_app/repo/src ; USER=root ; COMMAND=/usr/sbin/hciconfig hci0 reset
Dec 29 03:43:48 sudo[21861]: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 29 03:43:48 sudo[21861]: pam_unix(sudo:session): session closed for user root
Dec 29 03:43:48 my_app.py[17773]: trying to connect to XX:XX:XX:XX:XX:XX
Dec 29 03:43:48 systemd-udevd[21865]: Process '/bin/hciconfig hci0:64 up' failed with exit code 1.
Dec 29 03:43:51 my_app.py[17773]: connection successful :)
-- Reboot --
Jan 03 16:31:25 systemd[1]: Time has been changed
Jan 03 16:31:26 dhcpcd[470]: forked to background, child pid 587
Jan 03 16:31:25 systemd-timesyncd[360]: Synchronized to time server 206.108.0.133:123 (2.arch.pool.ntp.org).
Jan 03 16:31:25 systemd[1]: Starting Update man-db cache...
Jan 03 16:31:25 systemd[1]: Starting Rotate log files...
Jan 03 16:31:25 systemd[1]: Started Verify integrity of password and group files.
Jan 03 16:31:25 systemd[1]: ssh-tunnel.service: Service hold-off time over, scheduling restart.
Parece que, de alguma forma, journald está falhando em sync logs quando ocorre uma falha.
Também estou curioso para saber se a seguinte reivindicação do wiki do Arch Linux ainda é válida:
Since the syslog component of systemd, journald, does not flush its logs to disk during normal operation, these logs will be gone when the machine is shut down abnormally (power loss, kernel lock-ups, ...). In the case of kernel lock-ups, it is pretty important to have some kernel logs for debugging. Until journald gains a configuration option for flushing kernel logs, rsyslog can be used in conjunction with journald.
relatório de bug relacionado (antigo): Bug 61411 - Todos os logs desde a última inicialização após falha / reinicialização forçada
problema semelhante (antigo): Depuração de bloqueio - o systemd perde meus logs