# Mein erster systemd timer

## schmidicom

Vor kurzem habe ich mir mal einen eigenen systemd Timer zusammen gebastelt, doch leider scheint der nicht ganz so zu funktionieren wie ich geplant. Der Timer wird nach der Aktivierung immer nur einmal ausgelöst und hangt danach einfach fest. Leider konnte ich im Internet dazu nicht wirklich etwas finden aber möglicherweise hat ja einer von euch eine Idee woran es liegen könnte.

Zu den Details:

Mein Timer "fab-backup.timer" sollte von Montag bis und mit Freitag jeweils um 23:00 ausgelöst werden und das selbst erstellte Target "fab-backup.target" (in dem 3 Service Units installiert sind) aktivieren. Doch das ganze läuft nur einmal durch und danach hängt sich mein Timer einfach auf, und das sieht dann so aus:

```
# systemctl list-timers

NEXT                        LEFT         LAST                        PASSED  UNIT                         ACTIVATES

Di 2014-11-25 23:00:00 CET  9h ago       Di 2014-11-25 23:00:05 CET  9h ago  fab-backup.timer             fab-backup.target

Mi 2014-11-26 09:22:55 CET  1h 7min left Di 2014-11-25 09:22:55 CET  22h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

2 timers listed.

Pass --all to see loaded but inactive timers, too.
```

Erst wenn ich meinen Timer mit "systemctl restart fab-backup.timer" wieder neu starte ändert sich die Ausgabe

```
# systemctl list-timers

NEXT                        LEFT         LAST                        PASSED  UNIT                         ACTIVATES

Mi 2014-11-26 09:22:55 CET  1h 5min left Di 2014-11-25 09:22:55 CET  22h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

Mi 2014-11-26 23:00:00 CET  14h left     n/a                         n/a     fab-backup.timer             fab-backup.target

2 timers listed.

Pass --all to see loaded but inactive timers, too.
```

Hier noch die Dateien die ich gemäß verschiedener Anleitungen aus dem Internet erstellt habe:

```
# cat /etc/systemd/system/fab-backup.timer

[Unit]

Description=Fabrikatur Backup-Scripts

[Timer]

OnCalendar=Mon-Fri *-*-* 23:00:00

Unit=fab-backup.target                                                                                                                       

                                                                                                                                             

[Install]                                                                                                                                    

WantedBy=multi-user.target
```

```
# cat /etc/systemd/system/fab-backup.target                                                                                      

[Unit]                                                                                                                                       

Description=Backups für Fabrikatur
```

```
# ls -l /etc/systemd/system/fab-backup.target.wants/

insgesamt 0

lrwxrwxrwx 1 root root 38 20. Nov 12:57 backup_pps.service -> /etc/systemd/system/backup_pps.service

lrwxrwxrwx 1 root root 46 20. Nov 12:56 backup_schreinerei.service -> /etc/systemd/system/backup_schreinerei.service

lrwxrwxrwx 1 root root 36 20. Nov 12:57 belegung.service -> /etc/systemd/system/belegung.service
```

----------

## mv

Die Details von Timern habe ich mir niie angeschaut, aber warum benutzt Du nicht einfach systemd-cron (z.B. aus dem mv overlay)?

----------

## schmidicom

Weil ich keinen Sinn darin sehe einen cron oder pseudo cron zu betrieben wenn die gewünschte Funktionalität bereits an anderer Stelle vorhanden ist. Außerdem möchte ich mich, in Anbetracht der zunehmenden Verbreitung, mit möglichst vielen Aspekten von systemd richtig auskennen. Daher ist es für mich wichtig zu erkennen warum mein timer sich nicht so verhält wie geplant, fällt auch unter die Kategorie "neues dazu lernen".

----------

## mv

systemd-cron benutzt - wie der Name erahnen lässt - systemd timer units; er erstellt Dir Units, die funktionieren sollten.

Dazu gehören auch units zu Zurücksetzen von timern. Wie gesagt, genau habe ich mir das nie angeschaut.

----------

## schmidicom

Selbst wenn systemd-cron funktioniert weiß ich dann aber immer noch nicht warum mein Timer es nicht tut. Ich will letztlich in der Lage sein eigene systemd Timer zu schreiben die dann auch funktionieren.

----------

## mv

Bei systemd-cron stehen Dinge wie "StopWhenUnneeded=Yes" und "Type=oneshot". Irgendeines (oder beides) davon könnten dafür verantwortlich sein.

----------

## schmidicom

Also ein "StopWhenUnneeded=Yes" in den Service-Units reicht wohl nicht aus, mal sehen ob das ganze heute Abend sauber durchläuft wenn auch der Typ auf oneshot umgestellt ist.

----------

## musv

Hmm, woran erkennst du, dass es nur 1x ausgeführt wurde?

Bei mir steht da: 

```
NEXT                        LEFT     LAST                        PASSED       UNIT                         ACTIVATES

Mo 2014-12-01 00:00:00 CET  11h left So 2014-11-30 10:33:39 CET  1h 29min ago timer-weekly.timer           timer-weekly.target

Mo 2014-12-01 10:33:39 CET  22h left So 2014-11-30 10:33:39 CET  1h 29min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
```

Die Kette des wöchentlichen Cronjobs:

```
[Unit]

Description=Weekly Timer

[Timer]

OnBootSec=15min

OnCalendar=weekly

Persistent=true

Unit=timer-weekly.target

[Install]

WantedBy=basic.target
```

```
[Unit]

Description=Weekly Timer Target

StopWhenUnneeded=yes
```

```
[Unit]

Description=Starts program bar

Wants=timer-daily.timer

[Service]

User=                                          # Add a user if you wish the service to be executes as a particular user, else delete this line

Type=                                          # Simple by default, change it if you know what you are doing, else delete this line

Nice=19

IOSchedulingClass=2

IOSchedulingPriority=7

ExecStart=/usr/bin/bar --option1 --option2     # More than one ExecStart can be used if required

[Install]

WantedBy=timer-weekly.target
```

```
lrwxrwxrwx 1 root root   43 30. Mai 2014  eix_update_cron.service -> /etc/systemd/system/eix_update_cron.service

lrwxrwxrwx 1 root root   42 30. Mai 2014  logrotate_cron.service -> /etc/systemd/system/logrotate_cron.service

lrwxrwxrwx 1 root root   43 30. Mai 2014  makewhatis_cron.service -> /etc/systemd/system/makewhatis_cron.service

lrwxrwxrwx 1 root root   40 30. Mai 2014  mlocate_cron.service -> /etc/systemd/system/mlocate_cron.service

lrwxrwxrwx 1 root root   40 30. Mai 2014  prelink_cron.service -> /etc/systemd/system/prelink_cron.service
```

Und natürlich muss das Zeug noch aktiviert werden:

```
systemctl enable foo_cron.service

systemctl enable timer-weekly.timer
```

Update:

Funktioniert bei mir scheinbar auch nicht richtig. 

```
-- Reboot --

Nov 26 19:53:39 hexe systemd[1]: Starting Starts prelink Cron.Service...

Nov 26 19:53:39 hexe systemd[1]: Started Starts prelink Cron.Service.

-- Reboot --

Nov 27 10:55:33 hexe systemd[1]: Starting Starts prelink Cron.Service...

Nov 27 10:55:33 hexe systemd[1]: Started Starts prelink Cron.Service.

-- Reboot --

Nov 27 13:41:58 hexe systemd[1]: Starting Starts prelink Cron.Service...

Nov 27 13:41:58 hexe systemd[1]: Started Starts prelink Cron.Service.

-- Reboot --

Nov 28 20:59:14 hexe systemd[1]: Starting Starts prelink Cron.Service...

Nov 28 20:59:14 hexe systemd[1]: Started Starts prelink Cron.Service.

-- Reboot --

Nov 29 12:37:29 hexe systemd[1]: Starting Starts prelink Cron.Service...

Nov 29 12:37:29 hexe systemd[1]: Started Starts prelink Cron.Service.

-- Reboot --

Nov 30 10:33:39 hexe systemd[1]: Starting Starts prelink Cron.Service...

Nov 30 10:33:39 hexe systemd[1]: Started Starts prelink Cron.Service.
```

Obwohl der Cronjob wöchentlich ausgeführt werden soll, wird das Ding täglich abgearbeitet.

----------

## schmidicom

Erstmal danke für die umfassende Antwort.

Das mein Timer hängt sieht man daran das in der Ausgabe von "systemctl list-timers" unter LEFT ein negativer Wert angezeigt wird (also *h ago anstelle left) und das obwohl das Target mit seinen drei service-Units sauber durchgelaufen ist.

EDIT:

Gemäß Manpage arbeitet die Option "StopWhenUnneeded=" mit den Werten true/false und nicht mit Yes/No.

EDIT:

Inzwischen bin ich mir sicher es liegt am Target und nicht am Timer, denn das Target bleibt auf aktiv hängen. Sobald ich das Target manuell anhalte zeigt "systemctl list-timers" keinen Negativwert mehr an.

EDIT:

Ich habe nun meine drei Scripte zu einem Superscript zusammengefasst, ein service-Unit und einen Timer dazu erstellt. Mal sehen ob das ganze ohne Target besser hinhaut, wenn ja dürfte ziemlich klar sein wo es hängt.

EDIT:

Ohne ein Target-Unit funktioniert mein Timer einwandfrei:

```
# systemctl list-timers

NEXT                        LEFT     LAST                        PASSED  UNIT                         ACTIVATES

Di 2014-12-02 14:34:32 CET  7h left  Mo 2014-12-01 14:34:32 CET  16h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

Di 2014-12-02 23:00:00 CET  15h left Mo 2014-12-01 23:00:18 CET  8h ago  fab-backup-all.timer         backup_all.service

2 timers listed.

Pass --all to see loaded but inactive timers, too.
```

Stellt sich die Frage ob man sowas als Bug melden sollte oder nicht...

----------

