Ankündigung

Einklappen
Keine Ankündigung bisher.

SmartHomeNG State: degraded

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    SmartHomeNG State: degraded

    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!

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

    Kommentar


      #3
      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.

      Kommentar


        #4
        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
        Zuletzt geändert von bmx; 26.11.2021, 09:14.

        Kommentar


          #5
          Zitat von wvhn Beitrag anzeigen
          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?

          Kommentar


            #6
            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.

            Kommentar


              #7
              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
              Code:
              after = time-sync.target
              hinzuzufügen.
              Zuletzt geändert von wvhn; 23.12.2021, 21:50.

              Kommentar


                #8
                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
                Angehängte Dateien

                Kommentar


                  #9
                  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?

                  Kommentar

                  Lädt...
                  X