Debian-facile
Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.
Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#26 17-12-2021 04:06:16
- Sty_X
- Membre
- Inscription : 14-02-2021
Re : Problème de communication nut/onduleur
Non comment ça pour le fichier "upsd-users" ??
Tu n'as aucune référence à un "upssched" dans le fichier "upsmon.conf" ?
Tu n'as aucune référence à un "upssched" dans le fichier "upsmon.conf" ?
Hors ligne
#27 17-12-2021 05:54:47
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
non rien pour upssched
#upsmon.conf
#Ce fichier contient des mots de passe, alors gardez-le en sécurité.
#Par défaut, upsmon se divise en deux processus.
#en tant que root et attend d'exécuter le SHUTDOWNCMD.
#L'autre passe à un autre userid et fait tout le reste.
#L'utilisateur non privilégié par défaut est défini au moment de la compilation avec
# 'configurer --with-user=...'.
#Vous pouvez le remplacer par '-u <user>' lors du démarrage d'upsmon, ou simplement
#définissez-le ici pour plus de commodité.
# RUN_AS_USER <userid>
#Remarque : si vous prévoyez d'utiliser la fonction de rechargement, ce fichier (upsmon.conf)
#doit être lisible par cet utilisateur ! Puisqu'il contient des mots de passe, NE PAS
#le rendre lisible par tout le monde. Aussi, ne le rendez pas inscriptible par l'upsmon
# "utilisateur", car il crée une opportunité d'attaque en changeant le
#SHUTDOWNCMD à quelque chose de malveillant.
#Pour de meilleurs résultats, vous devez créer un nouvel utilisateur normal comme "nutmon",
#et en faire un membre d'un groupe "nut" ou similaire.
#Ensuite, spécifiez-le ici et accordez un accès en lecture à upsmon.conf pour ce groupe.
#Cet utilisateur ne doit pas avoir accès en écriture à upsmon.conf.
# RUN_AS_USER nut
#Indiquez le nombre d'alimentations qui doivent être alimentées pour maintenir
#ce système en marche. La plupart des systèmes n'ont qu'une seule alimentation, vous devez donc
#mettre "1" dans ce champ.
MINSUPPLIES 1
#upsmon exécute cette commande lorsque le système doit être arrêté.
#Cela devrait fonctionner, si ce n'est pas le cas, changez-le.
SHUTDOWNCMD "/sbin/shutdown -h +0"
#upsmon appelle ceci pour envoyer des messages lorsque des choses se produisent
#Cette commande est appelée avec le texte complet du message comme argument.
#La chaîne d'environnement NOTIFYTYPE contiendra la chaîne de type de
#quelle que soit la cause de cet événement.
#Notez que cela n'est appelé que pour les événements NOTIFY qui ont EXEC défini avec
#NOTIFYFLAG. Voir NOTIFYFLAG ci-dessous pour plus de détails.
#voir la doc
#Exemple:
#NOTIFYCMD /bin/notifyme
#Fréquence d'interrogation pour les activités normales, mesurée en secondes.
#Ajustez ceci pour empêcher upsmon d'inonder votre réseau,
#trop élevé ou il peut manquer certains événements de puissance de courte durée.
POLLFREQ 5
#Fréquence d'interrogation en secondes pendant que l'onduleur est sur batterie.
#Vous pouvez réduire ce nombre à POLLFREQ, ce qui accélérera les mises à jour
#lorsqu'un onduleur fonctionne sur batterie. C'est un bon moyen de régler
#la charge du réseau si vous avez beaucoup de ces choses en cours d'exécution.
#La valeur par défaut est de 5 secondes pour cela et pour POLLFREQ.
POLLFREQALERT 5
#HOSTSYNC - Combien de temps upsmon attendra avant d'abandonner un autre upsmon
# maitre/esclave voir doc
HOSTSYNC 15
#"DEADTIME - Intervalle d'attente avant de déclarer un onduleur "HS"
#upsmon nécessite qu'un onduleur fournisse des informations d'état
#toutes les quelques secondes
#valeur 15 = 3x5 (POLLFREQ 5 et POLLFREQALERT 5)
DEADTIME 15
#POWERDOWNFLAG
#Fichier indicateur pour forcer l'arrêt de l'onduleur sur le système maître
#upsmon créera un fichier avec ce nom en mode maître quand il sera temps
#pour arrêter la charge. Vous devriez vérifier l'existence de ce fichier dans
#vos scripts d'arrêt et exécutez 'upsdrvctl shutdown' s'il existe.
POWERDOWNFLAG /etc/killpower
#voir la doc pour option "NOTIFYMSG"
#ou le script original
# NOTIFYMSG - modifier les messages envoyés par upsmon
# lorsque certains événements se produisent
# Vous pouvez changer les messages par défaut
# en autre chose si vous le souhaitez.
# NOTIFYMSG <notify type> "message"
# NOTIFYMSG ONLINE "UPS %s on line power"
# NOTIFYMSG ONBATT "UPS %s on battery"
# NOTIFYMSG LOWBATT "UPS %s battery is low"
# NOTIFYMSG FSD "UPS %s: forced shutdown in progress"
# NOTIFYMSG COMMOK "Communications with UPS %s established"
# NOTIFYMSG COMMBAD "Communications with UPS %s lost"
# NOTIFYMSG SHUTDOWN "Auto logout and shutdown proceeding"
# NOTIFYMSG REPLBATT "UPS %s battery needs to be replaced"
# NOTIFYMSG NOCOMM "UPS %s is unavailable"
# NOTIFYMSG NOPARENT "upsmon parent process died - shutdown impossible"
# Note that %s is replaced with the identifier of the UPS in question.
# Valeurs possibles pour <type de notification> :
# ONLINE : UPS is back online
# ONBATT : UPS is on battery
# LOWBATT : UPS has a low battery (if also on battery, it's "critical")
# FSD : UPS is being shutdown by the master (FSD = "Forced Shutdown")
# COMMOK : Communications established with the UPS
# COMMBAD : Communications lost to the UPS
# SHUTDOWN : The system is being shutdown
# REPLBATT : The UPS battery is bad and needs to be replaced
# NOCOMM : A UPS is unavailable (can't be contacted for monitoring)
# NOPARENT : The process that shuts down the system has died (shutdown impossible)
#NOTIFYFLAG - modifier le comportement d'upsmon lorsque des événements NOTIFY se produisent
#Par défaut, upsmon envoie des messages (messages globaux à tous les utilisateurs connectés)
#et écrit dans le syslog lorsque des choses se produisent. Vous pouvez changer cela.
# NOTIFYFLAG <notify type> <flag>[+<flag>][+<flag>] ...
#
# NOTIFYFLAG ONLINE SYSLOG+WALL
# NOTIFYFLAG ONBATT SYSLOG+WALL
# NOTIFYFLAG LOWBATT SYSLOG+WALL
# NOTIFYFLAG FSD SYSLOG+WALL
# NOTIFYFLAG COMMOK SYSLOG+WALL
# NOTIFYFLAG COMMBAD SYSLOG+WALL
# NOTIFYFLAG SHUTDOWN SYSLOG+WALL
# NOTIFYFLAG REPLBATT SYSLOG+WALL
# NOTIFYFLAG NOCOMM SYSLOG+WALL
# NOTIFYFLAG NOPARENT SYSLOG+WALL
#
# Possible values for the flags:
#
# SYSLOG - Write the message in the syslog
# WALL - Write the message to all users on the system
# EXEC - Execute NOTIFYCMD (see above) with the message
# IGNORE - Don't do anything
# Si vous utilisez IGNORE, n'utilisez aucun autre indicateur sur la même ligne.
#RBWARNTIME - délai d'avertissement de remplacement de la batterie en secondes
#upsmon vous avertira normalement d'une batterie qui doit être remplacée
#toutes les 43 200 secondes, soit 12 heures. Il le fait en déclenchant un
#NOTIFY_REPLBATT qui est ensuite géré par la structure de notification habituelle
RBWARNTIME 43200
#NOCOMMWARNTIME - aucun délai d'avertissement de communication en secondes
#upsmon vous informera via le système de notification habituel s'il ne peut pas
#parlez à l'une des entrées UPS définies dans ce fichier. Ce sera
#déclencher un NOTIFY_NOCOMM par défaut toutes les 300 secondes
NOCOMMWARNTIME 300
#FINALDELAY - dernier intervalle de veille avant l'arrêt du système
#Sur un maître, upsmon attendra aussi longtemps après avoir envoyé le NOTIFY_SHUTDOWN
#avant d'exécuter votre SHUTDOWNCMD. Si vous avez besoin de faire quelque chose entre
#ces événements, augmenter ce nombre. N'oubliez pas qu'à ce stade, votre UPS est
#presque épuisé, alors ne le faites pas trop haut.
#Alternativement, vous pouvez régler cela très bas afin de ne pas attendre quand
#il est temps de fermer. Certains onduleurs ne donnent pas beaucoup d'avertissement en cas de faible
#batterie et nécessitera une valeur de 0 ici pour un arrêt en toute sécurité.
FINALDELAY 5
#voir la doc pour "CERTPATH" et autres
# CERTPATH /etc/nut/cert/upsmon
# CERTPATH /usr/ssl/certs
# CERTIDENT "my nut monitor" "MyPasSw0rD"
# CERTHOST localhost "My nut server" 1 1
# CERTVERIFY 1
#upsmon.conf
#Ce fichier contient des mots de passe, alors gardez-le en sécurité.
#Par défaut, upsmon se divise en deux processus.
#en tant que root et attend d'exécuter le SHUTDOWNCMD.
#L'autre passe à un autre userid et fait tout le reste.
#L'utilisateur non privilégié par défaut est défini au moment de la compilation avec
# 'configurer --with-user=...'.
#Vous pouvez le remplacer par '-u <user>' lors du démarrage d'upsmon, ou simplement
#définissez-le ici pour plus de commodité.
# RUN_AS_USER <userid>
#Remarque : si vous prévoyez d'utiliser la fonction de rechargement, ce fichier (upsmon.conf)
#doit être lisible par cet utilisateur ! Puisqu'il contient des mots de passe, NE PAS
#le rendre lisible par tout le monde. Aussi, ne le rendez pas inscriptible par l'upsmon
# "utilisateur", car il crée une opportunité d'attaque en changeant le
#SHUTDOWNCMD à quelque chose de malveillant.
#Pour de meilleurs résultats, vous devez créer un nouvel utilisateur normal comme "nutmon",
#et en faire un membre d'un groupe "nut" ou similaire.
#Ensuite, spécifiez-le ici et accordez un accès en lecture à upsmon.conf pour ce groupe.
#Cet utilisateur ne doit pas avoir accès en écriture à upsmon.conf.
# RUN_AS_USER nut
#Indiquez le nombre d'alimentations qui doivent être alimentées pour maintenir
#ce système en marche. La plupart des systèmes n'ont qu'une seule alimentation, vous devez donc
#mettre "1" dans ce champ.
MINSUPPLIES 1
#upsmon exécute cette commande lorsque le système doit être arrêté.
#Cela devrait fonctionner, si ce n'est pas le cas, changez-le.
SHUTDOWNCMD "/sbin/shutdown -h +0"
#upsmon appelle ceci pour envoyer des messages lorsque des choses se produisent
#Cette commande est appelée avec le texte complet du message comme argument.
#La chaîne d'environnement NOTIFYTYPE contiendra la chaîne de type de
#quelle que soit la cause de cet événement.
#Notez que cela n'est appelé que pour les événements NOTIFY qui ont EXEC défini avec
#NOTIFYFLAG. Voir NOTIFYFLAG ci-dessous pour plus de détails.
#voir la doc
#Exemple:
#NOTIFYCMD /bin/notifyme
#Fréquence d'interrogation pour les activités normales, mesurée en secondes.
#Ajustez ceci pour empêcher upsmon d'inonder votre réseau,
#trop élevé ou il peut manquer certains événements de puissance de courte durée.
POLLFREQ 5
#Fréquence d'interrogation en secondes pendant que l'onduleur est sur batterie.
#Vous pouvez réduire ce nombre à POLLFREQ, ce qui accélérera les mises à jour
#lorsqu'un onduleur fonctionne sur batterie. C'est un bon moyen de régler
#la charge du réseau si vous avez beaucoup de ces choses en cours d'exécution.
#La valeur par défaut est de 5 secondes pour cela et pour POLLFREQ.
POLLFREQALERT 5
#HOSTSYNC - Combien de temps upsmon attendra avant d'abandonner un autre upsmon
# maitre/esclave voir doc
HOSTSYNC 15
#"DEADTIME - Intervalle d'attente avant de déclarer un onduleur "HS"
#upsmon nécessite qu'un onduleur fournisse des informations d'état
#toutes les quelques secondes
#valeur 15 = 3x5 (POLLFREQ 5 et POLLFREQALERT 5)
DEADTIME 15
#POWERDOWNFLAG
#Fichier indicateur pour forcer l'arrêt de l'onduleur sur le système maître
#upsmon créera un fichier avec ce nom en mode maître quand il sera temps
#pour arrêter la charge. Vous devriez vérifier l'existence de ce fichier dans
#vos scripts d'arrêt et exécutez 'upsdrvctl shutdown' s'il existe.
POWERDOWNFLAG /etc/killpower
#voir la doc pour option "NOTIFYMSG"
#ou le script original
# NOTIFYMSG - modifier les messages envoyés par upsmon
# lorsque certains événements se produisent
# Vous pouvez changer les messages par défaut
# en autre chose si vous le souhaitez.
# NOTIFYMSG <notify type> "message"
# NOTIFYMSG ONLINE "UPS %s on line power"
# NOTIFYMSG ONBATT "UPS %s on battery"
# NOTIFYMSG LOWBATT "UPS %s battery is low"
# NOTIFYMSG FSD "UPS %s: forced shutdown in progress"
# NOTIFYMSG COMMOK "Communications with UPS %s established"
# NOTIFYMSG COMMBAD "Communications with UPS %s lost"
# NOTIFYMSG SHUTDOWN "Auto logout and shutdown proceeding"
# NOTIFYMSG REPLBATT "UPS %s battery needs to be replaced"
# NOTIFYMSG NOCOMM "UPS %s is unavailable"
# NOTIFYMSG NOPARENT "upsmon parent process died - shutdown impossible"
# Note that %s is replaced with the identifier of the UPS in question.
# Valeurs possibles pour <type de notification> :
# ONLINE : UPS is back online
# ONBATT : UPS is on battery
# LOWBATT : UPS has a low battery (if also on battery, it's "critical")
# FSD : UPS is being shutdown by the master (FSD = "Forced Shutdown")
# COMMOK : Communications established with the UPS
# COMMBAD : Communications lost to the UPS
# SHUTDOWN : The system is being shutdown
# REPLBATT : The UPS battery is bad and needs to be replaced
# NOCOMM : A UPS is unavailable (can't be contacted for monitoring)
# NOPARENT : The process that shuts down the system has died (shutdown impossible)
#NOTIFYFLAG - modifier le comportement d'upsmon lorsque des événements NOTIFY se produisent
#Par défaut, upsmon envoie des messages (messages globaux à tous les utilisateurs connectés)
#et écrit dans le syslog lorsque des choses se produisent. Vous pouvez changer cela.
# NOTIFYFLAG <notify type> <flag>[+<flag>][+<flag>] ...
#
# NOTIFYFLAG ONLINE SYSLOG+WALL
# NOTIFYFLAG ONBATT SYSLOG+WALL
# NOTIFYFLAG LOWBATT SYSLOG+WALL
# NOTIFYFLAG FSD SYSLOG+WALL
# NOTIFYFLAG COMMOK SYSLOG+WALL
# NOTIFYFLAG COMMBAD SYSLOG+WALL
# NOTIFYFLAG SHUTDOWN SYSLOG+WALL
# NOTIFYFLAG REPLBATT SYSLOG+WALL
# NOTIFYFLAG NOCOMM SYSLOG+WALL
# NOTIFYFLAG NOPARENT SYSLOG+WALL
#
# Possible values for the flags:
#
# SYSLOG - Write the message in the syslog
# WALL - Write the message to all users on the system
# EXEC - Execute NOTIFYCMD (see above) with the message
# IGNORE - Don't do anything
# Si vous utilisez IGNORE, n'utilisez aucun autre indicateur sur la même ligne.
#RBWARNTIME - délai d'avertissement de remplacement de la batterie en secondes
#upsmon vous avertira normalement d'une batterie qui doit être remplacée
#toutes les 43 200 secondes, soit 12 heures. Il le fait en déclenchant un
#NOTIFY_REPLBATT qui est ensuite géré par la structure de notification habituelle
RBWARNTIME 43200
#NOCOMMWARNTIME - aucun délai d'avertissement de communication en secondes
#upsmon vous informera via le système de notification habituel s'il ne peut pas
#parlez à l'une des entrées UPS définies dans ce fichier. Ce sera
#déclencher un NOTIFY_NOCOMM par défaut toutes les 300 secondes
NOCOMMWARNTIME 300
#FINALDELAY - dernier intervalle de veille avant l'arrêt du système
#Sur un maître, upsmon attendra aussi longtemps après avoir envoyé le NOTIFY_SHUTDOWN
#avant d'exécuter votre SHUTDOWNCMD. Si vous avez besoin de faire quelque chose entre
#ces événements, augmenter ce nombre. N'oubliez pas qu'à ce stade, votre UPS est
#presque épuisé, alors ne le faites pas trop haut.
#Alternativement, vous pouvez régler cela très bas afin de ne pas attendre quand
#il est temps de fermer. Certains onduleurs ne donnent pas beaucoup d'avertissement en cas de faible
#batterie et nécessitera une valeur de 0 ici pour un arrêt en toute sécurité.
FINALDELAY 5
#voir la doc pour "CERTPATH" et autres
# CERTPATH /etc/nut/cert/upsmon
# CERTPATH /usr/ssl/certs
# CERTIDENT "my nut monitor" "MyPasSw0rD"
# CERTHOST localhost "My nut server" 1 1
# CERTVERIFY 1
dans /sbin/ j'ai 2 scripts "upsd" et "upsmon" et 2 binaires "upsdrvctl" et "upssched"
Dernière modification par anonyme (17-12-2021 06:06:30)
#28 17-12-2021 11:38:35
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
Bonjour
pour faciliter la prise en compte du driver
Il s'agit probablement d'un problème avec les autorisations d'accès à l'appareil.
Vous pouvez résoudre ce problème en spécifiant une règle udev qui définit le groupe correct :
exemple:
lsusb => [ 5.617019] usb 1-11: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 1.00
/etc/udev/rules.d/50-ups.rules (=> fichier a créer 50-ups.rules )
et copier/coller la ligne ci dessous
SUBSYSTEM=="usb", ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", GROUP="nut"
SUBSYSTEM=="usb", ATTR{idVendor}=="xxxx", ATTR{idProduct}=="yyyy", GROUP="nut"
Où XXXX et YYYY sont le fabricant de l'appareil et les ID de produit.
Vous pouvez les voir soit dans la sortie d'erreur ([XXXX:YYYY]) soit en utilisant lsusb.
udevadm control --reload-rules
udevadm trigger
pour faciliter la prise en compte du driver
Il s'agit probablement d'un problème avec les autorisations d'accès à l'appareil.
Vous pouvez résoudre ce problème en spécifiant une règle udev qui définit le groupe correct :
exemple:
lsusb => [ 5.617019] usb 1-11: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 1.00
/etc/udev/rules.d/50-ups.rules (=> fichier a créer 50-ups.rules )
et copier/coller la ligne ci dessous
SUBSYSTEM=="usb", ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", GROUP="nut"
explication (avec le retour de lsusb par exemple )
SUBSYSTEM=="usb", ATTR{idVendor}=="xxxx", ATTR{idProduct}=="yyyy", GROUP="nut"
Où XXXX et YYYY sont le fabricant de l'appareil et les ID de produit.
Vous pouvez les voir soit dans la sortie d'erreur ([XXXX:YYYY]) soit en utilisant lsusb.
Une fois cela fait, rechargez et relancez les règles udev en exécutant :
udevadm control --reload-rules
udevadm trigger
je garanti pas que ça fonctionne 
ps: l'onduleur pour moi est en cour de livraison entre 8h et 18h 
Dernière modification par anonyme (17-12-2021 11:41:15)
#29 17-12-2021 13:01:55
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
status nut-driver.service
retour
● nut-driver.service - Network UPS Tools - power device driver controller
Loaded: loaded (/lib/systemd/system/nut-driver.service; static)
Active: active (running) since Fri 2021-12-17 11:44:53 CET; 1min 49s ago
Process: 509 ExecStart=/sbin/upsdrvctl start (code=exited, status=0/SUCCESS)
Main PID: 807 (usbhid-ups)
Tasks: 1 (limit: 19033)
Memory: 1.2M
CPU: 377ms
CGroup: /system.slice/nut-driver.service
└─807 /lib/nut/usbhid-ups -a Eaton
déc. 17 11:44:46 debian2 systemd[1]: Starting Network UPS Tools - power device driver controller...
déc. 17 11:44:51 debian2 upsdrvctl[520]: Using subdriver: MGE HID 1.40
déc. 17 11:44:52 debian2 upsdrvctl[520]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
déc. 17 11:44:52 debian2 upsdrvctl[520]: USB communication driver 0.33
déc. 17 11:44:53 debian2 usbhid-ups[807]: Startup successful
déc. 17 11:44:53 debian2 upsdrvctl[509]: Network UPS Tools - UPS driver controller 2.7.4
déc. 17 11:44:53 debian2 systemd[1]: Started Network UPS Tools - power device driver controller.
systemctl status nut-monitor.service
retour
● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller
Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-12-17 11:44:54 CET; 3min 23s ago
Process: 814 ExecStart=/sbin/upsmon (code=exited, status=0/SUCCESS)
Main PID: 816 (upsmon)
Tasks: 2 (limit: 19033)
Memory: 2.9M
CPU: 25ms
CGroup: /system.slice/nut-monitor.service
├─815 /lib/nut/upsmon
└─816 /lib/nut/upsmon
déc. 17 11:44:54 debian2 systemd[1]: Starting Network UPS Tools - power device monitor and shutdown controller...
déc. 17 11:44:54 debian2 upsmon[814]: fopen /run/nut/upsmon.pid: No such file or directory
déc. 17 11:44:54 debian2 upsmon[814]: UPS: Eaton@localhost (master) (power value 1)
déc. 17 11:44:54 debian2 upsmon[814]: Using power down flag file /etc/killpower
déc. 17 11:44:54 debian2 upsmon[815]: Startup successful
déc. 17 11:44:54 debian2 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: Operation not permitted
déc. 17 11:44:54 debian2 systemd[1]: nut-monitor.service: Supervising process 816 which is not our child. We'll most likely not notice when i>
déc. 17 11:44:54 debian2 systemd[1]: Started Network UPS Tools - power device monitor and shutdown controller.
déc. 17 11:44:54 debian2 upsmon[816]: Init SSL without certificate database
systemctl status nut-server.service
retour
● nut-server.service - Network UPS Tools - power devices information server
Loaded: loaded (/lib/systemd/system/nut-server.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-12-17 11:44:54 CET; 4min 19s ago
Process: 808 ExecStart=/sbin/upsd (code=exited, status=0/SUCCESS)
Main PID: 813 (upsd)
Tasks: 1 (limit: 19033)
Memory: 1.2M
CPU: 30ms
CGroup: /system.slice/nut-server.service
└─813 /lib/nut/upsd
déc. 17 11:44:53 debian2 systemd[1]: Starting Network UPS Tools - power devices information server...
déc. 17 11:44:53 debian2 upsd[808]: fopen /run/nut/upsd.pid: No such file or directory
déc. 17 11:44:53 debian2 upsd[808]: listening on 127.0.0.1 port 3493
déc. 17 11:44:53 debian2 upsd[808]: listening on 127.0.0.1 port 3493
déc. 17 11:44:53 debian2 upsd[808]: Connected to UPS [Eaton]: usbhid-ups-Eaton
déc. 17 11:44:53 debian2 upsd[808]: Connected to UPS [Eaton]: usbhid-ups-Eaton
déc. 17 11:44:54 debian2 upsd[813]: Startup successful
déc. 17 11:44:54 debian2 systemd[1]: Started Network UPS Tools - power devices information server.
déc. 17 11:44:55 debian2 upsd[813]: User eaton@127.0.0.1 logged into UPS [Eaton]
lsusb
retour (j'ai exactement le même que toi)
Bus 005 Device 002: ID 0463:ffff MGE UPS Systems UPS
sinon j'ai un souci au démarrage de l'ordinateur (si onduleur branché)
et je n'ai pas d'option activé sur le script
fopen /run/nut/upsmon.pid: No such file or directory
déc. 17 11:44:54 debian2 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: Operation not permitted
déc. 17 11:44:54 debian2 systemd[1]: nut-monitor.service: Supervising process 816 which is not our child. We'll most likely not notice when i>
#30 17-12-2021 13:34:49
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
tout est a peu près correct , sauf que onduleur branché , ça me bloque le démarrage
upsc Eaton
Init SSL without certificate database
battery.charge: 90
battery.charge.low: 20
battery.runtime: 3024
battery.type: PbAc
device.mfr: EATON
device.model: Eaton 3S 850
device.serial: Blank
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: MGE HID 1.40
driver.version.internal: 0.41
input.transfer.high: 264
input.transfer.low: 184
outlet.1.desc: PowerShare Outlet 1
outlet.1.id: 1
outlet.1.status: on
outlet.1.switchable: no
outlet.desc: Main Outlet
outlet.id: 0
outlet.switchable: yes
output.frequency.nominal: 50
output.voltage: 230.0
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 02.08.0010
ups.load: 5
ups.mfr: EATON
ups.model: Eaton 3S 850
ups.power.nominal: 850
ups.productid: ffff
ups.serial: Blank
ups.status: OL OFF
ups.timer.shutdown: 0
ups.timer.start: 0
ups.type: offline / line interactive
ups.vendorid: 0463
upsc Eaton
retour
Init SSL without certificate database
battery.charge: 90
battery.charge.low: 20
battery.runtime: 3024
battery.type: PbAc
device.mfr: EATON
device.model: Eaton 3S 850
device.serial: Blank
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: MGE HID 1.40
driver.version.internal: 0.41
input.transfer.high: 264
input.transfer.low: 184
outlet.1.desc: PowerShare Outlet 1
outlet.1.id: 1
outlet.1.status: on
outlet.1.switchable: no
outlet.desc: Main Outlet
outlet.id: 0
outlet.switchable: yes
output.frequency.nominal: 50
output.voltage: 230.0
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 02.08.0010
ups.load: 5
ups.mfr: EATON
ups.model: Eaton 3S 850
ups.power.nominal: 850
ups.productid: ffff
ups.serial: Blank
ups.status: OL OFF
ups.timer.shutdown: 0
ups.timer.start: 0
ups.type: offline / line interactive
ups.vendorid: 0463
on verra ça plus tard
on va pouvoir s'occuper de ton souci plus sérieusement 
#31 17-12-2021 19:29:48
- Sty_X
- Membre
- Inscription : 14-02-2021
Re : Problème de communication nut/onduleur
Merci pour ton aide ! Mais tu n'as quand même pas acheté un onduleur exprès pour cela quand même ??
Bon bon bon... Depuis la désinstallation / réinstallation j'ai des soucis qui se sont rajoutés... Avant il y avait ce soucis au niveau du driver qui ne se lançait pas au démarrage. Mais après avoir lancé manuellement avec "upsdrvctl start" tout fonctionnait ensuite (déclenchement de différents minuteurs pour envoie de mail puis extinction).
Maintenant, en reproduisant la configuration qui fonctionnait précédemment, les minuteurs qui se déclenchaient auparavant (via /etc/nut/upssched.conf et /bin/upssched-com) ne se déclenchent plus... Dans les log j'ai juste une alerte pour me dire que l'ups est sur batterie.
Lors de la désinstallation via "apt remove --purge nut" j'ai ensuite viré les fichiers de conf manuellement mais ce qui est étrange c'est que la première installation avaient créé ses fichiers (ou alors sont-ils présents de bases dans debian ?) et que la seconde installation ne les a pas recrée. Je me demande si la désinstallation / réinstallation n'a pas foutu la merde... J'aimerais bien repartir sur quelque-chose de vraiment propre pour ensuite être sur que les bug ne viennent pas d'une désinstallation/réinstallation pas clean ou d'un fichier/script qui traîne encore quelque part.
Bon bon bon... Depuis la désinstallation / réinstallation j'ai des soucis qui se sont rajoutés... Avant il y avait ce soucis au niveau du driver qui ne se lançait pas au démarrage. Mais après avoir lancé manuellement avec "upsdrvctl start" tout fonctionnait ensuite (déclenchement de différents minuteurs pour envoie de mail puis extinction).
Maintenant, en reproduisant la configuration qui fonctionnait précédemment, les minuteurs qui se déclenchaient auparavant (via /etc/nut/upssched.conf et /bin/upssched-com) ne se déclenchent plus... Dans les log j'ai juste une alerte pour me dire que l'ups est sur batterie.
Lors de la désinstallation via "apt remove --purge nut" j'ai ensuite viré les fichiers de conf manuellement mais ce qui est étrange c'est que la première installation avaient créé ses fichiers (ou alors sont-ils présents de bases dans debian ?) et que la seconde installation ne les a pas recrée. Je me demande si la désinstallation / réinstallation n'a pas foutu la merde... J'aimerais bien repartir sur quelque-chose de vraiment propre pour ensuite être sur que les bug ne viennent pas d'une désinstallation/réinstallation pas clean ou d'un fichier/script qui traîne encore quelque part.
Hors ligne
#32 17-12-2021 20:29:39
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
Bonjour
alors pour moi , le noyau de sid , la machine ne démarre plus
j'ai installé le noyau de bullseye , le 5.10.xx
2 erreurs que je n'arrive pas a supprimer
déc. 17 19:08:16 debian2 upsd[768]: fopen /run/nut/upsd.pid: No such file or directory
déc. 17 19:08:16 debian2 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: Operation not permitted
uname -a
Linux debian2 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
systemctl status nut-driver.service
● nut-driver.service - Network UPS Tools - power device driver controller
Loaded: loaded (/lib/systemd/system/nut-driver.service; static)
Active: active (running) since Fri 2021-12-17 19:08:14 CET; 27min ago
Process: 484 ExecStart=/sbin/upsdrvctl start (code=exited, status=0/SUCCESS)
Main PID: 767 (usbhid-ups)
Tasks: 1 (limit: 19044)
Memory: 1.1M
CPU: 5.303s
CGroup: /system.slice/nut-driver.service
└─767 /lib/nut/usbhid-ups -a Eaton
déc. 17 19:08:08 debian2 systemd[1]: Starting Network UPS Tools - power device driver controller...
déc. 17 19:08:13 debian2 upsdrvctl[492]: Using subdriver: MGE HID 1.40
déc. 17 19:08:13 debian2 upsdrvctl[492]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
déc. 17 19:08:13 debian2 upsdrvctl[492]: USB communication driver 0.33
déc. 17 19:08:14 debian2 usbhid-ups[767]: Startup successful
déc. 17 19:08:14 debian2 upsdrvctl[484]: Network UPS Tools - UPS driver controller 2.7.4
déc. 17 19:08:14 debian2 systemd[1]: Started Network UPS Tools - power device driver controller.
Bus 009 Device 003: ID 0463:ffff MGE UPS Systems UPS
alors pour moi , le noyau de sid , la machine ne démarre plus
j'ai installé le noyau de bullseye , le 5.10.xx
2 erreurs que je n'arrive pas a supprimer
déc. 17 19:08:16 debian2 upsd[768]: fopen /run/nut/upsd.pid: No such file or directory
et
déc. 17 19:08:16 debian2 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: Operation not permitted
non je suis a la campagne , et je n'avais plus d'onduleur , mais je pense que je vais l'utiliser sur la livebox "et ou" window10 que je n'utilise pas
sur debian pas terrible (avec Nut)
tout fonctionne a part ce que je marque au dessus (même l'arret du PC )
avec le changement du noyau (du 5.15 au 5.10) , j'ai retiré aussi apparmor
pour le driver j'ai appliqué le #28 ça change rien (vue que cela fonctionné avant pour le driver )
mon onduleur se nomme Eaton , mon user eaton (avec son mdp) ajouté au groupe nut
il y a peut être mieux comme logiciel , le Bureau Mate me donne de temps en temps le niveau de batterie (si le cordon usb n'est pas branché au démarrage mais plus tard)
donc tu a toujours le driver qui ne ce charge pas ?
ps:j'ajoute aucune notification sur le bureau , l'arrêt est sauvage
j'ai le même noyau que toi
uname -a
Linux debian2 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
et le driver
systemctl status nut-driver.service
● nut-driver.service - Network UPS Tools - power device driver controller
Loaded: loaded (/lib/systemd/system/nut-driver.service; static)
Active: active (running) since Fri 2021-12-17 19:08:14 CET; 27min ago
Process: 484 ExecStart=/sbin/upsdrvctl start (code=exited, status=0/SUCCESS)
Main PID: 767 (usbhid-ups)
Tasks: 1 (limit: 19044)
Memory: 1.1M
CPU: 5.303s
CGroup: /system.slice/nut-driver.service
└─767 /lib/nut/usbhid-ups -a Eaton
déc. 17 19:08:08 debian2 systemd[1]: Starting Network UPS Tools - power device driver controller...
déc. 17 19:08:13 debian2 upsdrvctl[492]: Using subdriver: MGE HID 1.40
déc. 17 19:08:13 debian2 upsdrvctl[492]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
déc. 17 19:08:13 debian2 upsdrvctl[492]: USB communication driver 0.33
déc. 17 19:08:14 debian2 usbhid-ups[767]: Startup successful
déc. 17 19:08:14 debian2 upsdrvctl[484]: Network UPS Tools - UPS driver controller 2.7.4
déc. 17 19:08:14 debian2 systemd[1]: Started Network UPS Tools - power device driver controller.
un souci avec ton type d'onduleur ? , il semble que ce soit le même
Bus 009 Device 003: ID 0463:ffff MGE UPS Systems UPS
un bon lien de cette année => https://wiki.archlinux.org/title/Network_UPS_Tools
Dernière modification par anonyme (17-12-2021 20:41:05)
#33 18-12-2021 09:53:43
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
Bonjour
on va comparer nos scripts peut être ?
j'ai activé le mode synchrone , correct
driver.parameter.synchronous: yes
on va comparer nos scripts peut être ?
j'ai activé le mode synchrone , correct
driver.parameter.synchronous: yes
tester un autre noyau ? (un souci avec l'actuel)
moi j'ai 2 soucis , le noyau de sid (démarrage bloqué de la machine ) et 2 pids qui génère une erreur (nut-server et nut-monitor)
mais bon tout semble correct
dans /etc/default/ je n'ai rien pour "nut"
j'ai forcé les "pids" dans /run/nut ( un lien virtuel sur le dossier /var/run/nut )
ton #31 pas logique , les scripts sont dans /etc/nut/ , je vais chercher encore , mais je pense pas en trouver ailleurs
pour apparmor et selinux j'ai enlevé ce que je pouvais , mais a priori pas de blocage sur nut
les dossiers /bin , /sbin et /lib sont lié dans /usr/ (lien symbolique ).
dans le /home rien pour "nut"
#34 19-12-2021 06:29:25
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
Bonjour
j'ai désinstallé Nut et purgé , il me reste juste le groupe "nut" et l'utilisateur "nutmon" qui est aussi dans le groupe "nut"
tout le reste a disparut
pour le noyau (kernel) il connaît l'onduleur , et le bureau mate me donne (gestionnaire d'énergie) le niveau de la batterie
dans les options (préférences) , j'ai onglet "sur onduleur" => ordinateur en veille => jamais
en dessous => niveau de l'onduleur faible => éteindre
en dessous => niveau de l'onduleur critique => éteindre
en dessous => affichage => mettre l'écran en veille => 10 mn
quand Nut est installé tout ceci n'apparaît plus
j'ai pas réussit a le faire fonctionner normalement ,
lors d un test je suis passé a moins de 20% sur la batterie et c'est l'onduleur qui a envoyé un shutdown
et a éteint la machine et l'onduleur a couper la sortie ondulé
donc pour moi résolu le driver , résolu le blocage du démarrage de la machine (enfin pas compris la cause).
et par contre toujours cette info sur les pid inaccessible (dans /run/nut/ )
seulement des infos de nut dans le syslog
ps: pour le dialogue , a priori l'info du niveau de la batterie monte sur mon bureau , donc il y a un minimum de choses (info de l'onduleur) qui remonte sur le système sans Nut installé
j'ai beau regardé ton retour en #20 pour moi tout est correct (je suppose que tu a créer l'utilisateur (basic sans dossier dans /home) et ajouté au groupe "nut"
a priori même pas utile de créer son mdp (nut n'utilise pas le fichier système des mot de passe si j'ai bien compris )
voila pour mes tests et c'est pas brillant
j'ai désinstallé Nut et purgé , il me reste juste le groupe "nut" et l'utilisateur "nutmon" qui est aussi dans le groupe "nut"
tout le reste a disparut
pour le noyau (kernel) il connaît l'onduleur , et le bureau mate me donne (gestionnaire d'énergie) le niveau de la batterie
dans les options (préférences) , j'ai onglet "sur onduleur" => ordinateur en veille => jamais
en dessous => niveau de l'onduleur faible => éteindre
en dessous => niveau de l'onduleur critique => éteindre
en dessous => affichage => mettre l'écran en veille => 10 mn
quand Nut est installé tout ceci n'apparaît plus
j'ai pas réussit a le faire fonctionner normalement ,
lors d un test je suis passé a moins de 20% sur la batterie et c'est l'onduleur qui a envoyé un shutdown
et a éteint la machine et l'onduleur a couper la sortie ondulé
donc pour moi résolu le driver , résolu le blocage du démarrage de la machine (enfin pas compris la cause).
et par contre toujours cette info sur les pid inaccessible (dans /run/nut/ )
seulement des infos de nut dans le syslog
ps: pour le dialogue , a priori l'info du niveau de la batterie monte sur mon bureau , donc il y a un minimum de choses (info de l'onduleur) qui remonte sur le système sans Nut installé
j'ai beau regardé ton retour en #20 pour moi tout est correct (je suppose que tu a créer l'utilisateur (basic sans dossier dans /home) et ajouté au groupe "nut"
a priori même pas utile de créer son mdp (nut n'utilise pas le fichier système des mot de passe si j'ai bien compris )
voila pour mes tests et c'est pas brillant
#35 19-12-2021 15:54:17
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
Bonjour
pour ton souci de driver je pense avoir trouvé
de ton #20
# systemctl status nut-driver.service
● nut-driver.service - Network UPS Tools - power device driver controller
Loaded: loaded (/lib/systemd/system/nut-driver.service; static; vendor preset
systemctl enable nut.driver-service
systemctl start nut.driver-service
systemctl status nut-driver.service
● nut-driver.service - Network UPS Tools - power device driver controller
Loaded: loaded (/lib/systemd/system/nut-driver.service; static)
Active: active (running) since Sun 2021-12-19 15:34:20 CET; 1min 21s ago
Process: 492 ExecStart=/sbin/upsdrvctl start (code=exited, status=0/SUCCESS)
Main PID: 792 (usbhid-ups)
Tasks: 1 (limit: 19033)
Memory: 1.1M
CPU: 297ms
CGroup: /system.slice/nut-driver.service
└─792 /lib/nut/usbhid-ups -a Eaton
déc. 19 15:34:13 debian2 systemd[1]: Starting Network UPS Tools - power device driver controller...
déc. 19 15:34:18 debian2 upsdrvctl[501]: Using subdriver: MGE HID 1.40
déc. 19 15:34:19 debian2 upsdrvctl[501]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
déc. 19 15:34:19 debian2 upsdrvctl[501]: USB communication driver 0.33
déc. 19 15:34:20 debian2 upsdrvctl[492]: Network UPS Tools - UPS driver controller 2.7.4
déc. 19 15:34:20 debian2 usbhid-ups[792]: Startup successful
déc. 19 15:34:20 debian2 systemd[1]: Started Network UPS Tools - power device driver controller.
pour ton souci de driver je pense avoir trouvé
de ton #20
# systemctl status nut-driver.service
● nut-driver.service - Network UPS Tools - power device driver controller
Loaded: loaded (/lib/systemd/system/nut-driver.service; static; vendor preset
nut-driver.service est en mode statique => static; vendor preset
tu fais un :
systemctl enable nut.driver-service
et un start
systemctl start nut.driver-service
suivit d'un status pour voir si correct
bon c'est pas cela (j'ai comme toi )
il y a un lien qui active le driver , peut être a partir de /etc/init.d/
la commande au dessus "enable" va te donner une erreur (ou tu a un lien de cassé )
systemctl status nut-driver.service
● nut-driver.service - Network UPS Tools - power device driver controller
Loaded: loaded (/lib/systemd/system/nut-driver.service; static)
Active: active (running) since Sun 2021-12-19 15:34:20 CET; 1min 21s ago
Process: 492 ExecStart=/sbin/upsdrvctl start (code=exited, status=0/SUCCESS)
Main PID: 792 (usbhid-ups)
Tasks: 1 (limit: 19033)
Memory: 1.1M
CPU: 297ms
CGroup: /system.slice/nut-driver.service
└─792 /lib/nut/usbhid-ups -a Eaton
déc. 19 15:34:13 debian2 systemd[1]: Starting Network UPS Tools - power device driver controller...
déc. 19 15:34:18 debian2 upsdrvctl[501]: Using subdriver: MGE HID 1.40
déc. 19 15:34:19 debian2 upsdrvctl[501]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
déc. 19 15:34:19 debian2 upsdrvctl[501]: USB communication driver 0.33
déc. 19 15:34:20 debian2 upsdrvctl[492]: Network UPS Tools - UPS driver controller 2.7.4
déc. 19 15:34:20 debian2 usbhid-ups[792]: Startup successful
déc. 19 15:34:20 debian2 systemd[1]: Started Network UPS Tools - power device driver controller.
j'ai aussi un service "static" , a la fin de la config , un redémarrage a suffit a tout mettre en ordre.
Dernière modification par anonyme (19-12-2021 16:42:49)
#36 20-12-2021 01:10:41
- Sty_X
- Membre
- Inscription : 14-02-2021
Re : Problème de communication nut/onduleur
Salut et une nouvelle fois merci !
En effet, la commande :
En effet, la commande :
# systemctl enable nut.driver-service
me retourne cette erreur :
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
Ensuite, lorsque je fais un
systemctl start nut-driver.service
j'ai en retour :
Job for nut-driver.service failed because a timeout was exceeded.
See "systemctl status nut-driver.service" and "journalctl -xe" for details.
See "systemctl status nut-driver.service" and "journalctl -xe" for details.
Et donc ensuite
systemctl status nut-driver.service
me renvoie
● nut-driver.service - Network UPS Tools - power device driver controller
Loaded: loaded (/lib/systemd/system/nut-driver.service; static; vendor preset: enabled)
Active: failed (Result: timeout) since Mon 2021-12-20 00:00:15 CET; 3min 37s ago
Process: 2211 ExecStart=/sbin/upsdrvctl start (code=killed, signal=TERM)
Dec 20 00:00:09 cal.fr systemd[1]: Starting Network UPS Tools - power device driver controller...
Dec 20 00:00:13 cal.fr upsdrvctl[2211]: Using subdriver: MGE HID 1.39
Dec 20 00:00:13 cal.fr upsdrvctl[2211]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
Dec 20 00:00:13 cal.fr upsdrvctl[2211]: USB communication driver 0.33
Dec 20 00:00:14 cal.fr systemd[1]: nut-driver.service: Start operation timed out. Terminating.
Dec 20 00:00:14 cal.fr systemd[1]: nut-driver.service: Control process exited, code=killed, status=15/TERM
Dec 20 00:00:15 cal.fr systemd[1]: nut-driver.service: Failed with result 'timeout'.
Dec 20 00:00:15 cal.fr systemd[1]: Failed to start Network UPS Tools - power device driver controller.
Loaded: loaded (/lib/systemd/system/nut-driver.service; static; vendor preset: enabled)
Active: failed (Result: timeout) since Mon 2021-12-20 00:00:15 CET; 3min 37s ago
Process: 2211 ExecStart=/sbin/upsdrvctl start (code=killed, signal=TERM)
Dec 20 00:00:09 cal.fr systemd[1]: Starting Network UPS Tools - power device driver controller...
Dec 20 00:00:13 cal.fr upsdrvctl[2211]: Using subdriver: MGE HID 1.39
Dec 20 00:00:13 cal.fr upsdrvctl[2211]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
Dec 20 00:00:13 cal.fr upsdrvctl[2211]: USB communication driver 0.33
Dec 20 00:00:14 cal.fr systemd[1]: nut-driver.service: Start operation timed out. Terminating.
Dec 20 00:00:14 cal.fr systemd[1]: nut-driver.service: Control process exited, code=killed, status=15/TERM
Dec 20 00:00:15 cal.fr systemd[1]: nut-driver.service: Failed with result 'timeout'.
Dec 20 00:00:15 cal.fr systemd[1]: Failed to start Network UPS Tools - power device driver controller.
En lisant ton post précédent (#35), j'ai l'impression que tu as trouvé une solution pour cela mais je n'ai pas ou mal compris. Pourrais-tu m'en dire plus ?
Je pense que c'est lié au problème ci-dessus, mais lors d'un reboot, dans les logs j'ai donc toujours un :
Dec 20 00:00:53 cal upsmon[1668]: Poll UPS [eaton650@localhost] failed - Driver not connected
Tant que je ne lance pas manuellement un :
# upsdrvctl start
Dernière modification par Sty_X (20-12-2021 01:26:14)
Hors ligne
#37 20-12-2021 07:57:43
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
au démarrage de la machine j'ai ceci (du syslog)
Dec 20 05:58:46 debian2 upsdrvctl[505]: Using subdriver: MGE HID 1.40
Dec 20 05:58:46 debian2 systemd[1]: Started User Login Management.
Dec 20 05:58:47 debian2 upsdrvctl[505]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
Dec 20 05:58:47 debian2 upsdrvctl[505]: USB communication driver 0.33
Dec 20 05:58:48 debian2 systemd[1]: Starting Authorization Manager...
Dec 20 05:58:48 debian2 upsdrvctl[493]: Network UPS Tools - UPS driver controller 2.7.4
Dec 20 05:58:48 debian2 usbhid-ups[808]: Startup successful
Dec 20 05:58:48 debian2 systemd[1]: Started Network UPS Tools - power device driver controller.
Dec 20 05:58:48 debian2 systemd[1]: Starting Network UPS Tools - power devices information server...
# ups.conf
[Eaton]
driver = usbhid-ups
#Pour usb valeur=auto
port = auto
desc = "Eaton 3S 850"
#synchronous = yes
#maxretry = 3
Dec 20 05:58:46 debian2 upsdrvctl[505]: Using subdriver: MGE HID 1.40
Dec 20 05:58:46 debian2 systemd[1]: Started User Login Management.
Dec 20 05:58:47 debian2 upsdrvctl[505]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
Dec 20 05:58:47 debian2 upsdrvctl[505]: USB communication driver 0.33
Dec 20 05:58:48 debian2 systemd[1]: Starting Authorization Manager...
Dec 20 05:58:48 debian2 upsdrvctl[493]: Network UPS Tools - UPS driver controller 2.7.4
Dec 20 05:58:48 debian2 usbhid-ups[808]: Startup successful
Dec 20 05:58:48 debian2 systemd[1]: Started Network UPS Tools - power device driver controller.
Dec 20 05:58:48 debian2 systemd[1]: Starting Network UPS Tools - power devices information server...
et le service c'est bien "upsdrvctl" qui le lance sur mon retour au dessus
donc si manuellement sur le bureau ça fonctionne .
il faut chercher un problème dans le syslog au démarrage de la machine
# ups.conf
[Eaton]
driver = usbhid-ups
#Pour usb valeur=auto
port = auto
desc = "Eaton 3S 850"
#synchronous = yes
#maxretry = 3
ps: ma config pour charger le driver (nouvelle install de hier)
pour le reste un upsd.users correct
un user pour nut ajouté au groupe nut et son mdp
une autre sortie usb utilisé , le noyau des backports , mais pas logique ça fonctionne a partir du bureau avec "upsdrvctl start"
ps: maxretry = 3 pose problème au démarrage (désactivé) pour mon onduleur
Dernière modification par anonyme (20-12-2021 08:03:44)
#38 20-12-2021 10:37:46
- Sty_X
- Membre
- Inscription : 14-02-2021
Re : Problème de communication nut/onduleur
Pourrais-tu me donner la commande à utiliser pour afficher les lignes intéressantes dans les logs après un redémarrage. Afin de pouvoir comparer avec toi.
Sinon voici mon fichier ups.conf
Sinon voici mon fichier ups.conf
#maxretry = 3
[eaton650]
driver = usbhid-ups
port = auto
[eaton650]
driver = usbhid-ups
port = auto
et le ficher upsd.users
[admin]
password = monmotdepasse
allowfrom = localhost
actions = SET
instcmds = ALL
upsmon master
password = monmotdepasse
allowfrom = localhost
actions = SET
instcmds = ALL
upsmon master
J'ai bien un utilisateur nut faisant partie du groupe nut. Peut-être un soucis au niveau des droits ?
Dernière modification par Sty_X (20-12-2021 10:38:14)
Hors ligne
#39 20-12-2021 16:12:00
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
non je fais la recherche manuellement pour le syslog et les lignes de Nut
sinon pour les tests
tail -f /var/log/syslog
cat /var/log/syslog | grep -i upsdrvctl
cat /var/log/syslog | grep -i fopen
Dec 20 09:05:01 debian2 upsd[791]: fopen /run/nut/upsd.pid: No such file or directory
Dec 20 09:05:01 debian2 upsmon[795]: fopen /run/nut/upsmon.pid: No such file or directory
cat /var/log/syslog | grep -i nut-monitor.service
Dec 20 09:05:01 debian2 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: Operation not permitted
Dec 20 09:05:01 debian2 systemd[1]: nut-monitor.service: Supervising process 800 which is not our child. We'll most likely not notice when it exits.
cat /var/log/syslog | grep -i nut-server
Dec 19 03:30:56 debian2 systemd[1]: nut-server.service: Deactivated successfully.
sinon pour les tests
tail -f /var/log/syslog
ou par exemple
cat /var/log/syslog | grep -i upsdrvctl
ps: ou un autre mot clé que "upsdrvctl
d'autres exemples
cat /var/log/syslog | grep -i fopen
Dec 20 09:05:01 debian2 upsd[791]: fopen /run/nut/upsd.pid: No such file or directory
Dec 20 09:05:01 debian2 upsmon[795]: fopen /run/nut/upsmon.pid: No such file or directory
cat /var/log/syslog | grep -i nut-monitor.service
Dec 20 09:05:01 debian2 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: Operation not permitted
Dec 20 09:05:01 debian2 systemd[1]: nut-monitor.service: Supervising process 800 which is not our child. We'll most likely not notice when it exits.
cat /var/log/syslog | grep -i nut-server
Dec 19 03:30:56 debian2 systemd[1]: nut-server.service: Deactivated successfully.
etc .........
Dernière modification par anonyme (20-12-2021 16:26:16)
#40 20-12-2021 16:50:07
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
pour les tests toujours mauvais
tail -f /var/log/syslog
Dec 20 15:44:09 debian2 upsmon[800]: UPS Eaton@localhost on battery
Dec 20 15:44:09 debian2 upssched-cmd: Unrecognized command: UPS Eaton@localhost on battery
Dec 20 15:51:49 debian2 upsmon[800]: UPS Eaton@localhost on line power
Dec 20 15:51:49 debian2 upssched-cmd: Unrecognized command: UPS Eaton@localhost on line power
tail -f /var/log/syslog
Dec 20 15:44:09 debian2 upsmon[800]: UPS Eaton@localhost on battery
Dec 20 15:44:09 debian2 upssched-cmd: Unrecognized command: UPS Eaton@localhost on battery
Dec 20 15:51:49 debian2 upsmon[800]: UPS Eaton@localhost on line power
Dec 20 15:51:49 debian2 upssched-cmd: Unrecognized command: UPS Eaton@localhost on line power
Dernière modification par anonyme (20-12-2021 16:52:49)
#41 20-12-2021 18:22:49
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
bon il me reste un souci
Dec 20 16:52:57 debian2 upsmon[801]: UPS Eaton@localhost on line power
Dec 20 16:55:42 debian2 upsmon[801]: UPS Eaton@localhost on battery
Dec 20 16:55:42 debian2 upssched[1289]: Timer daemon started
Dec 20 16:55:42 debian2 upssched[1289]: New timer: onbat (10 seconds)
Dec 20 16:55:42 debian2 upssched[1289]: New timer: shutdown (190 seconds)
Dec 20 16:55:52 debian2 upssched[1289]: Event: onbat
Dec 20 16:55:52 debian2 upssched-cmd: Onduleur : extinction dans 3 minutes
Dec 20 16:58:52 debian2 upssched[1289]: Event: shutdown
Dec 20 16:58:52 debian2 upssched-cmd: Unrecognized command: shutdown
Dec 20 16:59:07 debian2 upssched[1289]: Timer queue empty, exiting
Dec 20 16:59:57 debian2 upsmon[801]: UPS Eaton@localhost on line power
Dec 20 16:52:57 debian2 upsmon[801]: UPS Eaton@localhost on line power
Dec 20 16:55:42 debian2 upsmon[801]: UPS Eaton@localhost on battery
Dec 20 16:55:42 debian2 upssched[1289]: Timer daemon started
Dec 20 16:55:42 debian2 upssched[1289]: New timer: onbat (10 seconds)
Dec 20 16:55:42 debian2 upssched[1289]: New timer: shutdown (190 seconds)
Dec 20 16:55:52 debian2 upssched[1289]: Event: onbat
Dec 20 16:55:52 debian2 upssched-cmd: Onduleur : extinction dans 3 minutes
Dec 20 16:58:52 debian2 upssched[1289]: Event: shutdown
Dec 20 16:58:52 debian2 upssched-cmd: Unrecognized command: shutdown
Dec 20 16:59:07 debian2 upssched[1289]: Timer queue empty, exiting
Dec 20 16:59:57 debian2 upsmon[801]: UPS Eaton@localhost on line power
j'ai bien reçu le mail local sur la machine
mais tu vois que le shutdown ne fonctionne pas
#42 20-12-2021 19:50:24
- Sty_X
- Membre
- Inscription : 14-02-2021
Re : Problème de communication nut/onduleur
Voila ce que me donne les logs lors du démarrage :
$ cat /var/log/syslog | grep -i upsdrvctl
Dec 20 18:37:57 cal upsdrvctl[612]: Using subdriver: MGE HID 1.39
Dec 20 18:37:57 cal upsdrvctl[612]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
Dec 20 18:37:57 cal upsdrvctl[612]: USB communication driver 0.33
Dec 20 18:37:57 cal upsdrvctl[612]: Using subdriver: MGE HID 1.39
Dec 20 18:37:57 cal upsdrvctl[612]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
Dec 20 18:37:57 cal upsdrvctl[612]: USB communication driver 0.33
$ cat /var/log/syslog | grep -i fopen
Dec 20 18:37:58 cal upsd[1664]: fopen /var/run/nut/upsd.pid: No such file or directory
Dec 20 18:37:58 cal upsmon[1668]: fopen /var/run/nut/upsmon.pid: No such file or directory
Dec 20 18:37:58 cal upsd[1664]: fopen /var/run/nut/upsd.pid: No such file or directory
Dec 20 18:37:58 cal upsmon[1668]: fopen /var/run/nut/upsmon.pid: No such file or directory
$ cat /var/log/syslog | grep -i nut-monitor.service
Dec 20 18:37:58 cal systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory
Dec 20 18:37:58 cal systemd[1]: nut-monitor.service: Supervising process 1670 which is not our child. We'll most likely not notice when it exits.
Dec 20 18:37:58 cal systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory
Dec 20 18:37:58 cal systemd[1]: nut-monitor.service: Supervising process 1670 which is not our child. We'll most likely not notice when it exits.
$ cat /var/log/syslog | grep -i nut
Dec 20 18:37:58 cal systemd[1]: nut-driver.service: Start operation timed out. Terminating.
Dec 20 18:37:58 cal systemd[1]: nut-driver.service: Control process exited, code=killed, status=15/TERM
Dec 20 18:37:58 cal systemd[1]: nut-driver.service: Failed with result 'timeout'.
Dec 20 18:37:58 cal upsd[1664]: fopen /var/run/nut/upsd.pid: No such file or directory
Dec 20 18:37:58 cal upsmon[1668]: fopen /var/run/nut/upsmon.pid: No such file or directory
Dec 20 18:37:58 cal systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory
Dec 20 18:37:58 cal systemd[1]: nut-monitor.service: Supervising process 1670 which is not our child. We'll most likely not notice when it exits.
Dec 20 18:37:58 cal systemd[1]: nut-driver.service: Start operation timed out. Terminating.
Dec 20 18:37:58 cal systemd[1]: nut-driver.service: Control process exited, code=killed, status=15/TERM
Dec 20 18:37:58 cal systemd[1]: nut-driver.service: Failed with result 'timeout'.
Dec 20 18:37:58 cal upsd[1664]: fopen /var/run/nut/upsd.pid: No such file or directory
Dec 20 18:37:58 cal upsmon[1668]: fopen /var/run/nut/upsmon.pid: No such file or directory
Dec 20 18:37:58 cal systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory
Dec 20 18:37:58 cal systemd[1]: nut-monitor.service: Supervising process 1670 which is not our child. We'll most likely not notice when it exits.
Pour ton post #41 : tu utilises quoi comme commande pour le shutdown ?
voila mon /bin/upssched-cmd
case $1 in
onbat)
logger -t upssched-cmd "Cal sur onduleur -> Extinction dans 10 minutes !"
echo "Cal sur onduleur -> Extinction dans 10 minutes !" | mail -s "ONDULEUR ALERTE" root@cal.fr
curl "https://smsapi.free-mobile.fr/sendmsg?user=********&pass=********msg=Cal%20sur%20onduleur%20-%3e%20Extinction%20dans%2010%10minutes%20%21"
;;
shutdown)
logger -t upssched-cmd "Cal sur onduleur depuis 10 minutes -> Extinction immédiate !"
upsmon -c fsd
;;
*)
logger -t upssched-cmd "Unrecognized command: $1"
;;
esac
onbat)
logger -t upssched-cmd "Cal sur onduleur -> Extinction dans 10 minutes !"
echo "Cal sur onduleur -> Extinction dans 10 minutes !" | mail -s "ONDULEUR ALERTE" root@cal.fr
curl "https://smsapi.free-mobile.fr/sendmsg?user=********&pass=********msg=Cal%20sur%20onduleur%20-%3e%20Extinction%20dans%2010%10minutes%20%21"
;;
shutdown)
logger -t upssched-cmd "Cal sur onduleur depuis 10 minutes -> Extinction immédiate !"
upsmon -c fsd
;;
*)
logger -t upssched-cmd "Unrecognized command: $1"
;;
esac
Dernière modification par Sty_X (20-12-2021 19:51:24)
Hors ligne
#43 20-12-2021 20:22:05
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
voila suis enfin arrivé ( 3mn avant le shutdown )
Dec 20 19:07:05 debian2 upsmon[801]: UPS Eaton@localhost on battery
Dec 20 19:07:05 debian2 upssched[1208]: Timer daemon started
Dec 20 19:07:06 debian2 upssched[1208]: New timer: onbat (10 seconds)
Dec 20 19:07:06 debian2 upssched[1208]: New timer: shutdown (180 seconds)
Dec 20 19:07:16 debian2 upssched[1208]: Event: onbat
Dec 20 19:07:16 debian2 upssched-cmd: Onduleur : extinction dans 3 minutes
Dec 20 19:10:06 debian2 upssched[1208]: Event: shutdown
Dec 20 19:10:06 debian2 upssched-cmd: Shutting down using: upsmon -c fsd
Dec 20 19:10:06 debian2 upsmon[801]: Signal 10: User requested FSD
Dec 20 19:10:06 debian2 upsd[798]: Client nutmon@127.0.0.1 set FSD on UPS [Eaton]
Dec 20 19:10:06 debian2 upsmon[801]: Executing automatic power-fail shutdown
Dec 20 19:10:06 debian2 upsmon[801]: Auto logout and shutdown proceeding
Dec 20 19:10:11 debian2 systemd[1]: Stopping Session 2 of User robert...
Dec 20 19:10:11 debian2 systemd[1]: Removed slice Slice /system/modprobe.
Dec 20 19:10:11 debian2 systemd[1]: Stopped target Graphical Interface.
Dec 20 19:10:11 debian2 systemd[1]: Stopped target Multi-User System.
Dec 20 19:10:11 debian2 systemd[1]: Stopped target Login Prompts.
Dec 20 19:10:11 debian2 systemd[1]: Stopped target Sound Card.
Dec 20 19:10:11 debian2 systemd[1]: Stopped target Timer Units.
Dec 20 19:07:05 debian2 upsmon[801]: UPS Eaton@localhost on battery
Dec 20 19:07:05 debian2 upssched[1208]: Timer daemon started
Dec 20 19:07:06 debian2 upssched[1208]: New timer: onbat (10 seconds)
Dec 20 19:07:06 debian2 upssched[1208]: New timer: shutdown (180 seconds)
Dec 20 19:07:16 debian2 upssched[1208]: Event: onbat
Dec 20 19:07:16 debian2 upssched-cmd: Onduleur : extinction dans 3 minutes
Dec 20 19:10:06 debian2 upssched[1208]: Event: shutdown
Dec 20 19:10:06 debian2 upssched-cmd: Shutting down using: upsmon -c fsd
Dec 20 19:10:06 debian2 upsmon[801]: Signal 10: User requested FSD
Dec 20 19:10:06 debian2 upsd[798]: Client nutmon@127.0.0.1 set FSD on UPS [Eaton]
Dec 20 19:10:06 debian2 upsmon[801]: Executing automatic power-fail shutdown
Dec 20 19:10:06 debian2 upsmon[801]: Auto logout and shutdown proceeding
Dec 20 19:10:11 debian2 systemd[1]: Stopping Session 2 of User robert...
Dec 20 19:10:11 debian2 systemd[1]: Removed slice Slice /system/modprobe.
Dec 20 19:10:11 debian2 systemd[1]: Stopped target Graphical Interface.
Dec 20 19:10:11 debian2 systemd[1]: Stopped target Multi-User System.
Dec 20 19:10:11 debian2 systemd[1]: Stopped target Login Prompts.
Dec 20 19:10:11 debian2 systemd[1]: Stopped target Sound Card.
Dec 20 19:10:11 debian2 systemd[1]: Stopped target Timer Units.
je pourrai te donner mes scripts , mais je pense que tu connais mieux que moi 
ps: je regarde ton #42
#44 20-12-2021 20:27:53
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
pour les "pid" c'est un warning a priori aucune importance
tu peu les voir dans /run/nut/
il disparaissent si nut est pas lancé
ls /run/nut/
upsd.pid upsmon.pid usbhid-ups-Eaton usbhid-ups-Eaton.pid
tu peu les voir dans /run/nut/
il disparaissent si nut est pas lancé
ls /run/nut/
upsd.pid upsmon.pid usbhid-ups-Eaton usbhid-ups-Eaton.pid
#45 20-12-2021 20:31:34
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
il faut créer un dossier "upssched" pour les 2 "pid" de upssched.conf propriétaires "nut:nut"
ps: si tu veut l'ensemble de mes scripts maintenant dit le
ps: si tu veut l'ensemble de mes scripts maintenant dit le
Dernière modification par anonyme (20-12-2021 20:34:04)
#46 20-12-2021 20:41:49
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
ma version du driver
cat /var/log/syslog | grep -i upsdrvctl
Dec 20 19:05:43 debian2 upsdrvctl[505]: Using subdriver: MGE HID 1.40
Dec 20 19:05:43 debian2 upsdrvctl[505]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
Dec 20 19:05:43 debian2 upsdrvctl[505]: USB communication driver 0.33
Dec 20 19:05:45 debian2 upsdrvctl[496]: Network UPS Tools - UPS driver controller 2.7.4
cat /var/log/syslog | grep -i upsdrvctl
Dec 20 19:05:43 debian2 upsdrvctl[505]: Using subdriver: MGE HID 1.40
Dec 20 19:05:43 debian2 upsdrvctl[505]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
Dec 20 19:05:43 debian2 upsdrvctl[505]: USB communication driver 0.33
Dec 20 19:05:45 debian2 upsdrvctl[496]: Network UPS Tools - UPS driver controller 2.7.4
je dois être sur un usb version 1.1 (vieille machine)
mais j'ai du 2 et du 3 en usb disponible (en amd ancienne génération cpu AMD FX-8320E )
#47 20-12-2021 20:46:16
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
pour les pid comme toi (un bug mais ça fonctionne )
cat /var/log/syslog | grep -i fopen
Dec 20 19:05:45 debian2 upsd[795]: fopen /run/nut/upsd.pid: No such file or directory
Dec 20 19:05:45 debian2 upsmon[799]: fopen /run/nut/upsmon.pid: No such file or directory
Dec 20 19:12:05 debian2 upsd[796]: fopen /run/nut/upsd.pid: No such file or directory
Dec 20 19:12:05 debian2 upsmon[798]: fopen /run/nut/upsmon.pid: No such file or directory
cat /var/log/syslog | grep -i fopen
Dec 20 19:05:45 debian2 upsd[795]: fopen /run/nut/upsd.pid: No such file or directory
Dec 20 19:05:45 debian2 upsmon[799]: fopen /run/nut/upsmon.pid: No such file or directory
Dec 20 19:12:05 debian2 upsd[796]: fopen /run/nut/upsd.pid: No such file or directory
Dec 20 19:12:05 debian2 upsmon[798]: fopen /run/nut/upsmon.pid: No such file or directory
juste le driver ou je comprend pas ou est le souci pour toi , et sans driver le reste échoue
Dernière modification par anonyme (20-12-2021 20:47:49)
#48 20-12-2021 20:55:24
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
comme moi (en #18 ) le maxretry pose problème avec ton driver ?
upsdrvctl start
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Fatal error: 'maxretry' is not a valid variable name for this driver.
Look in the man page or call this driver with -h for a list of
valid variable names and flags.
battery.charge: 32
ups.firmware: 02.08.0010
upsdrvctl start
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Fatal error: 'maxretry' is not a valid variable name for this driver.
Look in the man page or call this driver with -h for a list of
valid variable names and flags.
il est prévue de faire 3 tentatives en cas d' échec du driver
la batterie fatiguée
la version du firmware de l'onduleur
battery.charge: 32
ups.firmware: 02.08.0010
Dernière modification par anonyme (20-12-2021 21:00:53)
#49 21-12-2021 00:03:33
- Sty_X
- Membre
- Inscription : 14-02-2021
Re : Problème de communication nut/onduleur
anonyme a écrit :
il faut créer un dossier "upssched" pour les 2 "pid" de upssched.conf propriétaires "nut:nut"
ps: si tu veut l'ensemble de mes scripts maintenant dit le
Je ne suis pas sûr de comprendre. Tu parles de créer un dossier nommé upssched dans /var/run/nut/ pour les fichiers en .pipe (PIPEFN et LOCKFN) mentionnés dans upssched.conf ? Si c’est bien ça moi j’ai fait autrement : j’ai modifié les lignes dans upssched.conf pour passer de cela :
PIPEFN /var/run/nut/upssched/upssched.pipe
LOCKFN /var/run/nut/upssched/upssched.lock
LOCKFN /var/run/nut/upssched/upssched.lock
A cela :
PIPEFN /var/run/nut/upssched.pipe
LOCKFN /var/run/nut/upssched.lock
LOCKFN /var/run/nut/upssched.lock
Comme cela je pensais que je n’avais pas besoin de créer le dossier /var/run/nut/upssched. Tu penses que ma solution pose problème ?
PS : Ah ben oui je veux bien tes scipts pour comparer si cela ne te dérange pas
anonyme a écrit :
ma version du driver
cat /var/log/syslog | grep -i upsdrvctl
Dec 20 19:05:43 debian2 upsdrvctl[505]: Using subdriver: MGE HID 1.40
Dec 20 19:05:43 debian2 upsdrvctl[505]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
Dec 20 19:05:43 debian2 upsdrvctl[505]: USB communication driver 0.33
Dec 20 19:05:45 debian2 upsdrvctl[496]: Network UPS Tools - UPS driver controller 2.7.4
je dois être sur un usb version 1.1 (vieille machine)
mais j'ai du 2 et du 3 en usb disponible (en amd ancienne génération cpu AMD FX-8320E )
C’est étrange : tu as la version 1.4 du driver MGE HID alors que j’ai la version 1.39... Est-il possible de faire une mise à jour ?
$ cat /var/log/syslog | grep -i upsdrvctl
Dec 20 09:27:42 cal upsdrvctl[607]: USB communication driver 0.33
Dec 20 18:37:57 cal upsdrvctl[612]: Using subdriver: MGE HID 1.39
Dec 20 18:37:57 cal upsdrvctl[612]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
Dec 20 09:27:42 cal upsdrvctl[607]: USB communication driver 0.33
Dec 20 18:37:57 cal upsdrvctl[612]: Using subdriver: MGE HID 1.39
Dec 20 18:37:57 cal upsdrvctl[612]: Network UPS Tools - Generic HID driver 0.41 (2.7.4)
Pour moi l'onduleur est connecté sur un port USB3
anonyme a écrit :
comme moi (en #18 ) le maxretry pose problème avec ton driver ?
upsdrvctl start
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Fatal error: 'maxretry' is not a valid variable name for this driver.
Look in the man page or call this driver with -h for a list of
valid variable names and flags.
il est prévue de faire 3 tentatives en cas d' échec du driver
la batterie fatiguée
la version du firmware de l'onduleur
battery.charge: 32
ups.firmware: 02.08.0010
Pour moi le maxretry ne pose pas de soucis :
$ sudo upsdrvctl start
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Using subdriver: MGE HID 1.39
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Using subdriver: MGE HID 1.39
En même temps la ligne est commentée dans le fichier ups.conf
#maxretry = 3
[eaton650]
driver = usbhid-ups
port = auto
[eaton650]
driver = usbhid-ups
port = auto
Chez moi le firmware de l'onduleur est en version 2 et non pas 02.08.0010 comme chez toi. Est-il possible de le mettre à jour ?
$ /bin/upsc eaton650@localhost
ups.firmware: 02
ups.firmware: 02
Hors ligne
#50 21-12-2021 03:15:04
- anonyme
- Banni(e)
Re : Problème de communication nut/onduleur
moi a chaque démarrage le dossier /run/nut/upssched disparaît
donc je l'ai mit dans /etc/nut/upssched , chnown nut:nut et chmod 770 (il doit lire et écrire un 700 doit suffire)
pour la version du driver ici => https://packages.debian.org/fr/bookworm/nut (la version de bookworm (debian12)
en activant une ligne "bookworm" tu dois pouvoir le récupérer avec les dépendances et mettre a jour
puis tu désactive la (ou les) lignes pour rester en stable
attention a ne pas faire un "upgrade" sinon tu passe en testing ( si trop compliquer abandonne l'idée , peut être il viendra dans les backports de bullseye)
pour le firmware c'est chez le constructeur et je pense pas que cela se met a jour (regarde si il propose quelque chose pour ton onduleur) .
ps: ma version du firmware ne va certainement pas fonctionner sur le tien (pas même génération et type de matériel)
il doit fonctionner (avec sa version actuelle ) et je te conseille de ne pas chercher a le faire .
pour le maxretry teste 1 puis 2 puis 3 , voir si ça change quelque chose et met le a la fin du script .
donc je l'ai mit dans /etc/nut/upssched , chnown nut:nut et chmod 770 (il doit lire et écrire un 700 doit suffire)
pour la version du driver ici => https://packages.debian.org/fr/bookworm/nut (la version de bookworm (debian12)
en activant une ligne "bookworm" tu dois pouvoir le récupérer avec les dépendances et mettre a jour
puis tu désactive la (ou les) lignes pour rester en stable
attention a ne pas faire un "upgrade" sinon tu passe en testing ( si trop compliquer abandonne l'idée , peut être il viendra dans les backports de bullseye)
pour le firmware c'est chez le constructeur et je pense pas que cela se met a jour (regarde si il propose quelque chose pour ton onduleur) .
ps: ma version du firmware ne va certainement pas fonctionner sur le tien (pas même génération et type de matériel)
il doit fonctionner (avec sa version actuelle ) et je te conseille de ne pas chercher a le faire .
pour le maxretry teste 1 puis 2 puis 3 , voir si ça change quelque chose et met le a la fin du script .