Les services de NUT ne démarrent pas
Bien que sélectionnés pour cela
Système et matériels / Autres matériels et périphériques
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Reprise du message précédent
J'aimerais faire de teste, supprimer le timer et ajouter cette proposition avec le sleep :https://www.baeldung.com/linux/systemd-postpone-script-boot#adding-explicit-delays
ExecStartPre=/bin/sleep 120
Si le service ne démarre toujours pas, c'est bien let dépendances qui ne vont pas sur systemd. Et aucune idée comment débugger
Téléverser une image : /wiki/hebergement-de-fichiers-sur-mlo
| Arch | Machine | OS |
| x86_64 | lenovo x250 | mga9 |
| armv7hl | bananapro | mga9 |
| aarch64 | Raspberry Pi 4B | mga9 |
Meuz Membre non connecté
-
- Voir le profil du membre Meuz
- Inscrit le : 06/08/2011
- Groupes :
Code TEXT :
$ systemctl status nut-server
○ nut-server.service - Network UPS Tools - power devices information server
Loaded: loaded (/usr/lib/systemd/system/nut-server.service; enabled; preset: disabled)
Drop-In: /etc/systemd/system/nut-server.service.d
└─network.conf
Active: inactive (dead)...Je précise que nut-server.service comportait déjà un ExecStartPre. J'ai inséré le délai de 120 s comme suit :
Code TEXT :
… ExecStartPre=/bin/sleep 120 ExecStartPre=-/usr/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/nut-common-tmpfiles.conf …
Pour info, le fichier nut-server.service complet :
Caché :
Code TEXT :
[Unit]
Description=Network UPS Tools - power devices information server
After=local-fs.target network.target nut-driver.target
# We don't Require drivers to be successfully started! This would be
# a change of behavior compared to init SysV, and could prevent from
# accessing successfully started, at least to audit a system.
Wants=nut-driver.target
# The `upsd` is a networked service (even if bound to a `localhost`)
# so it requires that the OS has some notion of networking already.
# Extending the unit does not require *this* file to be edited, you
# can instead drop in an additional piece of configuration, e.g. to
# require that NUT data server only starts after external networking
# is configured (usable IP addresses appear in the system) you can
# add a `/etc/systemd/system/nut-server.service.d/network.conf` with:
# [Unit]
# Requires=network-online.target
# After=network-online.target
Requires=network.target
Before=nut-monitor.service
PartOf=nut.target
[Service]
# A busy server can be monitoring a lot of devices as well as replying
# to many clients. The "infinity" definition is actually capped by OS
# settings and hard-coded defaults; typically can be 65535+ nowadays.
# On 64-bit distros this can well be set into hundreds of thousands
# as well (though note each connection has a CPU and RAM overhead
# so one can strike physical limits upon deployment and/or bring the
# poorly sized system to a crawl, or worse). On a running system you
# can check /proc/$MAINPID/limits for active ulimits of the process.
# From my experiments, up to 1048576 can be set, but any larger value
# falls back to 65536. The systemd definition of "infinity" is 65536
# too (or maybe it falls back to that); though this may be OS/distro
# limitation and not systemd fault specifically.
#LimitNOFILE=infinity
#LimitNOFILE=65535
LimitNOFILE=1048576
EnvironmentFile=/etc/ups/nut.conf
SyslogIdentifier=%N
# DO NOT actually start if MODE is known and is "netclient" or "none";
# however do start (and maybe fail if not yet configured), for other
# MODE values or if nut.conf file is absent:
### Since systemd v243 ### ExecCondition=/bin/sh -c '[ x"${MODE}" != x"netclient" -a x"${MODE}" != x"none" ]'
# This should be executed by the system, but better safe than sorry
# (e.g. in custom rebuilds):
ExecStartPre=/bin/sleep 120
ExecStartPre=-/usr/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/nut-common-tmpfiles.conf
# Note: foreground mode "-F" by default skips writing a PID file (and
# needs default Type=simple); we can use "-FF" here to create the file
# anyway, so that old "upsd -c reload" works rather than systemd action:
ExecStart=/usr/sbin/upsd -F
ExecReload=/usr/sbin/upsd -c reload -P $MAINPID
ExecStartPost=-/usr/bin/grep -E 'Units|Max open files' /proc/${MAINPID}/limits
# No tracking for PIDFile path and service attribute here (it might not
# even exist).
# If "-FF" or background-daemon mode is used, so that PID file exists
# and "upsd -c stop" in particular can be used from command-line or
# legacy scripts, it causes a clean and intentional exit of the daemon.
# Then systemd should not revive it - hence restart it only on failure:
Restart=on-failure
Type=simple
#WatchdogSec=240s
[Install]
WantedBy=nut.target
Alias=upsd.serviceJybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
After=…?
Lancer aussi
systemd-verify nut-server? Je ne suis pas certain de la syntaxe
Téléverser une image : /wiki/hebergement-de-fichiers-sur-mlo
| Arch | Machine | OS |
| x86_64 | lenovo x250 | mga9 |
| armv7hl | bananapro | mga9 |
| aarch64 | Raspberry Pi 4B | mga9 |
Meuz Membre non connecté
-
- Voir le profil du membre Meuz
- Inscrit le : 06/08/2011
- Groupes :
Code BASH :
systemd-analyze verify nut-server.service
Aucune erreur retournée.
J'ai commenté
Code TEXT :
[Unit] Description=Network UPS Tools - power devices information server # After=local-fs.target network.target nut-driver.target
Pas de changement, nut-server est inactif après le démarrage.
Merci quand même de l'intérêt que tu y portes.
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
?
Téléverser une image : /wiki/hebergement-de-fichiers-sur-mlo
| Arch | Machine | OS |
| x86_64 | lenovo x250 | mga9 |
| armv7hl | bananapro | mga9 |
| aarch64 | Raspberry Pi 4B | mga9 |
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie