[GELÖST] RaspberryMatic + NUT-Server - USV-Reboot

[wolwin]

Hallo zusammen,
nachdem ich gesehen hatte, dass die RaspberryMatic die Möglichkeit bietet einen NUT-Server zu betreiben, habe ich meine bisherige NUT-Server Installation, die sich auf einem Raspberry / Debian System befand, migriert. Gleichzeitig habe ich eine Homematic Integration mit zusätzlichem Email Versand vorgenommen. Entwickelt ... getestet ... läuft ...

Und dann kommt zwei Monate später tatsächlich der Stromausfall !! Alles funktioniert wie es soll ... die USV geht auf Batteriebetrieb, die Emails werden versandt, nachdem die Batterie-Kapazität im kritischen Bereich ist, wird der FSD Shutdown ausgelöst (auch für die Clients) und die RaspberryMatic fährt ordnungsgemäß herunter. Alles gut - oder? Leider nein ... das System-Log der Fritzbox zeigte, dass die USV gar nicht heruntergefahren war, sondern auf Batterie weitergelaufen war bis dass dann der Strom wieder da war. Das führte dazu, dass die RaspberryMatic weiter im 'Heruntergefahrenen Modus' stand (also abgeschaltet) und darauf wartete, dass die USV den Strom ab- und dann später wieder anschaltet. Genau DAS ist aber nicht geschehen - stattdessen musste die RaspberryMatic durch manuellen Eingriff neu gestartet werden.

Natürlich dachte ich, dass bei der Migration irgendetwas schief gelaufen ist - konnte aber keinen Fehler entdecken. Also habe ich die ursprüngliche Raspberry / Debian Installation mit RaspberryMatic Installation verglichen und letztlich gefunden, dass die RaspberryMatic zwar den System-Shutdown startet, aber den Shutdown der USV nicht ausführt ! Hier mal ein System-Überblick, wie es hätte ablaufen müssen:

Das Weitere war schnell gefunden - das Herunterfahren der USV wird mit 'nutshutdown' hier ausgelöst (Raspberry / Debian Installation);

Zwischenablage03.jpg (21.09 KiB) 1884 mal betrachtet

Ich habe dann die RaspberryMatic nach 'nutshutdown' durchsucht und nicht gefunden. Daher nehme ich an, dass das Ausschalten der USV im 'systemd'-Bereich fehlt / nicht implementiert ist.

@ Jens Maus: vielleicht könntest Du ja mal einen Blick darauf werfen ... - Danke!

Gruss
Wolfram

[wolwin]

Hallo,
um die 'nutshutdown' Funktion nachzubilden, habe ich in '/usr/local/etc/config/rc.d/' folgende Datei eingestellt:

Code: Alles auswählen

#!/bin/sh
# /usr/local/etc/config/rc.d/nutshutdown
case "$1" in
""|start)
  # RM Startup 
  ;;
stop)
  # RM Shutdown 
  # - Test for the UPS shutdown flag
  # - Command the UPS driver to run their shutdown sequence
  # Test for the UPS shutdown flag
  if /usr/sbin/upsmon -K >/dev/null 2>&1; then
    # Send email 
    /etc/config/addons/email/email 47
    # Command the UPS driver to run their shutdown sequence
    /usr/sbin/upsdrvctl shutdown
    /bin/sleep 2
  fi
  ;;
esac

Löse ich über die Konsole mit 'upsmon -c fsd' den Shutdown Prozess aus, wird 'nutshutdown' korrekt abgearbeitet (=> die Email wird versandt ...) - nur der Befehl 'upsdrvctl shutdown', der die USV zur Abschaltung auffordert, wird nicht korrekt ausgeführt.

Ich habe dann an der Console getestet, was schief läuft ...

Code: Alles auswählen

root@RASPI-HM:~# upsdrvctl -t shutdown
Network UPS Tools - UPS driver controller 2.7.4.1
*** Testing mode: not calling exec/kill
   0.000000     [D2]
If you're not a NUT core developer, chances are that you're told to enable debugging
to see why a driver isn't working for you. We're sorry for the confusion, but this is
the 'upsdrvctl' wrapper, not the driver you're interested in.

Below you'll find one or more lines starting with 'exec:' followed by an absolute
path to the driver binary and some command line option. This is what the driver
starts and you need to copy and paste that line and append the debug flags to that
line (less the 'exec:' prefix).

   0.000787     [D1] Shutdown UPS: ups
   0.000892     [D2] exec:  /usr/bin/usbhid-ups -a ups -k

Das ist noch ok: es wird also der Befehl '/usr/bin/usbhid-ups -a ups -k' aufgerufen - und hier passiert der Fehler:

Code: Alles auswählen

root@RASPI-HM:~# /usr/bin/usbhid-ups -a ups -k
Network UPS Tools - Generic HID driver 0.43 (2.7.4.1)
USB communication driver 0.33
Can't claim USB device [051d:0002]: No such file or directory

Das Problem ist, dass das System das USB-Gerät als Root-Besitzer einbindet, aber der Nut-Daemon mit einem unprivilegierten Konto arbeitet, das nicht über die notwendigen Rechte verfügt. Die einfache Lösung besteht eigentlich darin, udev zum Anpassen der Geräteberechtigungen zu verwenden. Gefunden habe ich diese Anpassung in '/lib/udev/rules.d/' in der Datei '62-nut-usbups.rules' ...

Nur verstehe ich jetzt nicht, warum dieser Mechanismus hier nicht funktioniert ...

[jmaus]

Das Problem ist, dass das System das USB-Gerät als Root-Besitzer einbindet, aber der Nut-Daemon mit einem unprivilegierten Konto arbeitet, das nicht über die notwendigen Rechte verfügt. Die einfache Lösung besteht eigentlich darin, udev zum Anpassen der Geräteberechtigungen zu verwenden. Gefunden habe ich diese Anpassung in '/lib/udev/rules.d/' in der Datei '62-nut-usbups.rules' ...

Welches konkrete device will er aus /dev denn dafür verwenden und wie sehen die Permissions dafür aus wenn du "ls -la /dev/XXXX" mal eingibst und schaust.

[wolwin]

Welches konkrete device will er aus /dev denn dafür verwenden und wie sehen die Permissions dafür aus wenn du "ls -la /dev/XXXX" mal eingibst und schaust.

Sieht eigentlich gut aus ... es wird 'nobody' aus '62-nut-usbups.rules' genommen ...

Code: Alles auswählen

root@RASPI-HM:~# lsusb
Bus 001 Device 006: ID 0781:5571
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 003: ID 0424:2514
Bus 001 Device 002: ID 0424:2514
Bus 001 Device 004: ID 0424:7800
Bus 001 Device 005: ID 051d:0002

UPS ist verbunden mit: Bus 001 Device 005: ID 051d:0002

Code: Alles auswählen

root@RASPI-HM:~# ls -la /dev/bus/usb/001/005
crw-rw-r--    1 root     nobody    189,   4 Apr  6 18:14 /dev/bus/usb/001/005

[jmaus]

Welches konkrete device will er aus /dev denn dafür verwenden und wie sehen die Permissions dafür aus wenn du "ls -la /dev/XXXX" mal eingibst und schaust.

Sieht eigentlich gut aus ... es wird 'nobody' aus '62-nut-usbups.rules' genommen ...
[...]

Code: Alles auswählen

root@RASPI-HM:~# ls -la /dev/bus/usb/001/005
crw-rw-r--    1 root     nobody    189,   4 Apr  6 18:14 /dev/bus/usb/001/005

Na dann liegt es ganz offensichtlich nicht an den persmissions, denn die NUT dienste sollte ja als "nobody" laufen und wie du siehst hat nobody als gruppe ja auch volle permissions auf das device.

[wolwin]

Na dann liegt es ganz offensichtlich nicht an den persmissions, denn die NUT dienste sollte ja als "nobody" laufen und wie du siehst hat nobody als gruppe ja auch volle permissions auf das device.

Stimmt ... ich habe an der Konsole verschieden Befehle mit dem 'usbhid-ups' Treiber durchgespielt - wenn ich die Befehlssequenz ändere, dann gibt es keine Fehlermeldung mehr und die UPS wird heruntergefahren:

Code: Alles auswählen

root@RASPI-HM:~# /usr/bin/usbhid-ups -k -a ups
Network UPS Tools - Generic HID driver 0.43 (2.7.4.1)
USB communication driver 0.33
Using subdriver: APC HID 0.96
Initiating UPS shutdown

...

[jmaus]

Stimmt ... ich habe an der Konsole verschieden Befehle mit dem 'usbhid-ups' Treiber durchgespielt - wenn ich die Befehlssequenz ändere, dann gibt es keine Fehlermeldung mehr und die UPS wird heruntergefahren:

Na wunderbar. Dann könntest du das am besten mal in ein komplettes HowTo bzw. Kurzdokumentation verwandeln, dann könnte man das in den Dokumentationswiki transferieren damit auch andere von deinen Erkenntnissen profitieren können. Und wer weiss, vllt. lässt sich davon ja was in RaspberryMatic direkt integrieren. Aber dazu müsstest du das ganze noch einmal komplett und sauber als Schritt-für-Schritt Anleitung zusammenfassen.

[wolwin]

Aber dazu müsstest du das ganze noch einmal komplett und sauber als Schritt-für-Schritt Anleitung zusammenfassen.

Ok, mach ich ... Zuerst muss ich jetzt noch das 'delayed timing' für das Herunterfahren der USV in den configs verifizieren und testen. Ist also noch etwas zu tun ... ich melde mich dann, damit auch andere vielleicht einen Gegencheck machen können.

Gruss
Wolfram

[Baxxy]

Interessant... und nützlich.
Ich habe mich schon immer gefragt wie man diese Problematik bewerkstelligt.

Bisher hatte ich Glück da die Stromausfälle so kurz waren das die RM nicht herunterfahren musste.

Gegencheck machen

Ich würde mir das dann definitiv mal anschauen.

Grüße, Baxxy

[wolwin]

Na dann liegt es ganz offensichtlich nicht an den persmissions, ...

Das seltsame Verhalten der USV mit dem RM-NUT-Server hat mich nicht ruhen lassen und ich habe heute nachmittag noch einmal den Debian-RASPI und 'funktionierenden' NUT-Server mit dem RM-NUT-Server detailiert ein zweites Mal verglichen und mehrfach einen Shutdown durchgeführt ... wieder nichts. Ich wollte schon aufgeben, als ich in einem G* Internet-Artikel den entscheidenen Hinweis gefunden habe.

• Beim Herunterfahren von NUT wird mit 'nutshutdown' und dem Befehl 'upsdrvctl shutdown' auch die USV heruntergefahren - auf dem Debian System funktioniert das problemlos, da zu diesem Zeitpunkt die Treiber-Instanz schon beendet ist.

• Anders beim RM-System - 'nutshutdown' wird in '/usr/local/etc/config/rc.d/' ausgeführt ... und zu diesem Zeitpunkt ist die Treiber-Instanz noch nicht beendet - ein nochmaliger Aufruf über 'upsdrvctl' führt dann zu einem (undefinierten) Fehler, der verhindert, dass die USV sich abschaltet.

Die Lösung ist wie immer - wenn man es weiss - einfach: vor dem 'upsdrvctl shutdown' Befehl muss mit ' 'upsdrvctl stop' die Treiber-Instanz beendet werden.

Hier das Listing der 'nutshutdown', die in ' /usr/local/etc/config/rc.d/' gelegt werden muss ... (könnte auch direkt so in die RM-Entwicklung übernommen werden):

Code: Alles auswählen

#!/bin/sh

# /usr/local/etc/config/rc.d/nutshutdown
# user-rights: 0755 - root [0]

case "$1" in
""|start)
  # RM Startup 
  ;;
stop)
  # RM Shutdown 
  # NUT-Original: /sbin/upsmon -K >/dev/null 2>&1 && /sbin/upsdrvctl shutdown
  # Test for the UPS shutdown flag
  if /usr/sbin/upsmon -K >/dev/null 2>&1; then
    # Stop UPS driver instance
    /usr/sbin/upsdrvctl stop
    sleep 2
    # Call UPS shutdown
    /usr/sbin/upsdrvctl shutdown
    # Send email 
    # /etc/config/addons/email/email 47
  fi
  ;;
esac

Mit dieser Änderung funktioniert jetzt auch das 'zeitgesteuerte' Herunterfahren der USV ... aber dazu später mehr ...

Gruss
Wolfram