Existe uma maneira de saber quando um timer do systemd será executado a seguir?

Estou testando um timer do systemd e tentando substituir o tempo limite padrão, mas sem êxito. Eu estou querendo saber se existe uma maneira de pedir ao systemd para nos dizer quando o serviço será executado a seguir.

Arquivo 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

O arquivo de substituição ( /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

Executei os seguintes comandos e o timer ainda funciona uma vez a cada 5 minutos. Poderia haver um erro no systemd?

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

Então, eu também estava pensando, como posso saber quando o cronômetro irá marcar a seguir? Porque isso me diria imediatamente se é em 5 minutos. ou 30 min. mas a partir do systemctl status snapbackend.timerdiz nada sobre isso. Apenas querendo saber se existe um comando que me diga o atraso usado atualmente.

Para os interessados, também existe o arquivo de serviço ( /lib/systemd/system/snapbackend.service), embora eu imagine que isso não deva afetar os tiques do timer ...

# 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

O estado dos temporizadores atualmente ativos pode ser mostrado 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.

No comentário e resposta do @phg, encontrei uma página com a resposta. Os temporizadores são cumulativos e você precisa redefini-los primeiro, caso contrário a entrada anterior permanece por perto. Isso é útil para calendários, mas funciona da mesma forma com todos os cronômetros.

Ter uma entrada que redefina o cronômetro antes de alterá-lo para um novo valor funciona conforme o esperado:

# 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

Não, não parece haver uma maneira exata de ver quando um cronômetro será executado a seguir. systemdofertas systemctl list-timerse systemctl status something.timer, mas elas não mostram o efeito AccuracySec=e possivelmente outras diretivas que mudam o tempo.

Se você definir AccuracySec=1hem dois servidores, eles reportarão que o mesmo timer nos dois servidores será acionado exatamente ao mesmo tempo, mas, na verdade, eles podem começar com uma hora de diferença! Se você estiver interessado em saber se dois cronômetros aleatórios podem colidir, parece não haver maneira de verificar o tempo de execução final calculado para descobrir.

Há um problema de sistema aberto para tornar a saída dos timers de lista mais precisa / menos confusa.