Не срабатывает systemd таймер

И как это можно дебажить?

Логи (journalctl -b или journalctl -e) и статус юнитов (systemctl status make-backup.{timer,service}) в студию.

Type=simple

Это к делу (скорее всего) не относится, но Type=oneshot.

Разумеется на самом деле ничего не срабатывает.

При этом понятно, что на самом деле таймер не срабатывает.

Откуда «разумеется» и «понятно»? Мне отнюдь не «разумеется» и совсем не понятно.

Как уже сказал, логи в студию.

Алсо:

[Timer]
OnCalendar=--* 20:55:00

NEXT
Mon 2019-06-24 21:08:00 CEST

Не сходится.

Логи (journalctl -b или journalctl -e) и статус юнитов (systemctl status make-backup.{timer,service}) в студию.

# journalctl -a -e

[...]
Jun 24 21:28:31 sol bash[23146]: 8:19  ^M         58.34G  96%  461.96kB/s    1:09:36  ^M         58.34G  96%  439.46kB/s    1:13:09  ^M         58.34G  96%  408.20kB/s    1:1
[...]

Предельно странно, но это именно то что делал этот сервис позавчера. Но дата почему то «только что».

Это к делу (скорее всего) не относится, но Type=oneshot.

Поменял.

Откуда «разумеется» и «понятно»? Мне отнюдь не «разумеется» и совсем не понятно.

Я заменил ExecStart=/bin/ls. Точно такой же эффект.

Не сходится.

Не, это ОК, потому что я их меняю постоянно с интервалом в 2-3 минуты. Починить пытаюсь, типа.

systemctl status make-backup.{timer,service}

Сорри, забыл.

# systemctl status make-backup.{timer,service}
● make-backup.timer - VMs Backup Service (Timer)
   Loaded: loaded (/etc/systemd/system/make-backup.timer; disabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-06-24 21:31:32 CEST; 1min 37s ago

Jun 24 21:31:32 sol systemd[1]: Started VMs Backup Service (Timer).

● make-backup.service - VMs Backup Service
   Loaded: loaded (/etc/systemd/system/make-backup.service; static; vendor preset: enabled)
   Active: active (running) since Fri 2019-06-21 06:00:00 CEST; 3 days ago
 Main PID: 23146 (bash)
    Tasks: 3 (limit: 4915)
   Memory: 17.1G
      CPU: 1h 11min 20.748s
   CGroup: /system.slice/make-backup.service
           ├─23146 /bin/bash /usr/local/bin/make_backup.sh
           ├─23147 rsync --progress -avzh -e ssh -p 48000 -i /root/backup/id_rsa /mnt/pve/backup/dump/vzdump-qemu-1101-2019_06_15-04_00_01.log /mnt/pve/backup/dump/vzdump-qem
           └─23152 ssh -p 48000 -i /root/backup/id_rsa -l uploader home.xand.es rsync --server -vlogDtprze.iLsfxC . /data/

Jun 24 21:25:04 sol bash[23146]: [2.0K blob data]
Jun 24 21:25:55 sol bash[23146]: [2.0K blob data]
Jun 24 21:26:47 sol bash[23146]: [2.0K blob data]
Jun 24 21:27:37 sol bash[23146]: [2.0K blob data]
Jun 24 21:28:31 sol bash[23146]: [1.9K blob data]
Jun 24 21:29:23 sol bash[23146]: [2.0K blob data]
Jun 24 21:30:17 sol bash[23146]: [2.0K blob data]
Jun 24 21:31:08 sol bash[23146]: [2.0K blob data]
Jun 24 21:32:01 sol bash[23146]: [1.9K blob data]
Jun 24 21:32:52 sol bash[23146]: [1.9K blob data]

Сорри, забыл. По ходу он как 3 дня запустился, так до сих пор и работает. По какой то причине.

По ходу он как 3 дня запустился, так до сих пор и работает.

Ну вот тебе и ответ.

systemd не будет запускать вторую копию юнита, пока первая ещё работает. Более подробно: https://unix.stackexchange.com/q/203254/21885

Ну вот тебе и ответ.

Спасибо большое. Ты меня снова выручил в вопросах systemd.

Но вообще предельное странно что этот rsync сам по себе не отвалился. Ну или не загрузил файлы, там ничего такого нет чтобы 3 дня грузить по объему.

Но вообще предельное странно что этот rsync сам по себе не отвалился. Ну или не загрузил файлы, там ничего такого нет чтобы 3 дня грузить по объему.

Посмотри в лог по юниту: journalctl -a -b -u make-backup.service.

Спасибо большое. Ты меня снова выручил в вопросах systemd.

P. S.: systemd даёт вам просто исчерпывающий набор тулз для интроспекции и отладки — но нет, не хотим читать маны, хотим ныть на ЛОРе «как это дебажить». Штатными способами, блин.

Штатными способами, блин.

Ну вот я только только научился пользоваться journalctl более менее.

Чтобы не плодить темы напишу тут: Настроил fstrim через systemctl Но при просмотре systemctl list-timers -all NEXT LEFT LAST PASSED UNIT Mon 2019-10-21 10:30:00 EET 2s left Mon 2019-10-21 10:29:00 EET 57s ago pvesr.timer Mon 2019-10-21 11:04:49 EET 34min left Mon 2019-10-21 10:02:52 EET 27min ago anacron.timer Mon 2019-10-21 18:20:00 EET 7h left Sun 2019-10-20 18:20:00 EET 16h ago systemd-tmpfiles- Mon 2019-10-21 21:46:09 EET 11h left Mon 2019-10-21 07:41:05 EET 2h 48min ago apt-daily.timer Tue 2019-10-22 03:13:43 EET 16h left Mon 2019-10-21 03:02:52 EET 7h ago pve-daily-update. Tue 2019-10-22 06:14:06 EET 19h left Mon 2019-10-21 06:48:52 EET 3h 41min ago apt-daily-upgrade n/a n/a n/a n/a fstrim.timer

Видно что у fstrim.timer все отметки n/a Я не понимаю работает задание или нет. Так выглядит fstrim.service [Unit] Description=Discard unused blocks

[Service] Type=oneshot ExecStart=/sbin/fstrim -av

Так выглядит fstrim.timer [Unit] Description=Discard unused blocks once a day Documentation=man:fstrim

[Timer] OnCalendar=daily AccuracySec=1h Persistent=true

[Install] WantedBy=timers.target

При просмотре команды journalctl -a -b -u fstrim.timer -- No entries -- Пишет, что нет данных для отображения.

root@proxmox0:~# systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a day Loaded: loaded (/etc/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:fstrim

Что не так? Как диагностировать причину сбоя?

Чтобы не плодить темы

Плодить темы ­— это не что-то плохое. Некропостинг и флуд в других темах гораздо хуже. Если ты считаешь, что твой вопрос недостоин отдельной темы, то его вообще не следует задавать.

Заодно советую выучить Markdown или LORCODE. Кашу из текста читать никто не будет.

регистрант-писатель — не читатель?