FHEM Forum

Hallo,

heute früh war mein cubietruck nicht mehr erreichbar, ein ping funktionierte auch nicht mehr.
Ich habe dann die Resettaste gedrückt, danach funktionierte er wieder.
Kann bitte mal jemand auf die dmesg Ausgabe in der Anlage schauen ob ein Problem erkennbar ist.
Die nand Fehlermeldungen dürften eigentlich egal sein, da ich eine SD-Karte gesteckt habe.
root ist auf SSD

root@cubie:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.9G  5.4G  2.2G  72% /
devtmpfs       1000M     0 1000M   0% /dev
tmpfs           128M  196K  128M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           128M     0  128M   0% /run/shm
/dev/sda2        50G  5.3G   42G  12% /daten
tmpfs           1.0G  4.0K  1.0G   1% /tmp
Gruß Ralf

Hallo,

das ist die Ausgabe von dmesg nach dem Neustart. Interessant wäre das /var/lib/syslog vom vorigen Lauf bis zum Reset.

Viele Grüße
Boris

Da steht nichts besonderes
Jul 13 07:17:01 localhost /USR/SBIN/CRON[14924]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 13 07:20:01 localhost /USR/SBIN/CRON[14928]: (root) CMD (/root/scripts/empty_shutdown)
Jul 13 07:30:01 localhost /USR/SBIN/CRON[14935]: (root) CMD (/root/scripts/empty_shutdown)
Jul 13 07:40:01 localhost /USR/SBIN/CRON[14943]: (root) CMD (/root/scripts/empty_shutdown)
Jul 13 07:50:01 localhost /USR/SBIN/CRON[14950]: (root) CMD (/root/scripts/empty_shutdown)
Jul 13 08:00:01 localhost /USR/SBIN/CRON[14958]: (root) CMD (/root/scripts/empty_shutdown)
Jul 13 08:10:01 localhost /USR/SBIN/CRON[14965]: (root) CMD (/root/scripts/empty_shutdown)
Jul 13 08:17:01 localhost /USR/SBIN/CRON[14972]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 13 08:20:01 localhost /USR/SBIN/CRON[14975]: (root) CMD (/root/scripts/empty_shutdown)
Jul 13 08:30:01 localhost /USR/SBIN/CRON[14982]: (root) CMD (/root/scripts/empty_shutdown)
Jul 14 08:53:34 localhost kernel: imklog 5.8.11, log source = /proc/kmsg started.
Jul 14 08:53:34 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="1923" x-info="http://www.rsyslog.com"] start
Jul 14 08:53:34 localhost kernel: [    0.000000] Booting Linux on physical CPU 0
...
Jul 14 08:54:36 localhost kernel: [   77.344753] delay: estimated 336, actual 144
Jul 14 08:54:36 localhost kernel: [   77.352225] delay: estimated 336, actual 144
Jul 14 08:54:36 localhost kernel: [   77.359787] delay: estimated 288, actual 144
Jul 13 09:00:09 localhost /USR/SBIN/CRON[2381]: (root) CMD (/root/scripts/empty_shutdown)
Jul 13 09:10:01 localhost /USR/SBIN/CRON[2484]: (root) CMD (/root/scripts/empty_shutdown)
Mir ist da auch aufgefallen, daß ca 5 Min lang das Datum von morgen drin steht.

root@cubie:~/scripts# cat empty_shutdown
#!/bin/sh
export BATLEVEL=`cat /sys/class/power_supply/battery/capacity`
export BATONLINE=`cat /sys/class/power_supply/battery/online`
DATE=`date`
if [ $BATLEVEL -le 15 ] && [ $BATONLINE -eq 1 ] 
then
       echo "$DATE: Batterieladezustand niedrig: $BATLEVEL%" >> /opt/fhem/log/battery.log
       echo "$DATE: Cubietruck wird heruntergefahren." >> /opt/fhem/log/battery.log
       shutdown -h now
fi
root@cubie:~/scripts#
root@cubie:/var/log# cat /opt/fhem/log/battery.log
...
Wed May 15 09:20:01 CEST 2019: Batterieladezustand niedrig: 14%
Wed May 15 09:20:01 CEST 2019: Cubietruck wird heruntergefahren.
Wed May 15 09:30:01 CEST 2019: Batterieladezustand niedrig: 7%
Wed May 15 09:30:01 CEST 2019: Cubietruck wird heruntergefahren.
Sun Oct 30 03:00:01 CET 2022: Batterieladezustand niedrig: 14%
Sun Oct 30 03:00:01 CET 2022: Cubietruck wird heruntergefahren.
root@cubie:/var/log#
Gruß Ralf

Sorry, keine Idee. Das Log ist unauffällig.

Danke, evtl war nur die uptime zu groß.

Warum muß sowas immer zu unpassenden Zeitpunkten passieren?
Ich fahre morgen für einige Tage in die Berge.

Zitat von: Ralf9 am 13 Juli 2023, 14:11:53evtl war nur die uptime zu groß.

Hä?

Was auffällt:

ZitatJul 14 08:54:36 localhost kernel: [   77.359787] delay: estimated 288, actual 144
Jul 13 09:00:09 localhost /USR/SBIN/CRON[2381]: (root) CMD (/root/scripts/empty_shutdown)

Du hast einen Zeitsprung drin. Sogar mehr als einen. Außerdem ist der 14 eigentlich morgen?
(O.K. hast Du auch schon geschrieben)

Was ich nicht weiß: Wie ist die Uhr bei dem Cubi realisiert?

Zitat von: Wernieman am 13 Juli 2023, 18:41:15Was ich nicht weiß: Wie ist die Uhr bei dem Cubi realisiert?

Kommt drauf an, ob man eine Pufferbatterie dafür angeschlossen hat oder nicht.

Falls nicht, verhält die sich einfach so, wie sich eine RTC bei Stromausfall halt verhält. Sie muss danach nicht mehr stimmen, solange sie nicht neu (z.B. durch ntp) synchronisiert wurde.

Laut seinem Log hat er aber kein boot zwischen den Zeitsprüngen, also Stromausfall sehe ich da eher als unwahrscheinlich. Zusätzlich wird doch eigentlich (bei Linux) nicht die Hardwareuhr, sondern eine Softwareuhr verwendet ..... wie kommen da im laufendem System so ein Zeitsprung (und genau um 1h?)?. Meine Frage währe dann, läuft eventuell ein (böser) Cron mit z.B. ntpdate? Oder eine sonstige autoconfig, die hier Harakiry gemacht hat?

ZitatZusätzlich wird doch eigentlich (bei Linux) nicht die Hardwareuhr, sondern eine Softwareuhr verwendet ..... wie kommen da im laufendem System so ein Zeitsprung (und genau um 1h?)

Es sieht so aus, daß beim booten erstmal die Hardwareuhr verwendet wird und dann die Zeit vom Internet geholt wird.
Ich habe ein LiPo Akku mit 4400mAh eingebaut.

Die Hardwareuhr geht fast ein Tag vor. Heißt das, daß ich die Hardwareuhr ab und zu mit "hwclock –systohc" stellen muß?
root@cubie:/etc/init.d# ./hwclock.sh show
Fri Jul 21 11:48:28 2023  -1.640318 seconds
root@cubie:/etc/init.d# date
Thu Jul 20 11:53:42 CEST 2023
Gruß Ralf

Wenn die Hardwareuhr so ungenau ist ... ist es keine ordentliche Hardwareuhr. In welchen Zeitraum hewinnt sie so viel Zeit?

Der Cubietruck wurde schon einige Jahre nicht mehr heruntergefahren.
Laut
https://debian-handbook.info/browse/de-DE/stable/sect.config-misc.html
wird die Hardwareuhr nur beim herunterfahren gestellt.

Im log Verzeichnis ist mir aufgefallen, dass bei syslog seit 2017 das logrotate nicht mehr funktioniert. Ist es ausreichend, wenn ich syslog.1.gz lösche?
-rw-r----- 1 root adm     171631546 Jul 21 14:00 syslog
-rw-r----- 1 root adm          8340 Aug 21  2017 syslog.1
-rw-r----- 1 root adm             0 Aug 22  2017 syslog.1.gz
-rw-r----- 1 root adm          1492 Aug 20  2017 syslog.2.gz
-rw-r----- 1 root adm          1469 Aug 19  2017 syslog.3.gz
-rw-r----- 1 root adm          1458 Aug 18  2017 syslog.4.gz
Gibts einen besonderen Grund warum bei syslog daily steht und nicht weekly?
root@cubie:/etc/logrotate.d# cat rsyslog
/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Zitatdaily steht und nicht weekly

Es geht nur darum, ob das Logfile daily oder weekly rotiert werden soll. Entscheidungssache von Administrator

Wenn Du die alten syslog nichts brauchst, kannst Du auch einfach alle syslog.?.gz löschen. Wenn DU sie brauchst, auch einfach in ein "old" verschieben
mkdir /var/log/old
mv /var/log/syslog.?.gz /var/log/oldNach X Tagen (Wochen/Monaten) das Aufräumen von old nicht vergessen ;o)