Existe-t-il un moyen de savoir quand un minuteur systemd s'exécutera ensuite?


19

Je teste un temporisateur systemd et j'essaie de remplacer son délai d'expiration par défaut, mais sans succès. Je me demande s'il existe un moyen de demander à systemd de nous dire quand le service sera exécuté ensuite.

Fichier normal ( /lib/systemd/system/snapbackend.timer):

# Documentation available at:
# https://www.freedesktop.org/software/systemd/man/systemd.timer.html

[Unit]
Description=Run the snapbackend service once every 5 minutes.

[Timer]
# You must have an OnBootSec (or OnStartupSec) otherwise it does not auto-start
OnBootSec=5min
OnUnitActiveSec=5min
# The default accuracy is 1 minute. I'm not too sure that either way
# will affect us. I am thinking that since our computers will be
# permanently running, it probably won't be that inaccurate anyway.
# See also:
# http://stackoverflow.com/questions/39176514/is-it-correct-that-systemd-timer-accuracysec-parameter-make-the-ticks-slip
#AccuracySec=1

[Install]
WantedBy=timers.target

# vim: syntax=dosini

Le fichier de remplacement ( /etc/systemd/system/snapbackend.timer.d/override.conf):

# This file was auto-generated by snapmanager.cgi
# Feel free to do additional modifications here as
# snapmanager.cgi will be aware of them as expected.
[Timer]
OnUnitActiveSec=30min

J'ai exécuté les commandes suivantes et la minuterie continue de fonctionner toutes les 5 minutes. Pourrait-il y avoir un bogue dans systemd?

sudo systemctl stop snapbackend.timer
sudo systemctl daemon-reload
sudo systemctl start snapbackend.timer

Alors je me demandais aussi, comment puis-je savoir quand la minuterie va tic-tac ensuite? Parce que cela me dirait immédiatement si c'est dans 5 min. ou 30 min. mais de la systemctl status snapbackend.timerne dit rien à ce sujet. Je me demande simplement s'il existe une commande qui me dirait le délai actuellement utilisé.

Pour ceux qui sont intéressés, il y a aussi le fichier de service ( /lib/systemd/system/snapbackend.service), bien que j'imagine que cela ne devrait pas avoir d'effet sur les tics du minuteur ...

# Documentation available at:
# https://www.freedesktop.org/software/systemd/man/systemd.service.html

[Unit]
Description=Snap! Websites snapbackend CRON daemon
After=snapbase.service snapcommunicator.service snapfirewall.service snaplock.service snapdbproxy.service

[Service]
# See also the snapbackend.timer file
Type=simple
WorkingDirectory=~
ProtectHome=true
NoNewPrivileges=true
ExecStart=/usr/bin/snapbackend
ExecStop=/usr/bin/snapstop --timeout 300 $MAINPID
User=snapwebsites
Group=snapwebsites
# No auto-restart, we use the timer to start once in a while
# We also want to make systemd think that exit(1) is fine
SuccessExitStatus=1
Nice=5
LimitNPROC=1000
# For developers and administrators to get console output
#StandardOutput=tty
#StandardError=tty
#TTYPath=/dev/console
# Enter a size to get a core dump in case of a crash
#LimitCORE=10G

[Install]
WantedBy=multi-user.target

# vim: syntax=dosini

1
Est-ce que la sortie de l' systemctl list-timersaide?
phg

Ah! En recherchant cela, j'ai trouvé cette page avec la solution: bbs.archlinux.org/viewtopic.php?id=214989 Je vais écrire une réponse maintenant.
Alexis Wilke

Réponses:


25

L'état des minuteries actuellement actives peut être affiché en utilisant systemctl list-timers:

$ systemctl list-timers --all
NEXT                         LEFT     LAST                         PASSED       UNIT                         ACTIVATES
Wed 2016-12-14 08:06:15 CET  21h left Tue 2016-12-13 08:06:15 CET  2h 18min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

1 timers listed.

7

À partir du commentaire et de la réponse @phg, j'ai trouvé une page avec la réponse. Les minuteries sont cumulatives et vous devez d'abord les réinitialiser, sinon l'entrée précédente reste présente. C'est utile pour les calendriers, mais cela fonctionne de la même manière avec tous les temporisateurs.

Avoir une entrée qui réinitialise la minuterie avant de la changer en une nouvelle valeur fonctionne comme prévu:

# This file was auto-generated by snapmanager.cgi
# Feel free to do additional modifications here as
# snapmanager.cgi will be aware of them as expected.
[Timer]
OnUnitActiveSec=
OnUnitActiveSec=30min

1

Non, il n'apparaît pas un moyen de voir exactement quand une minuterie s'exécutera ensuite. systemdoffres systemctl list-timerset systemctl status something.timer, mais ceux-ci ne montrent pas l'effet de AccuracySec=et éventuellement d'autres directives qui décalent le temps.

Si vous définissez AccuracySec=1hsur deux serveurs, ils signaleront tous deux que le même minuteur sur les deux serveurs se déclenchera en même temps, mais en fait, ils pourraient démarrer jusqu'à une heure d'intervalle! Si vous souhaitez savoir si deux minuteries aléatoires pourraient entrer en collision, il semble qu'il n'y ait aucun moyen de vérifier la durée d'exécution finale calculée pour le savoir.

Il y a un problème systemd ouvert pour rendre la sortie des list-timers plus précise / moins confuse.


Point intéressant sur les minuteries. Les informations que nous obtenons list-timers, cependant, sont déjà assez bonnes pour comprendre si votre utilisation des minuteries est correcte ou non.
Alexis Wilke

1
Pas dans mon cas. Je voudrais utiliser la même configuration exacte sur des hôtes jumeaux, mais utilisez AccuracySec = pour vous assurer que les deux ne font pas la maintenance en même temps. Je voudrais voir quand les minuteries se déclencheront réellement sur chaque hôte, mais je ne peux pas.
Mark Stosberg

Ah. J'ai des problèmes similaires. Je voudrais utiliser un maître sélectionné (en utilisant un système de vote) et le maître envoie un message "faire la maintenance" à l'ordinateur 1, une fois que l'ordinateur 1 est terminé, il signale son nouveau statut au maître qui demande ensuite à l'ordinateur 2 de faire sa maintenance, etc. L'un de ces ordinateurs serait bien sûr le maître, mais le code exécutant la boucle de maintenance devrait être distinct de la maintenance réelle. Un problème à garder à l'esprit. Si votre cluster est de faire croître un peu se rappeler que cela prend du temps et il pourrait être si longtemps que certains ordinateurs ne sont pas mis à jour depuis longtemps!
Alexis Wilke
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.