[RÉSOLU] Un coup de main pour résoudre un problème avec NUT

Bonjour à tous
J’ai installé NU (sur un Raspberry Pi) pour monitorer un onduleur Eaton UPS.
S’il y a coupure de courant l’onduleur fait arrêter le RPI (ou le maintient en activité pendant 10 minutes).

Mais quand le courant revient, 10 minutes après le RPI se met à rebooter.

C’est le timer de NOTIFYCMD let "n = 600" qui le fait rebooter après 10 mn (si je passe la valeur à 900, le RPI reboot après 15mn).

Et je ne comprends pas pourquoi.
Voici ma configuration :

/etc/default/nut

# start upsd
START_UPSD=yes

# start upsmon
START_UPSMON=yes

/etc/nut/ups.conf

[eaton]
driver = usbhid-ups
port = auto
desc = "Eaton3S"

/etc/nut/nut.conf

standalone

/etc/nut/upsd.conf

# LISTEN <address> <port> LISTEN 127.0.0.1 3493 LISTEN ::1 3493
/etc/nut/upsd.users

[admin]
password = mypass
actions = SET
instcmds = ALL

[upsmon]
password = mypass
upsmon master

/etc/nut/upsmon.conf

MONITOR eaton@localhost 1 admin mypass master
MINSUPPLIES 1

FINALDELAY 5
SHUTDOWNCMD "sudo /sbin/shutdown -h +0"

NOTIFYCMD "/etc/nut/notifycmd"

NOTIFYFLAG ONBATT EXEC+SYSLOG+WALL
NOTIFYFLAG ONLINE EXEC+SYSLOG+WALL
NOTIFYCMD /etc/nut/notifycmd

And finally, NOTIFYCMD:
/etc/nut/notifycmd

[code]
#!/bin/bash

NUT NOTIFYCMD script

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin

trap “exit 0” SIGTERM

if [ “$NOTIFYTYPE” = “ONLINE” ]
then
echo $0: power restored | wall
curl “command”
#sleep 5
# Cause all instances of this script to exit.
killall -s SIGTERM basename $0

fi

if [ “$NOTIFYTYPE” = “ONBATT” ]
then
echo $0: 10 minutes till system powers down… | wall
curl “command!”
# Loop with one second interval to allow SIGTERM reception.
let "n = 600"
while [ $n -ne 0 ]
do
sleep 1
let "n–"
done
echo $0: commencing shutdown | wall
upsmon -c fsd

fi[/code]

Voilà.

J’espère que vous allez pouvoir m’aider car je tiens au peu de cheveux qui me reste.

Vois-tu dans un terminal les messages “10 minutes till system powers down…” quand le courant est coupé et “power restored” quand le courant revient ?

salut,

c’est un exercice ?
vous êtes combien dans votre classe ?

parce que j’ai déjà donné une réponse à ce sujet sur un autre site…

spread the word ! :laughing:

le script ne testant pas “en continu” l’état de l’alimentation, il ne peut pas y avoir de changement de comportement.

oui, je les vois.

une réponse déjà donnée ?
où cela ?
peut-on la voir ici ?

sur le forum de hardware.fr, dans la section Codes et scripts, sous Linux et OS alternatifs, en adoptant la forme d’un pseudo-code.

ah !
J’y suis allé, j’ai vu et je suis revenu.
Mon latin est sans doute meilleur car je ne vois pas pourquoi il se met à redémarrer.
Où est l’erreur ?

quelles sont les modifications apportées au script ?
tu peux nous copier la nouvelle version ?

c’est la version qu’on peut voir plus haut :
dans NOTIFYCMD “/etc/nut/notifycmd”

#!/bin/bash
#

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
trap "exit 0" SIGTERM
if [ "$NOTIFYTYPE" = "ONLINE" ]
then
        echo $0: power restored | wall
        curl "command"
        #sleep 5
        # Cause all instances of this script to exit.
        killall -s SIGTERM `basename $0`
fi
if [ "$NOTIFYTYPE" = "ONBATT" ]
then
        echo $0: 10 minutes till system powers down... | wall
        curl "command!"
        # Loop with one second interval to allow SIGTERM reception.
		let "n = 600"
        while [ $n -ne 0 ]
        do
                sleep 1
                let "n--"
        done
        echo $0: commencing shutdown | wall
        upsmon -c fsd
fi

le “bug” se trouverait là, mais je ne le vois pas.
(10 minutes après le retour de courant, le Raspeberry fait éteindre l’onduleur et se met à rebooter).
Ça me rend dingue.

bon en fait pour résoudre ce problème il faut passer par upssched qui offre plus de possibilités (en outre celle de terminer les timers).
Mais j’ai toujours un problème.
Voici la nouvelle configuration:

Le fichier /etc/nut/upsmon.conf
> MONITOR eaton@localhost 1 admin password master

MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h now"
HOSTSYNC 15
POWERDOWNFLAG /etc/nut/killpower
FINALDELAY 5
NOTIFYCMD /sbin/upssched
NOTIFYMSG ONBATT "%s is on battery"
NOTIFYMSG ONLINE "%s is back online"
NOTIFYMSG SHUTDOWN "System is being shutdown!"
NOTIFYFLAG ONLINE SYSLOG+EXEC
NOTIFYFLAG ONBATT SYSLOG+EXEC
NOTIFYFLAG SHUTDOWN SYSLOG+EXEC

Celui de /etc/nut/upssched.conf
CMDSCRIPT /usr/bin/upssched-cmd

PIPEFN /var/run/nut/upssched/upssched.pipe
LOCKFN /var/run/nut/upssched/upssched.lock

AT ONBATT * START-TIMER upssms 30
AT ONLINE * CANCEL-TIMER upssms

AT ONBATT * START-TIMER upsgone 150
AT ONLINE * CANCEL-TIMER upsgone

AT ONLINE * EXECUTE ups-back-on-power

Et, enfin le script /usr/bin/upssched-cmd :

#!/bin/bash
case $1 in
upssms)
logger -t upssched-cmd “The UPS has been gone for 30 secs. Warn by sms…”
/bin/echo “Power failed. System will hibernate soon…” | curl “command”
;;
upsgone)
logger -t upssched-cmd “The UPS has been gone for 2 and a half minutes. Hibernating…”
/usr/sbin/upsmon -c fsd # call a shutdown in NUT instead
;;
ups-back-on-power)
logger -t upssched-cmd “The UPS power has been restored.”
/bin/echo “Power restored.” | curl “command”
;;
*)
logger -t upssched-cmd "Unrecognized command: $1"
esac

Le problème est le suivant :
Quand le courant est rétabli l’alerte fonctionne (ups-back-on-power).
Par contre quand le courant est coupé, je ne reçois pas l’alerte générée par CURL (la commande fonctionne pourtant dans upssms).

Et je vois pas pourquoi.
Où est-ce que ça coince d’après vous ?