¿Hay alguna manera de saber cuándo se ejecutará un temporizador systemd a continuación?

Estoy probando un temporizador systemd e intento anular su tiempo de espera predeterminado, pero sin éxito. Me pregunto si hay una manera de pedirle a systemd que nos diga cuándo se ejecutará el servicio a continuación.

Archivo 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

El archivo de anulación ( /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

Ejecuté los siguientes comandos y el temporizador sigue marcando una vez cada 5 minutos. ¿Podría haber un error en systemd?

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

Entonces también me preguntaba, ¿cómo puedo saber cuándo el cronómetro marcará el próximo paso? Porque eso me diría de inmediato si es en 5 minutos. o 30 min. pero del systemctl status snapbackend.timerdice nada sobre eso. Solo me pregunto si hay un comando que me diga la demora actualmente utilizada.

Para aquellos interesados, también está el archivo de servicio ( /lib/systemd/system/snapbackend.service), aunque me imagino que esto no debería tener ningún efecto en los tics del temporizador ...

# 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

El estado de los temporizadores actualmente activos se puede mostrar usando 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.

De @phg comentario y respuesta, encontré una página con la respuesta. Los temporizadores son acumulativos y debe restablecerlos primero; de lo contrario, la entrada anterior permanece. Esto es útil para calendarios, pero funciona igual con todos los temporizadores.

Tener una entrada que restablece el temporizador antes de cambiarlo a un nuevo valor funciona como se esperaba:

# 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

No, no aparece una forma de ver exactamente cuándo se ejecutará un temporizador la próxima vez. systemdofertas systemctl list-timersy systemctl status something.timer, pero esas no muestran el efecto de AccuracySec=y posiblemente otras directivas que cambian el tiempo.

Si configura AccuracySec=1hen dos servidores, ambos informarán que el mismo temporizador en ambos servidores se disparará exactamente al mismo tiempo, ¡pero de hecho podrían comenzar con una hora de diferencia! Si está interesado en saber si dos temporizadores aleatorios podrían colisionar, parece que no hay forma de verificar el tiempo de ejecución calculado final para averiguarlo.

Hay un problema systemd abierto para hacer que la salida de los temporizadores de lista sea más precisa / menos confusa.