Opened 3 years ago
Closed 2 years ago
#4908 closed Aufgabe (ungültig)
Proxmoxpaedml: Daemon für neue USV installieren
| Reported by: | Rüdiger Kupper | Owned by: | bau |
|---|---|---|---|
| Priority: | schnell erledigen | Milestone: | Schuljahr 2022/23 |
| Component: | Server: allgemein | Severity: | beeinträchtigt keinen Unterricht |
| Keywords: | Cc: | bau |
Description
Nach einem erneuten Spontanausfall der alten USV heute durch neues Fabrikat ersetzt. Benötigt andere Software für das kontrollierte Herunterfahren.
Change History (22)
comment:1 by , 3 years ago
| Owner: | changed from to |
|---|---|
| Priority: | normal → hoch |
| Status: | new → accepted |
| Summary: | ptoxmoxpaedml: Daemon für neue USV installieren → Daemon für neue USV installieren |
comment:2 by , 3 years ago
| Cc: | added |
|---|
comment:3 by , 3 years ago
| Summary: | Daemon für neue USV installieren → Proxmoxpaedml: Daemon für neue USV installieren |
|---|
comment:4 by , 3 years ago
Konfiguriere wie in AdminUsv beschrieben.
Auf gluster5,6 schmiert die Kommunikation nach einigen Stunden ab, prüfen, ob das hier auch passiert.
comment:6 by , 3 years ago
Nach der Installation startet der Dienst "nut-server" leider nicht. Bricht ab mit dem Fehler "dependency error". Was für eine Abhängigkeit fehlt, darüber schweigt sich das Log leider aus.
Auch ein "apt full-upgrade" ändert daran nichts.
comment:8 by , 3 years ago
- @bau
- Warum läuft der Dienst hier nicht? Liegt es an einer veralteten Proxmox-Version?
comment:9 by , 3 years ago
| Owner: | changed from to |
|---|---|
| Status: | accepted → assigned |
comment:10 by , 3 years ago
Das scheint mir tatsächlich der Fall -> neue ProxMox-Version installieren?
comment:11 by , 3 years ago
Wenn wir irgendwann auf die neue Linuxmusterlösung upgrade wollen stände das ohnehin an.
Eigenartig ist, dass der "dependency error" nicht vom Paketmanager kommt, sondern von systemd.
comment:12 by , 3 years ago
Ah, hier ist etwas, im log der Unit "nut-driver.service":
Aug 03 13:17:42 proxmoxpaedml upsdrvctl[31512]: Can't claim USB device [06da:ffff]: could not detach kernel driver from interface 0: Operation not permitted
Also kein Zugriff auf das USB-Device.
comment:13 by , 3 years ago
| Resolution: | → erledigt |
|---|---|
| Status: | assigned → closed |
Habe das Problem gefunden: Das nut-Paket, das auf dem proxmox installiert ist, bringt keine udev-Regeln mit (wie neuere Pakete). Habe die Regel von gluster5 rüberkopiert, jetzt bekommt das Device die Gruppe "nut" und der Dienst läuft.
Jetzt bin ich gespannt, ob das gleiche passiert wie auf gluster5,6, dass die Kommunikation irgendwann abbricht. Oder ob das ein Spezialproblem von gluster5,6 ist.
comment:15 by , 3 years ago
Bingo. Nach 4 Stunden ist auf proxmoxpaedml das selbe passiert: "Data for UPS [powerwalker] is stale - check driver".
Da haben wir wohl ein größeres Problem!
comment:16 by , 3 years ago
Der Fehler wird in vielen Foren berichtet. Empfohlen wird, den Parameter MAXAGE in upsd.conf zu erhöhen (von 15 auf 25). Siehe:
https://networkupstools.org/docs/man/upsd.conf.html
-> ausprobieren.
comment:17 by , 3 years ago
Habe MAXAGE nun auf proxmoxpaedml und gluster5,6 vom Default (15s) auf 25s erhöht. Irgendwie glaube ich aber nicht, dass das unser Problem löst. In den Foren ist von sporadischen Meldungen die Rede, bei uns läuft alle glatt bis zu einem Punkt und dann meldet sich der Treiber scheinbar gar nicht mehr.
comment:18 by , 3 years ago
| Resolution: | erledigt |
|---|---|
| Status: | closed → reopened |
comment:19 by , 3 years ago
Problem besteht weiter, nicht nur für paedml, sondern für alle Server mit Powerwalker-USV.
Querverweise:
comment:20 by , 3 years ago
Vor einiger Zeit habe ich diesbezüglich folgendes Forum gelesen:
https://serverfault.com/questions/994338/how-can-i-fix-my-ups-repeatedly-disconnecting-and-reconnecting
Den dort vorgeschlagenen Workaround (udev-Regel) habe ich angepasst auf proxmoxls5 implementiert. Es ist keine Lösung des Problems (dass sich das Device nach einiger Zeit abmeldet), sondern startet in diesem Fall lediglich den Treiber neu, so dass dis Kommunikation neu aufgebaut wird:
Datei /etc/udev/rules.d/62-nut-usbups-disconnect-fix.rules:
# Fix for our UPS keeping disconnecting and connecting.
# this file is in addition to /lib/udev/rules.d/62-nut-usbups.rules
# PROTECT B / NAS - usbhid-ups
ACTION=="add|change", SUBSYSTEM=="usb|usb_device", SUBSYSTEMS=="usb|usb_device", ATTR{idVendor}=="06da", ATTR{idProduct}=="ffff", MODE="664", GROUP="nut", RUN+="/sbin/upsdrvctl stop; /sbin/upsdrvctl start"
Leider funktioniert die Regel nicht, im Syslog steht diese Meldung:
2024-03-13T12:43:21.685205+01:00 proxmoxls5 (udev-worker)[3779130]: 4-2: Process '/sbin/upsdrvctl stop; /sbin/upsdrvctl start' failed with exit code 1. 2024-03-13T12:43:21.687605+01:00 proxmoxls5 (udev-worker)[3779131]: 4-2: Process '/sbin/upsdrvctl stop; /sbin/upsdrvctl start' failed with exit code 1.
=> schauen, was hier fehlschlägt.
comment:21 by , 3 years ago
Offenbar mag das udev unter Ubuntu nicht, wenn in RUN+ mehrere Befehle hintereinander übergeben werden. Man kann stattdessen einfach zwei RUN+hintereinander schreiben:
# Fix for our UPS keeping disconnecting and connecting.
# this file is in addition to /lib/udev/rules.d/62-nut-usbups.rules
# PROTECT B / NAS - usbhid-ups
ACTION=="add|change", SUBSYSTEM=="usb|usb_device", SUBSYSTEMS=="usb|usb_device", ATTR{idVendor}=="06da", ATTR{idProduct}=="ffff", MODE="664", GROUP="nut", RUN+="/sbin/upsdrvctl stop", RUN+="/sbin/upsdrvctl start"
Mal sehen, ob die Regel nun auf proxmoxls5 macht, was sie soll.
comment:22 by , 2 years ago
| Resolution: | → ungültig |
|---|---|
| Status: | reopened → closed |
Betrifft:
Welchen Treiber brauchen wir? Gibt es den über das normale Paketmanagement?