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

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

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.

À 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

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.