Czy istnieje sposób, aby dowiedzieć się, kiedy systemowy licznik czasu uruchomi się następnie?


19

Testuję systemowy licznik czasu i próbuję zastąpić jego domyślny limit czasu, ale bez powodzenia. Zastanawiam się, czy istnieje sposób, aby poprosić systemd o informację, kiedy usługa zostanie uruchomiona w następnej kolejności.

Normalny plik ( /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

Plik zastępowania ( /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

Uruchomiłem następujące polecenia, a zegar nadal tyka raz na 5 minut. Czy może być błąd w systemd?

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

Zastanawiałem się więc, skąd mam wiedzieć, kiedy stoper będzie tykał dalej? Ponieważ to natychmiast powiedziałoby mi, czy to za 5 minut. lub 30 min. ale z tego systemctl status snapbackend.timernic nie mówi. Zastanawiam się tylko, czy istnieje polecenie, które powiedziałoby mi o aktualnie używanym opóźnieniu.

Dla zainteresowanych jest też plik usługi ( /lib/systemd/system/snapbackend.service), choć wyobrażam sobie, że nie powinno to mieć wpływu na tykanie timera ...

# 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
Czy wynik systemctl list-timerspomocy?
phg

Ach! Szukając tego, znalazłem tę stronę z rozwiązaniem: bbs.archlinux.org/viewtopic.php?id=214989 Napiszę teraz odpowiedź.
Alexis Wilke,

Odpowiedzi:


25

Stan aktualnie aktywnych timerów można wyświetlić za pomocą 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

Z komentarza i odpowiedzi @phg znalazłem stronę z odpowiedzią. Liczniki są kumulowane i musisz je najpierw zresetować, w przeciwnym razie poprzedni wpis pozostanie. Jest to przydatne w przypadku kalendarzy, ale działa tak samo ze wszystkimi licznikami czasu.

Posiadanie jednego wpisu, który resetuje timer przed zmianą go na nową wartość, działa zgodnie z oczekiwaniami:

# 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

Nie, nie ma sposobu, aby dokładnie zobaczyć, kiedy licznik czasu uruchomi się w następnej kolejności. systemdoferty systemctl list-timersi systemctl status something.timer, ale te nie pokazują wpływu AccuracySec=i prawdopodobnie innych dyrektyw, które zmieniają czas.

Jeśli ustawisz AccuracySec=1hna dwóch serwerach, oba będą zgłaszać, że ten sam licznik na obu serwerach uruchomi się dokładnie w tym samym czasie, ale w rzeczywistości mogą zacząć się w odstępie godziny! Jeśli chcesz wiedzieć, czy dwa losowe zegary mogą się zderzyć, wydaje się, że nie ma sposobu, aby sprawdzić ostateczny obliczony czas działania, aby się dowiedzieć.

Istnieje otwarty problem systemowy, który sprawia, że ​​wyjście liczników list jest bardziej dokładne / mniej mylące.


Interesujący punkt na temat timerów. Informacje, które otrzymujemy list-timers, są jednak całkiem dobre, aby zrozumieć, czy użycie timerów jest prawidłowe, czy nie.
Alexis Wilke

1
Nie w moim przypadku. Chciałbym użyć dokładnie tej samej konfiguracji na bliźniaczych hostach, ale użyj AccuracySec =, aby upewnić się, że oba nie wykonują konserwacji w tym samym czasie. Chciałbym zobaczyć, kiedy liczniki czasu faktycznie uruchomią się na każdym hoście, ale nie mogą.
Mark Stosberg

Ach Mam podobne problemy. Użyłbym wybranego wzorca (za pomocą systemu głosowania), a wzorzec wysyła komunikat „wykonaj konserwację” do komputera 1, gdy komputer 1 jest gotowy, zgłasza swój nowy status kapitanowi, który następnie prosi komputer 2 o wykonanie konserwacji, itp. Jednym z tych komputerów byłby oczywiście master, ale kod uruchamiający pętlę konserwacji powinien być oddzielny od faktycznej konserwacji. Jeden problem, o którym należy pamiętać. Jeśli klaster ma się dość rozrastać, pamiętaj, że zajmuje to dużo czasu i może trwać tak długo, że niektóre komputery nie będą aktualizowane przez długi czas!
Alexis Wilke
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.