logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#26 17-12-2021 03: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" ?

Hors ligne

#27 17-12-2021 04:54:47

anonyme
Invité

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
 



dans /sbin/  j'ai 2 scripts "upsd" et "upsmon" et 2 binaires "upsdrvctl" et "upssched"

Dernière modification par anonyme (17-12-2021 05:06:30)

#28 17-12-2021 10:38:35

anonyme
Invité

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"
 


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  roll
ps: l'onduleur pour moi est en cour de livraison entre 8h et 18h    hmm

Dernière modification par anonyme (17-12-2021 10:41:15)

#29 17-12-2021 12:01:55

anonyme
Invité

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 12:34:49

anonyme
Invité

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
 


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  smile

#31 17-12-2021 18: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.

Hors ligne

#32 17-12-2021 19:29:39

anonyme
Invité

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
 


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  roll
sur debian pas terrible   hmm  (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 19:41:05)

#33 18-12-2021 08:53:43

anonyme
Invité

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
 


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 05:29:25

anonyme
Invité

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  roll

#35 19-12-2021 14:54:17

anonyme
Invité

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
 



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 15:42:49)

#36 20-12-2021 00: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 :

# 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.



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.



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.



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 00:26:14)

Hors ligne

#37 20-12-2021 06:57:43

anonyme
Invité

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...
 



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 07:03:44)

#38 20-12-2021 09: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

#maxretry = 3
[eaton650]
    driver = usbhid-ups
    port = auto
 



et le ficher upsd.users

[admin]
        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 09:38:14)

Hors ligne

#39 20-12-2021 15:12:00

anonyme
Invité

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
 


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 15:26:16)

#40 20-12-2021 15:50:07

anonyme
Invité

Re : Problème de communication nut/onduleur

pour les tests toujours mauvais  roll


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 15:52:49)

#41 20-12-2021 17:22:49

anonyme
Invité

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
 


j'ai bien reçu le mail local sur la machine

mais tu vois que le shutdown ne fonctionne pas  roll

#42 20-12-2021 18: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



$ 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



$ 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.



$ 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.



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
 

Dernière modification par Sty_X (20-12-2021 18:51:24)

Hors ligne

#43 20-12-2021 19:22:05

anonyme
Invité

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.
 



je pourrai te donner mes scripts , mais je pense que tu connais mieux que moi   tongue  wink
ps: je regarde ton #42

#44 20-12-2021 19:27:53

anonyme
Invité

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
 

#45 20-12-2021 19:31:34

anonyme
Invité

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  smile

Dernière modification par anonyme (20-12-2021 19:34:04)

#46 20-12-2021 19:41:49

anonyme
Invité

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
 


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 19:46:16

anonyme
Invité

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
 



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 19:47:49)

#48 20-12-2021 19:55:24

anonyme
Invité

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.
 


il est prévue de faire 3 tentatives en cas d' échec du driver

la batterie fatiguée  tongue
la version du firmware de l'onduleur


battery.charge: 32

ups.firmware: 02.08.0010
 

Dernière modification par anonyme (20-12-2021 20:00:53)

#49 20-12-2021 23: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  smile


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


A cela :

PIPEFN /var/run/nut/upssched.pipe
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 smile


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)


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  tongue
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



En même temps la ligne est commentée dans le fichier ups.conf

#maxretry = 3
[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

Hors ligne

#50 21-12-2021 02:15:04

anonyme
Invité

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 .

Pied de page des forums