# Vérifier la configuration et le bon fonctionnement de son onduleur **URL:** \ **Category:** Support Debian\ **Tags:** onduleur, serveur, buster, systemd\ **Created:** [Janvier 21, 2021, 11:17 UTC](https://www.debian-fr.org/t/verifier-la-configuration-et-le-bon-fonctionnement-de-son-onduleur/83783 "2021-01-21T11:17:45Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![anon46052761](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/e274bd/32.png) [@anon46052761](https://www.debian-fr.org/u/anon46052761)\ **Post date:** [Janvier 21, 2021, 11:17 UTC](https://www.debian-fr.org/t/verifier-la-configuration-et-le-bon-fonctionnement-de-son-onduleur/83783/1 "2021-01-21T11:17:45Z")
Bonjour, J’ai un MGE Ellipse 600 avec une batterie auto 12 V DC classique : un bricolage qui marche bien. Je dois m’assurer que mon onduleur est bien configuré dans ma Buster serveur. Puisque je vais probablement laisser le serveur allumé plus souvent et plus longtemps, la fonction UPS est indispensable. J’ai la crainte qu’un processus bloque la séquence d’arrêt et me contraigne à forcer l’arrêt, par l’appui long sur le bouton (la pire des choses) ou de préférence avec [l’emploi de la séquence REISUB ou plutôt REISUO](https://www.debian-fr.org/t/maj-vers-buster-problemes-nvidia/79747/15) J’ai passé des moments avec plusieurs documentations pour aboutir à quelque chose qui devrait encore fonctionner mais c’est tellement essentiel à mes yeux que je souhaite vérifier tout ça du début à la fin. Pour le moment, j’ai une connexion avec le MGE600 ``` root@n40l:~# upsc MGE600 Init SSL without certificate database battery.charge: 100 battery.charge.low: 90 battery.runtime: 668 battery.type: PbAc battery.voltage.high: 13.6 battery.voltage.low: 12 device.mfr: MGE UPS SYSTEMS device.model: Ellipse 600 device.serial: AP8G49073 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 10 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.data: MGE HID 1.39 driver.version.internal: 0.41 input.transfer.high: 264 input.transfer.low: 184 outlet.1.desc: PowerShare Outlet 1 outlet.1.id: 2 outlet.1.status: on outlet.1.switchable: no outlet.desc: Main Outlet outlet.id: 1 outlet.switchable: no 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.load: 15 ups.mfr: MGE UPS SYSTEMS ups.model: Ellipse 600 ups.power.nominal: 600 ups.productid: ffff ups.serial: AP8G49073 ups.status: OL ups.timer.shutdown: -1 ups.timer.start: -10 ups.vendorid: 0463 root@n40l:~# ``` J’ai modifié le paramètre « battery.charge.low: 65 » ``` root@n40l:~# uname -a Linux n40l 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux root@n40l:~# ``` * * * L’origine en 2016 > [@NUT : Onduleur UPS MGE Ellipse](https://www.debian-fr.org/t/nut-onduleur-ups-mge-ellipse/66989): > > Bonsoir, J’ai un onduleur MGE UPS SYSTEMS Ellipse 600 MAX ; Pas un Eaton [image] Il dispose d’une prise RJ45 femelle (COM) Modifié, il fonctionne sur batterie de voiture 50 Ah Grâce à : [http://www.hacker-maker.com/2013/11/cable-rj45-usb-pour-onduleur-mge.html](http://www.hacker-maker.com/2013/11/cable-rj45-usb-pour-onduleur-mge.html) J’ai réussi à concevoir le câble : rem@n40l:~$ lsusb -s 004:006 Bus 004 Device 006: ID 0463:ffff MGE UPS Systems UPS Ce système NUT (Network UPS Tools) m’est totalement nouveau ; Je ne sais pas à quoi m’attendre. Pourrai-je avoir … * * * Un sujet de [ttufekk](https://www.debian-fr.org/u/ttufekk) > [@Configuration onduleur (NUT)](https://www.debian-fr.org/t/configuration-onduleur-nut/79885): > > Hello à tous, Je viens d’investir dans un onduleur (un Eaton 3s) sur lequel j’ai branché un raspberry-pi (Raspbian 9.9 et Yunohost 3.6) en suivant [ce tuto](http://www.bernaerts-nicolas.fr/linux/75-debian/335-debian-wheezy-install-monitor-eaton-ups) . Tout fonctionne nickel mais en jouant (ma question est donc pas hyper urgente donc…) avec les différentes commandes je me rends compte que je ne peux pas modifier la variable battery.charge.low via la commande : # upsrw -s battery.charge.low=35 -u upsmonitor -p mot-de-passe eaton@localhost (j’ai utilisé les mêmes username que dans le tuto… * * * Mes onduleurs avec batteries auto PbAc 45 Ah : [https://forum.macbidouille.com/index.php?s=&showtopic=371927&view=findpost&p=4190801](https://forum.macbidouille.com/index.php?s=&showtopic=371927&view=findpost&p=4190801) ---
**Author:** ![anon46052761](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/e274bd/32.png) [@anon46052761](https://www.debian-fr.org/u/anon46052761)\ **Post date:** [Janvier 21, 2021, 2:04 UTC](https://www.debian-fr.org/t/verifier-la-configuration-et-le-bon-fonctionnement-de-son-onduleur/83783/2 "2021-01-21T14:04:23Z")
> [@](#): > > Après des modifications de configuration et pour redémarrer NUT (Network UPS Tools) sans redémarrer la machine : > > ```auto > sudo systemctl restart nut-driver.service > sudo systemctl restart nut-server.service > sudo systemctl restart nut-monitor.service > > ``` ---
**Author:** ![ttufekk](https://www.debian-fr.org/user_avatar/www.debian-fr.org/ttufekk/32/7636_2.png) [@ttufekk](https://www.debian-fr.org/u/ttufekk)\ **Post date:** [Janvier 21, 2021, 4:04 UTC](https://www.debian-fr.org/t/verifier-la-configuration-et-le-bon-fonctionnement-de-son-onduleur/83783/3 "2021-01-21T16:04:13Z")
Je suis pas sûr de comprendre ta question, tu veux checker si la séquence de shutdown s’exécute correctement c’est ça? Peut-être que cette doc pourrait t’intéresser si c’est le cas. [https://dan.langille.org/2020/09/10/nut-testing-the-shutdown-mechanism/](https://dan.langille.org/2020/09/10/nut-testing-the-shutdown-mechanism/) ---
**Author:** ![anon46052761](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/e274bd/32.png) [@anon46052761](https://www.debian-fr.org/u/anon46052761)\ **Post date:** [Janvier 22, 2021, 3:28 UTC](https://www.debian-fr.org/t/verifier-la-configuration-et-le-bon-fonctionnement-de-son-onduleur/83783/4 "2021-01-22T03:28:29Z")
Bonjour, C’est un peu normal que tu ne sois pas sûr de comprendre ma question car j’en ai pas réellement posé. Je me souviens avoir eu des difficultés de compréhension lors d’une ou deux étapes de la configuration et en même temps cela fait si longtemps. Je vais faire comme si la configuration avait été faite par un autre et tout vérifier à l’aide des tutos disponibles. Je reviendrai poser des questions si besoin. Merci pour le lien. Bien sûr que je veux voir si la séquence de shutdown s’exécute correctement. Je crois me souvenir qu’elle s’exécute un peu rapidement. ``` rem@n40l:~$ sudo /usr/local/sbin/upsdrvctl -t shutdown [sudo] Mot de passe de rem : sudo: /usr/local/sbin/upsdrvctl : commande introuvable rem@n40l:~$ locate upsdrvctl /sbin/upsdrvctl /usr/share/man/man8/upsdrvctl.8.gz rem@n40l:~$ sudo /sbin/upsdrvctl -t shutdown Network UPS Tools - UPS driver controller 2.7.4 *** Testing mode: not calling exec/kill 0.000000 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.000399 Shutdown UPS: MGE600 0.000438 exec: /lib/nut/usbhid-ups -a MGE600 -k rem@n40l:~$ ``` . ``` rem@n40l:/etc/nut$ sudo grep shutdown *.conf ups.conf:# a UPS from the shutdown sequence, set this to -1. upsmon.conf:#SHUTDOWNCMD "/sbin/shutdown -h now" upsmon.conf:NOTIFYMSG SHUTDOWN "System is being shutdown!" upsmon.conf:# "master" means this system will shutdown last, allowing the slaves upsmon.conf:# time to shutdown first. upsmon.conf:#SHUTDOWNCMD "/sbin/shutdown -h +0" upsmon.conf:# disconnect once it has set the forced shutdown (FSD) flag. If they upsmon.conf:# to a low battery condition. This may force a shutdown if it is providing upsmon.conf:# POWERDOWNFLAG - Flag file for forcing UPS shutdown on the master system upsmon.conf:# your shutdown scripts and run 'upsdrvctl shutdown' if it exists. upsmon.conf:# See the shutdown.txt file in the docs subdirectory for more information. upsmon.conf:# NOTIFYMSG FSD "UPS %s: forced shutdown in progress" upsmon.conf:# NOTIFYMSG SHUTDOWN "Auto logout and shutdown proceeding" upsmon.conf:# NOTIFYMSG NOPARENT "upsmon parent process died - shutdown impossible" upsmon.conf:# FSD : UPS is being shutdown by the master (FSD = "Forced Shutdown") upsmon.conf:# SHUTDOWN : The system is being shutdown upsmon.conf:# NOPARENT : The process that shuts down the system has died (shutdown impossible) upsmon.conf:# battery and will require a value of 0 here for a safe shutdown. upssched.conf:#AT ONBATT * START-TIMER earlyshutdown 10 upssched.conf:#AT ONLINE * CANCEL-TIMER earlyshutdown rem@n40l:/etc/nut$ ``` C’est un vrai bazar ! Tout semble commenté… J’ai repris une des commandes du lien proposé par [ttufekk](https://www.debian-fr.org/u/ttufekk) mais il y a tellement de parties commentées dans les `/etc/nut/*.conf` que cette deuxième partie est inutile. En plus acceptable : ``` rem@n40l:/etc/nut$ sudo grep -i shutdown *.conf | grep -v '#' upsmon.conf:SHUTDOWNCMD "/bin/systemctl poweroff" upsmon.conf:NOTIFYMSG SHUTDOWN "System is being shutdown!" upsmon.conf:NOTIFYFLAG SHUTDOWN SYSLOG+EXEC upssched.conf:AT ONBATT * START-TIMER earlyshutdown 90 upssched.conf:AT ONLINE * CANCEL-TIMER earlyshutdown rem@n40l:/etc/nut$ ``` ---
**Author:** ![anon46052761](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/e274bd/32.png) [@anon46052761](https://www.debian-fr.org/u/anon46052761)\ **Post date:** [Janvier 22, 2021, 4:58 UTC](https://www.debian-fr.org/t/verifier-la-configuration-et-le-bon-fonctionnement-de-son-onduleur/83783/5 "2021-01-22T04:58:21Z")
J’ai commencé par établir un `/var/log/nut.log` séparé. ``` root@n40l:~# cat /etc/rsyslog.d/99-nut.conf :syslogtag,contains,"upsmon" /var/log/nut.log :syslogtag,contains,"nut" /var/log/nut.log :syslogtag,contains,"upssched" /var/log/nut.log root@n40l:~# ``` . ``` root@n40l:~# touch /var/log/nut.log root@n40l:~# chown root:adm /var/log/nut.log root@n40l:~# chmod 640 /var/log/nut.log root@n40l:~# systemctl restart rsyslog ``` Merci d’intervenir si besoin. source : [https://ubuntuforums.org/showthread.php?t=2424036&p=13902797#post13902797](https://ubuntuforums.org/showthread.php?t=2424036&p=13902797#post13902797) ---
**Author:** ![anon46052761](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/e274bd/32.png) [@anon46052761](https://www.debian-fr.org/u/anon46052761)\ **Post date:** [Janvier 22, 2021, 8:04 UTC](https://www.debian-fr.org/t/verifier-la-configuration-et-le-bon-fonctionnement-de-son-onduleur/83783/6 "2021-01-22T08:04:45Z")
J’ai relu mon sujet [NUT : Onduleur UPS MGE Ellipse](https://www.debian-fr.org/t/nut-onduleur-ups-mge-ellipse/66989) ainsi que l’ébauche [Configurer et surveiller un onduleur avec NUT](https://wiki.debian-fr.xyz/Configurer_et_surveiller_un_onduleur_avec_NUT) J’ai vérifié et adapté ma configuration. Je trouve une espèce de doublon pour la commande d’arrêt dans l’ensemble de la configuration. Dans `/etc/nut/upsmon.conf` il y a une directive SHUTDOWNCMD Elle est mise à `"/bin/systemctl poweroff -i -f"` dans mon serveur. Et dans `/bin/upssched-cmd` il y a un appel à `upsmon -c fsd` après le dernier timer. NOTE : `upsmon -c fsd` éteint électriquement mon onduleur pendant une poignée de secondes. C’est pas une bonne affaire pour l’équipement qui y est relié ! Pourquoi avoir deux commandes d’arrêt différentes ? Laquelle va être utilisée ? D’après [Arrêter proprement sa machine à l'aide d'un script](https://www.debian-fr.org/t/arreter-proprement-sa-machine-a-laide-dun-script/79934/8) je vais placer un simple `/bin/systemctl poweroff` aux deux emplacements. Il devrait être possible d’utiliser `sudo /sbin/upsdrvctl shutdown` également. * * * Plus loin, au terme de ma recherche et de l’expérimentation, je choisis de revenir sur `upsmon -c fsd` comme commande d’arrêt. Je pense que c’est probablement la meilleure manière pour ne pas subir de blocage avant l’arrêt. La directive SHUTDOWNCMD ne semble plus servir. ---
**Author:** ![anon46052761](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/e274bd/32.png) [@anon46052761](https://www.debian-fr.org/u/anon46052761)\ **Post date:** [Janvier 22, 2021, 11:58 UTC](https://www.debian-fr.org/t/verifier-la-configuration-et-le-bon-fonctionnement-de-son-onduleur/83783/7 "2021-01-22T11:58:03Z")
Je n’avais pas testé depuis que j’ai changé le bloc d’alimentation. Fin 2018, je suis passé de la 150 Watts d’origine à une de 350 Watts neuve. Mon onduleur 600VA / 360 W ne supporte pas la charge que je lui demande. Je dois la diminuer avant de retester, quitte à laisser seulement le serveur. Si la configuration est bonne ce serait suffisant pour le protéger. Quand je coupe l’alimentation de l’onduleur, le serveur gèle et les connexions SSH sont gelées. Les voyants du serveur continuent d’être allumés et de clignoter comme si de rien n’était. Et l’écran passe en veille aussitôt. Quand je rebranche l’onduleur, le serveur se réinitialise mais mal. Figé au premier écran du BIOS. Je dois appuyer brièvement sur le bouton pour qu’il s’éteigne. Je vais placer des charges sur mon deuxième onduleur. Mes deux écrans, mon transportable, le routeur AP Wifi et le switch. ---
**Author:** ![anon46052761](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/e274bd/32.png) [@anon46052761](https://www.debian-fr.org/u/anon46052761)\ **Post date:** [Janvier 22, 2021, 2:35 UTC](https://www.debian-fr.org/t/verifier-la-configuration-et-le-bon-fonctionnement-de-son-onduleur/83783/8 "2021-01-22T14:35:21Z")
L’onduleur supporte la charge du serveur seul. Les timers ne se cumulent pas dans l’exemple ci-dessous. ``` root@n40l:~# tail -f /var/log/syslog ... Jan 22 15:26:48 n40l upsmon[920]: MGE600@127.0.0.1 is on battery Jan 22 15:26:48 n40l upssched[1553]: Timer daemon started Jan 22 15:26:48 n40l upssched[1553]: New timer: onbat60 (60 seconds) Jan 22 15:26:48 n40l upssched[1553]: New timer: earlyshutdown (90 seconds) Jan 22 15:26:48 n40l upssched[1553]: New timer: onbattwarn (120 seconds) Jan 22 15:27:48 n40l upssched[1553]: Event: onbat60 Jan 22 15:27:48 n40l upssched-cmd: Système sur onduleur (onbat60) Jan 22 15:27:48 n40l upssched-cmd: Exécution de /usr/local/bin/stoptout.sh Jan 22 15:28:18 n40l upssched[1553]: Event: earlyshutdown Jan 22 15:28:18 n40l upssched-cmd: Système sur onduleur (earlyshutdown 90) Jan 22 15:28:48 n40l upssched[1553]: Event: onbattwarn Jan 22 15:28:48 n40l upssched-cmd: Arrêt système avec : upsmon -c fsd (onbattwarn 120) Jan 22 15:28:48 n40l upsmon[920]: Signal 10: User requested FSD Jan 22 15:28:48 n40l upsd[913]: Client admin@127.0.0.1 set FSD on UPS [MGE600] Jan 22 15:28:48 n40l upsmon[920]: Executing automatic power-fail shutdown Diffusion de message de nut@n40l (somewhere) (Fri Jan 22 15:28:48 2021) : Executing automatic power-fail shutdown Jan 22 15:28:48 n40l upsmon[920]: System is being shutdown! Connection to n40l closed by remote host. Connection to n40l closed. rem@n73sm ~ $ ``` ---
**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\ **Post date:** [Janvier 23, 2021, 8:17 UTC](https://www.debian-fr.org/t/verifier-la-configuration-et-le-bon-fonctionnement-de-son-onduleur/83783/9 "2021-01-23T08:17:31Z")
A scindé ce sujet (le Janvier 23, 2021, 8:17 UTC) 3 messages ont été scindés en un nouveau sujet : [Puissances des onduleurs](https://www.debian-fr.org/t/puissances-des-onduleurs/83797)