SmartHomeNG State: degraded

[dede2k]

Hallo Zusammen,
mein Smarthome funktioniert nicht. Mein backend admin ist seit längerer Zeit nicht erreichbar.
Folgend der Log:

[smarthome@SmartHomeNG /usr/local/smarthome]$ systemctl status
● SmartHomeNG
State: degraded
Jobs: 0 queued
Failed: 3 units
Since: Thu 1970-01-01 01:00:07 CET; 51 years 10 months ago
CGroup: /
├─user.slice
│ └─user-1001.slice
│ ├─session-7.scope
│ │ ├─3848 sshd: smarthome [priv]
│ │ ├─3854 sshd: smarthome@pts/0
│ │ ├─3855 -bash
│ │ ├─3955 python3 bin/smarthome.py
│ │ ├─4009 systemctl status
│ │ └─4010 pager
│ └─user@1001.service
│ └─init.scope
│ ├─3356 /lib/systemd/systemd --user
│ └─3357 (sd-pam)
├─init.scope
│ └─1 /sbin/init
└─system.slice
├─nfs-idmapd.service
│ └─337 /usr/sbin/rpc.idmapd
├─grafana-server.service
│ └─665 /usr/sbin/grafana-server --config=/etc/grafana/grafana.ini --pidfile=/var/run/grafana/grafana-serve
├─nfs-mountd.service
│ └─670 /usr/sbin/rpc.mountd --manage-gids
├─alsa-state.service
│ └─355 /usr/sbin/alsactl -E HOME=/run/alsa -s -n 19 -c rdaemon
├─systemd-timesyncd.service
│ └─342 /lib/systemd/systemd-timesyncd
├─nmbd.service
│ └─664 /usr/sbin/nmbd --foreground --no-process-group
├─unattended-upgrades.service
│ └─661 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal
├─mosquitto.service
│ └─666 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
├─nginx.service
│ ├─718 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
│ ├─720 nginx: worker process
│ ├─721 nginx: worker process
│ ├─722 nginx: worker process
│ ├─723 nginx: worker process
│ └─724 nginx: cache manager process
├─dbus.service
│ └─357 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog
├─hciuart.service
│ └─575 /usr/bin/hciattach /dev/serial1 bcm43xx 3000000 flow -
├─smbd.service
│ ├─731 /usr/sbin/smbd --foreground --no-process-group
│ ├─792 /usr/sbin/smbd --foreground --no-process-group
│ └─793 /usr/sbin/smbd --foreground --no-process-group
├─ssh.service
│ └─663 /usr/sbin/sshd -D
├─php7.3-fpm.service
│ ├─654 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)
│ ├─735 php-fpm: pool www
│ └─737 php-fpm: pool www
├─avahi-daemon.service
│ ├─358 avahi-daemon: running [SmartHomeNG.local]
│ └─371 avahi-daemon: chroot helper
├─system-getty.slice
│ └─getty@tty1.service
│ └─715 /sbin/agetty -o -p -- \u --noclear tty1 linux
├─wpa_supplicant.service
│ └─366 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
├─triggerhappy.service
│ └─360 /usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user nobody --dev
├─rpcbind.service
│ └─340 /sbin/rpcbind -f -w
├─nfs-blkmap.service
│ └─152 /usr/sbin/blkmapd
├─systemd-logind.service
│ └─361 /lib/systemd/systemd-logind
├─knxd.service
│ └─655 /usr/bin/knxd -e 15.15.240 -E 0.0.2:8 -c -b ipt:192.168.178.54
├─cron.service
│ └─705 /usr/sbin/cron -f
├─systemd-udevd.service
│ └─166 /lib/systemd/systemd-udevd
├─rsyslog.service
│ └─365 /usr/sbin/rsyslogd -n -iNONE
├─atop.service
│ └─398 /usr/bin/atop -R -w /var/log/atop/atop_20210729 600
├─bluetooth.service
│ └─581 /usr/lib/bluetooth/bluetoothd --noplugin=sap
├─snmpd.service
│ └─659 /usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux mteTrigger mteTriggerConf
├─systemd-journald.service
│ └─116 /lib/systemd/systemd-journald
├─atopacct.service
│ └─378 /usr/sbin/atopacctd
├─rng-tools.service
│ └─710 /usr/sbin/rngd -r /dev/hwrng
├─dhcpcd.service
│ ├─503 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -Dnl80211,wext
│ └─650 /sbin/dhcpcd -q -w
└─systemd-networkd.service
└─402 /lib/systemd/systemd-networkd
lines 52-100/100 (END)

Hat mir jemand einen Tip?
Smartvisu ist erreichbar hat aber ebenfalls keine Verbindung zu Smarthome.

Besten Dank vorab!

[Onkelandy]

Etwas wenig Info..? Was sagt denn systemctl status smarthome? Was sagt das Logfile? Was passiert beim manuellen Start von shng mittels smarthome.py -d?

[dede2k]

Komischerweise funktioniert es wieder. Ich weiss nicht was ich genau gemacht habe, aber es funzt.


● smarthome.service - SmartHomeNG daemon
Loaded: loaded (/lib/systemd/system/smarthome.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2021-11-25 22:32:33 CET; 34min ago
Process: 693 ExecStart=/usr/local/bin/python3 /usr/local/smarthome/bin/smarthome.py (code=exited, status=0/SUCCESS)
Main PID: 837 (python3)
Tasks: 28 (limit: 4915)
Memory: 82.7M
CGroup: /system.slice/smarthome.service
└─837 /usr/local/bin/python3 /usr/local/smarthome/bin/smarthome.py

Nov 25 22:32:27 SmartHomeNG systemd[1]: Starting SmartHomeNG daemon...
Nov 25 22:32:33 SmartHomeNG python3[693]: Daemon PID 837
Nov 25 22:32:33 SmartHomeNG systemd[1]: smarthome.service: Supervising process 837 which is not our child. We'll most likely not notice when it exits.
Nov 25 22:32:33 SmartHomeNG systemd[1]: Started SmartHomeNG daemon.

[wvhn]

Wenn beim Neustart des Raspberrys das Datum nicht gesetzt wird, weil z.B. der ntp-Server nicht erreichbar ist, dann sind sämtliche Zertifikate ungültig und die Python-Pakete aus der requirements-Liste können nicht geprüft / installiert werden. Danach sieht es in diesem Fall aus (Zeile 6 in dem zitierten Log).

Since: Thu 1970-01-01 01:00:07 CET; 51 years 10 months ago

Gruß
Wolfram

[dede2k]

Wenn beim Neustart des Raspberrys das Datum nicht gesetzt wird, weil z.B. der ntp-Server nicht erreichbar ist, dann sind sämtliche Zertifikate ungültig und die Python-Pakete aus der requirements-Liste können nicht geprüft / installiert werden. Danach sieht es in diesem Fall aus (Zeile 6 in dem zitierten Log).

Gruß
Wolfram

Danke für die Antwort.
Was kann ich dagegen tun?

[Onkelandy]

Zum einen die Systemuhrzeit und das Zeit-Sync-Service checken. Zum anderen vielleicht das Paket https://manpages.debian.org/jessie/f...lock.8.en.html installieren.

[wvhn]

Hast Du shNG als Service eingerichtet gemäß der Komplettanleitung? Dann sollte shNG erst starten, wenn das Netzwerk läuft. Das müsste fürs Einstellen der Systemzeit per Zeitserver aus dem Internet reichen (ich gehe davon aus, dass der Raspi Internetverbindung hat, denn in Deinem zweiten Post war die Zeit korrekt eingestellt).

Wenn die Zeitsynchronisation dennoch öfter nicht rechtzeitig fertig ist, könntest Du noch versuchen, ein

after = time-sync.target

hinzuzufügen.

[Klanad]

Hallo Leute ,

habe exakt die gleiche Ausgabe mit SmartHomeNG State: degraded. bei Aufruf von systemctl status
Wollte eigentlich auf die neueste Version wechseln und bin über eben das hier gestolpert.

Vorab, bei mir funktioniert alles soweit ich es überschauen kann (bin aber nicht der Crack).
Komme auch in den Admin Bereich. Hier wird mir das richtige Datum/Uhrzeit angegzeigt.
Kann auch aus der smartVISU alles schalten.

Was ist der Unterschied zwischen "systemctl status" (hier wird mir ein falsches Datum angezeigt) und "systemctl status smarthome"? (mit dem richtigen Datum - sieht unten)


[smarthome@SmartHomeNG ~]$ systemctl status
● SmartHomeNG
State: degraded
Jobs: 0 queued
Failed: 2 units
Since: Thu 1970-01-01 01:00:09 CET; 52 years 0 months ago
CGroup: /
├─user.slice
│ └─user-1001.slice
│ ├─session-22.scope
│ │ ├─3227 sshd: smarthome [priv]
│ │ ├─3245 sshd: smarthome@pts/0
│ │ ├─3246 -bash
│ │ ├─3451 systemctl status
│ │ └─3452 pager
│
usw.

Aufruf von systemctl status smarthome zeigt

[smarthome@SmartHomeNG ~]$ systemctl status smarthome
● smarthome.service - SmartHomeNG daemon
Loaded: loaded (/lib/systemd/system/smarthome.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2022-01-08 19:34:35 CET; 8min ago
Process: 3384 ExecStart=/usr/bin/python3 /usr/local/smarthome/bin/smarthome.py (code=exited, status=0/SUCCESS)
Main PID: 3394 (python3)
Tasks: 26 (limit: 2059)
Memory: 45.4M
CGroup: /system.slice/smarthome.service
└─3394 /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py

Bin allerdings nicht so ganz firm mit der ganzen Materie.
Danke

Screenshot 2022-01-08 203222.jpg

[Onkelandy]

Also nur "systemctl status" gibt die halt Infos zu allen Services. Dass da "smarthomeNG" als Erstes steht, liegt daran, dass der Host so heißt. Mit Smarthome NG Software hat das nix zu tun. Das "since 1970..." ist bei mir auch - hat wohl nix zu bedeuten außer dass ganz zum Beginn vom Booten die Zeit noch nicht bekannt ist (was normal ist). Wichtig sind die 2 failed units. Die musst du aufspüren und wenn möglich fixen. Haben aber mit shng offenbar nix zu tun.

Bei welchen Services bei
systemctl list-units --type=service
zeigt er nicht "loaded" und "active" an?