Problème nut et onduleur

par **dlalleme** » 02 Mars 2007 09:16

Bonjour,

Depuis la dernière mise à jour 7.1.1, tous mes onduleurs arrêtent mes serveurs alors qu'il n'y a pas de raison. J'ai l'impression qu'un shutdown est programmé au bout d'un certain temps ....

Je reçois également beaucoup de messages dans lesquels il m'indique, une fois problème de communication, une autre fois batterie basse, etc ...

Les onduleurs sont des MGE dernières versions via USB.

La version précédente ne me faisait pas ce problème...

Cordialement

Denis

par **Titofe** » 02 Mars 2007 13:46

Même problème, j’ai fait la mise à jour des serveurs hier dans l’heures qui à suivi ils ont tous étais couper par l’onduleur et à chaque fois que je l’ai rallume même problème avec des type de message différent que je reçois par mail qui sont complètement incorrect !!!

Pour le moment j’ai enlevé le câble USB de chaque onduleur, en attendant de trouver une solution …

Mais onduleur sont aussi des MGE Ellipse 1000.

par **barroud** » 02 Mars 2007 13:46

Bonjour,
J'ai exactement le même problème dont j'ai parlé dans le topic de mise à jour SME 7.1.1. J'ai dû arrêter le service nut pour éviter qu'il n'éteigne ma SME et j'ai pas eut le temps de plus regarder encore.

:edit: J'ai aussi un MGE Ellipse 1000.

Cordialement,

Barroud.

par **unnilennium** » 02 Mars 2007 20:18

des retour avec les APC Back-UPS en USB ... histoire qu eje mette pas a jour les serveur si c le cas ...

JPP

par **Titofe** » 04 Mars 2007 21:24

Je relance ce post pour savoir si d’autre personne on eu ce type de problème et si eu on trouver une solution, sinon la chose que j’en retient c’est que je ne ferais plus de mise à jour sans attendre quelque mois pour voir les retombés …

Titofe

par **Titofe** » 05 Mars 2007 09:58

Voila ce que j’ai quand je tape upsc ups@localhost

Code: Tout sélectionner: [root@serveur10 ~]# upsc ups@localhost battery.charge: 100 battery.charge.low: 30 battery.runtime: 3400 battery.type: PbAc driver.name: newhidups driver.parameter.port: /var/lib/ups/hiddev0 driver.version: 2.0.5 driver.version.data: MGE HID 1.0 driver.version.internal: 0.30 input.transfer.high: 264.0 input.transfer.low: 184.0 outlet.0.desc: Main Outlet outlet.0.id: 1 outlet.0.switchable: no outlet.1.desc: PowerShare Outlet 1 outlet.1.id: 2 outlet.1.status: on outlet.1.switchable: no output.voltage: 230.0 ups.beeper.status: enabled ups.delay.shutdown: -1 ups.delay.start: -10 ups.load: 4 ups.mfr: MGE UPS SYSTEMS ups.model: Ellipse 1000 ups.power.nominal: 1000 ups.serial: 1H6G270AP ups.status: OL CHRG

Hormis si ma lecture est mauvaise, mais tout est ok, autant pour le modèle reconnu, son drivers et de ces batterie, pourtant j’ai des mails qui me dise complètement l’inverse, jusqu'à l’interruption du serveur, à savoir que j’ai deux serveur SME 7.1.1 avec les mêmes onduleurs et trois autres Windows avec eu aussi les mêmes onduleurs que les SME, donc je peux confirmer que le problème ne viens pas des onduleurs.

Par contre je n’ai pas d’idée pour rectifié le problème car peut importe les paramètres que je regarde ils sont tous ok.

Titofe

par **Franck78** » 05 Mars 2007 15:34

Salut,

Trouve le prog qui utilise les données que tu présentes.

Il y comme qui dirait un petit bug dedans. ;-)

par **Titofe** » 05 Mars 2007 17:25

Merci de ton aide, mais je ne vois pas le bug que tu aurai aperçu et vu mon niveau je ne sais pas qui utilise c’est information …(Je veux dire ou chercher)
Si tu peux en dire plus, merci.

Titofe

par **Franck78** » 05 Mars 2007 19:47

Je n'ai pas aperçu de bug. Je te donne la démarche:
-trouver le prog qui utilise ces infos.
-parcourir ce prog

par **boblefou** » 06 Mars 2007 09:30

Salut,
J'ai exactement le même problème avec onduleur MGE Pulsar M3000. Onduleur OnLine mais arrêt du serveur (toujours content d'arriver le mati avec un serveur éteint...).

Bref, il y a un soucis. Pour ma part, déconnexion immédiate du port série, on va pas recommencer comme cela.

Premier pas, analyse des logs et pour ma part :

Code: Tout sélectionner: Mar 5 20:14:59 smeserver1 upsmon[3422]: UPS UPS@localhost on battery Mar 5 20:14:59 smeserver1 upsmon[3422]: UPS UPS@localhost battery is low Mar 5 20:14:59 smeserver1 upsd[3417]: Client upsmaster@127.0.0.1 set FSD on UPS [UPS] Mar 5 20:14:59 smeserver1 upsmon[3422]: Executing automatic power-fail shutdown

Le responsable ? Upsmon, il est même très fort, car sur la même seconde, il arrive a dire que l'onduleur est sur batterie et tout de suite après que celles-ci sont vide...
J'ai contrôler l'historique de l'onduleur (physiquement sur celui-ci), et il n'y a pas eu de coupure de courant, i m'affiche même 87min d'autonomie et pas 1 seconde.

La configuration de upsmon se fait à l'aide du fichier /etc/ups/upsmon.conf
Après analyse et comparaison entre une SME7.1 et la SME7.1.1 voila les lignes rajoutées :

Code: Tout sélectionner: NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC NOTIFYFLAG FSD SYSLOG+WALL+EXEC NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC

Il y a peut-être un problème d'interprétation des ligne LOWBATT et ONBATT...
Piste a suivre, je cherche de mon coté.

par **Franck78** » 06 Mars 2007 10:16

il n'y a pas d'APC concerné dans cette histoire?
oui: bug localisé avec merlin gérin

C'est plus sur de ne pas lancer "upsmon" que de débrancher la cable! En tout cas c'est la qu'il vous faut creuser. Quels changement par rapport à 'avant quand ca marchait' ?

par **Uzuul** » 16 Mars 2007 11:07

salut a tous,

désolé pour le temps de réponse, mais il est préférable de me contacter directement, ie sur mon adresse de dev (http://lists.alioth.debian.org/pipermai ... 01840.html) ou sur l'adresse de support MGE (http://opensource.mgeups.com/contacts.htm)

Les pb que vous rencontrez sont étonnants ! Surtout que mon pilote newhidups est le meme pour les apc, et autres. Donc, s'il y avait un bug de code, il devrait se retrouver sur _tous_ les modeles, et pas seulement les mge !

je n'ai pas de sme sous la main (ni le temps d'en installer une), mais j'ai testé sur Debian, Ubuntu, RH, SuSE, et Mandriva dans différentes versions, sans apercevoir ce pb...

j'aurai donc besoin d'un certain nombre d'info pour auditer. Merci de m'envoyer ces infos en directe :
- type d'arch (i386, x86_64, ...),
- modele de l'onduleur,
- grep ups /var/log/syslog (ou equivalent),
- details et frequence du pb (ex: 5 mn apres le boot, ...),
- fichiers de conf: ups.conf, upsmon.conf (+ upssched.conf si utilisé)

A noter :
- le mieux pour désactiver le shutdown en conservant le monitoring (voir les événements) est de vider la ligne SHUTDOWNCMD "/sbin/shutdown -h +0" => SHUTDOWNCMD "".
- si la version précédente fonctionne (et le test serait intéressant a faire), revenez sur celle ci.

Derniere question : quelle était la version dans SME7.1

Arnaud
--
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/

par **barroud** » 17 Mars 2007 11:59

Bonjour,
Pour ma part :

arch : i686
Modèle : MERLIN GERIN ELLIPSE ASR 1000 USBS (USB + SÉRIE) 1000 VA/600 W
J'utilise le port USB.

ups.conf :

Code: Tout sélectionner: [UPS] driver = newhidups port = /var/lib/ups/hiddev0

upsmon.conf :

Code: Tout sélectionner: DEADTIME 15 FINALDELAY 5 HOSTSYNC 15 MINSUPPLIES 1 MONITOR UPS@localhost 1 upsmaster coLCBS3UQhhq0fZ9FNzQcH2t8xu+PAjk/pnKEl4BSux4u0Pt+O8cd/LgyJBnq+joakzVt3xsu57l master NOCOMMWARNTIME 300 NOTIFYCMD /sbin/e-smith/nutUPS.notify NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC NOTIFYFLAG FSD SYSLOG+WALL+EXEC NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC POLLFREQ 5 POLLFREQALERT 5 POWERDOWNFLAG /etc/killpower RBWARNTIME 43200 SHUTDOWNCMD "/sbin/e-smith/signal-event halt"

Message

Code: Tout sélectionner: Mar 16 20:46:20 hades upsdrvctl: Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.0.5) Mar 16 20:46:20 hades upsdrvctl: Mar 16 20:46:20 hades upsdrvctl: Detected a UPS: MGE UPS SYSTEMS/ELLIPSE Mar 16 20:46:20 hades upsdrvctl: Using subdriver: MGE HID 1.0 Mar 16 20:46:24 hades newhidups[15216]: Startup successful Mar 16 20:46:24 hades upsdrvctl: Network UPS Tools - UPS driver controller 2.0.5 Mar 16 20:46:24 hades nut: Démarrage de upsdrvctl succeeded Mar 16 20:46:24 hades upsd: Connected to UPS [UPS]: UPS Mar 16 20:46:24 hades upsd[15219]: Connected to UPS [UPS]: UPS Mar 16 20:46:24 hades upsd[15220]: Startup successful Mar 16 20:46:24 hades nut: Démarrage de upsd succeeded Mar 16 20:46:24 hades upsmon: UPS: UPS@localhost (master) (power value 1) Mar 16 20:46:24 hades upsmon[15224]: Startup successful Mar 16 20:46:24 hades upsd[15220]: Connection from 127.0.0.1 Mar 16 20:46:24 hades upsd[15220]: Client upsmaster@127.0.0.1 logged into UPS [UPS] Mar 16 20:46:24 hades upsmon: Using power down flag file /etc/killpower Mar 16 20:46:24 hades upsmon: Mar 16 20:46:24 hades nut: Démarrage de upsmon succeeded Mar 16 20:56:54 hades upsmon[15225]: UPS UPS@localhost battery needs to be replaced Mar 16 21:11:39 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 16 21:55:55 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 16 23:01:17 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 16 23:13:47 hades kernel: usb 3-1: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 161 rq 1 len 2 ret -32 Mar 16 23:13:48 hades kernel: usb 3-1: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 128 rq 6 len 256 ret -110 Mar 16 23:13:49 hades kernel: usb 3-1: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 128 rq 6 len 256 ret -110 Mar 16 23:13:50 hades upsd[15220]: Data for UPS [UPS] is stale - check driver Mar 16 23:13:50 hades kernel: usb 3-1: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 128 rq 6 len 256 ret -110 Mar 16 23:13:51 hades kernel: usb 3-1: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 128 rq 6 len 256 ret -110 Mar 16 23:13:52 hades kernel: usb 3-1: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 128 rq 6 len 256 ret -110 Mar 16 23:13:52 hades upsmon[15225]: Poll UPS [UPS@localhost] failed - Data stale Mar 16 23:13:52 hades upsmon[15225]: Communications with UPS UPS@localhost lost Mar 16 23:13:53 hades upsd[15220]: UPS [UPS] data is no longer stale Mar 16 23:13:53 hades kernel: usb 3-1: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 128 rq 6 len 256 ret -110 Mar 16 23:13:57 hades upsmon[15225]: Communications with UPS UPS@localhost established Mar 16 23:30:12 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 16 23:31:57 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 16 23:39:47 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 16 23:47:58 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 00:07:08 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 00:14:38 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 00:23:03 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 00:28:43 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 00:42:04 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 01:02:44 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 01:07:29 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 01:12:34 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 01:12:59 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 01:36:30 hades upsmon[15225]: UPS UPS@localhost on battery Mar 17 01:36:40 hades upsmon[15225]: UPS UPS@localhost on line power Mar 17 01:47:25 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 01:52:25 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 02:09:16 hades upsmon[15225]: UPS UPS@localhost on battery Mar 17 02:09:21 hades upsmon[15225]: UPS UPS@localhost on line power Mar 17 02:24:57 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 02:37:37 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 03:19:20 hades upsmon[15225]: UPS UPS@localhost on battery Mar 17 03:19:20 hades upsmon[15225]: UPS UPS@localhost battery is low Mar 17 03:19:20 hades upsd[15220]: Client upsmaster@127.0.0.1 set FSD on UPS [UPS] Mar 17 03:19:20 hades upsmon[15225]: Executing automatic power-fail shutdown Mar 17 03:19:20 hades upsmon[15225]: Auto logout and shutdown proceeding Mar 17 03:19:25 hades upsd[15220]: Host 127.0.0.1 disconnected (read failure) Mar 17 03:19:36 hades ups: Arrêt de upsmon failed Mar 17 03:19:36 hades upsd[15220]: Signal 15: exiting Mar 17 03:19:36 hades ups: Arrêt de upsd succeeded

Cordialement,

Barroud.

par **daveledave** » 18 Mars 2007 14:18

Bonjour,

J'ai exactement le meme probleme avec la meme config.
Si qqun a la solution...

A+

David

par **Titofe** » 22 Mars 2007 12:18

Bonjour,

Retour de vacances donc je reprend le fil, j’ai lu qu’il serrai utile de faire le test de revenir en arrière pour NUT, je suis partant, mais j'ai besoin de confirmation :

Faut-il bien remplacer ces RPM là :

Code: Tout sélectionner: nut-2.0.5-1.el4.sme nut-client-2.0.5-1.el4.sme e-smith-nutUPS-1.2.0-8.el4.sme

Par cela (Version fourni pour SME 7.1):

Code: Tout sélectionner: nut-2.0.4-2.el4.sme nut-client-2.0.4-2.el4.sme e-smith-nutUPS-1.2.0-4.el4.sme

Pouvez-vous me le confirmé ?

Merci.

Titofe