[SOLVED] systemd timer failing after first run?

7thSon · 2017-10-30 17:20:59

I've set a systemd timer to trigger a borg system backup every day at 04:00. This worked for the first night and I checked systemctl list-timers and everything was fine.
However, the next day the backup didn't run and when I checked list-timers again the column stating time "LEFT" until next run read "n/a".

The timer (timer-borgArch.timer) in /etc/systemd/system is set up like this:

[Unit]
Description=Run borg backup daily for Arch Linux.

[Timer]
Unit=timer-borgArch.target
OnCalendar=*-*-* 04:00:00
Persistent=True

The target file it points to contains nothing but this:

[Unit]
Description=timer-borgArch

I have two service units that should be triggered by the timer/target, one to backup to my local disk, and one to backup to my server.
borgArchLocal.service:

[Unit]
Description=Run borg backup for Arch Linux system to NAS.
After=borgArchNAS.service

[Service]
User=root
ExecStart=/home/user/.scripts/borg/borgArchLocal.sh

[Install]
WantedBy=timer-borgArch.target

borgArchNAS.service:

[Unit]
Description=Run borg backup for Arch Linux system to NAS.
Before=borgArchLocal.service

[Service]
User=root
ExecStart=/home/user/.scripts/borg/borgArchNAS.sh

[Install]
WantedBy=timer-borgArch.target

If I do "systemctl restart timer-borgArch.timer" and "systemctl daemon-reload" the timer resets and again displays the correct time "LEFT" in the column of list-timers.
What could be the reason as to why the timer breaks, and what could I do to fix it?

Last edited by 7thSon (2017-12-03 11:47:08)

cfr · 2017-10-31 02:43:23

Don't you need a

WantedBy=timers.target

somewhere?

circleface · 2017-10-31 02:53:54

Are you sure you enabled it as well as started it?

7thSon · 2017-10-31 07:33:24

cfr wrote:

Don't you need a
WantedBy=timers.target
somewhere?

So the timer also needs this WantedBy=timers.target? Why should that target be "timers.target" by the way, and not timer-borgArch.target which is my custom target?
The target units are really confusing me, because it seems like all the guides I found on systemd scheduling talk about service and timer units, but completely gloss over targets and how they work

Could you please elaborate your answer, if I read you correctly I need to add a target to the timer-borgArch.timer unit I have?
I did this and it does load, enable and start without errors now, so hopefully the timer will be persistent this time.

circleface wrote:

Are you sure you enabled it as well as started it?

Yes, I double checked this before.

cfr · 2017-10-31 23:51:46

7thSon wrote:

So the timer also needs this WantedBy=timers.target? Why should that target be "timers.target" by the way, and not timer-borgArch.target which is my custom target?
The target units are really confusing me, because it seems like all the guides I found on systemd scheduling talk about service and timer units, but completely gloss over targets and how they work
Could you please elaborate your answer, if I read you correctly I need to add a target to the timer-borgArch.timer unit I have?

To be honest, I am not certain. It was just a guess based on looking at the timers available on my system and reading the manual pages. The timers.target is a 'special' target which manages timers, so I wondered if you needed this in order to get systemd to actually treat your timers properly.

However, not all the timers available on my system use this target. But the ones that don't seem to measure durations from activation time, rather than using calendar settings. Moreover, the others are also tied to some special target, albeit it multi-user.target rather than timers.target, though I know not why.

As I say, it was just a guess. It could very easily be wrong. (But not the kind of guess which might do any harm - I thought it might or might not work and it seemed at worst harmless.)

I did this and it does load, enable and start without errors now, so hopefully the timer will be persistent this time.

You didn't mention any errors before. What errors were you getting?

Last edited by cfr (2017-10-31 23:53:13)

7thSon · 2017-11-01 07:21:50

cfr wrote:

7thSon wrote:
I did this and it does load, enable and start without errors now, so hopefully the timer will be persistent this time.
You didn't mention any errors before. What errors were you getting?

I didn't notice this until after your earlier reply, but systemctl gave a warning about there not being a WantedBy statement in the timer as you pointed out. After adding it the warning isn't there anymore, but I'm still getting the same behavior, the borgArch timer resets to n/a after the first run, as well as some timers I set up as hourly, daily, weekly and monthly triggers, all of them n/a as well.

cfr · 2017-11-02 01:31:15

Maybe https://bbs.archlinux.org/viewtopic.php?id=231408 helps?

7thSon · 2017-11-04 10:03:04

cfr wrote:

Maybe https://bbs.archlinux.org/viewtopic.php?id=231408 helps?

Hmm, I don't think so, I'm already using OnCalendar and it still says n/a.
Funny though, I checked my borg backups today and the timer seems to be triggering still, since I have the backups from the past few days.
Why then does it still say "n/a" in the systemctl list-timers? It doesn't feel very reliable in the state it is right now.

Last edited by 7thSon (2017-11-04 10:03:23)

RoundCube · 2017-11-04 14:28:57

Just another guess, maybe a systemctl daemon-reload needs to be done to invoke the changes.

7thSon · 2017-11-04 15:20:43

RoundCube wrote:

Just another guess, maybe a systemctl daemon-reload needs to be done to invoke the changes.

No, thats not it, I've reloaded the daemon several times, as well as restarted the timers. Then they show the correct time left etc, but once that first trigger time passes they revert to showing "n/a".

cfr · 2017-11-04 16:28:35

7thSon wrote:

Funny though, I checked my borg backups today and the timer seems to be triggering still, since I have the backups from the past few days.
Why then does it still say "n/a" in the systemctl list-timers? It doesn't feel very reliable in the state it is right now.

So they now work with your original set-up? They just say they don't? Or they now work with a modified set-up, but say they don't?

glyons · 2017-11-04 17:04:06

Anything in the journalctrl ?

$journalctl | grep borgArch

What happens if you just run one service at a time?

also ... maybe?

the wiki says
Persistent=true
you have
Persistent=True

Last edited by glyons (2017-11-04 20:08:15)

7thSon · 2017-11-05 15:53:37

cfr wrote:

7thSon wrote:
Funny though, I checked my borg backups today and the timer seems to be triggering still, since I have the backups from the past few days.
Why then does it still say "n/a" in the systemctl list-timers? It doesn't feel very reliable in the state it is right now.
So they now work with your original set-up? They just say they don't? Or they now work with a modified set-up, but say they don't?

It seems like they worked with my original set-up but stating "n/a" in the time left column. I reloaded the systemctl daemon and restarted all the timers yesterday after setting "True" to "true", but last night the backups didn't run. I reloaded the daemon and restarted the timers again, and looks like the backups ran immediately as I did that, so now they backed up today at 12.44. But none of the timers should state n/a in the time left column, if they in a normal state?

glyons wrote:

Anything in the journalctrl ?
$journalctl | grep borgArch
What happens if you just run one service at a time?
also ... maybe?
the wiki says
Persistent=true
you have
Persistent=True

The journal has a ton of lines that are from the borg backups that were actually run.
There are some warnings though, that state "Nov 05 12:45:34 arch systemd[1]: /etc/systemd/system/borgArchNAS.service:8: Unknown lvalue 'Wants' in section 'Service'"
Don't I need the "Wants" option in the service?

I also tried changing "True" to "true", but the hourly timer triggered, and its back to n/a again.

How do you mean "run one service at a time?", aren't the timers separate from the services, i.e. the timers don't depend on the services they trigger?

Last edited by 7thSon (2017-11-05 15:58:39)

cfr · 2017-11-05 23:32:14

7thSon wrote:

The journal has a ton of lines that are from the borg backups that were actually run.
There are some warnings though, that state "Nov 05 12:45:34 arch systemd[1]: /etc/systemd/system/borgArchNAS.service:8: Unknown lvalue 'Wants' in section 'Service'"
Don't I need the "Wants" option in the service?

Please post the actual files you are using. There is no 'Wants' in the code you posted originally and I don't see that you've posted updated versions since.

You certainly don't need 'Wants' in the .service. See the examples in the manual page. Possibly you cannot have 'Wants' here - I'm not sure and you don't say where or how you're trying to use it.

7thSon · 2017-11-07 16:46:59

cfr wrote:

7thSon wrote:
The journal has a ton of lines that are from the borg backups that were actually run.
There are some warnings though, that state "Nov 05 12:45:34 arch systemd[1]: /etc/systemd/system/borgArchNAS.service:8: Unknown lvalue 'Wants' in section 'Service'"
Don't I need the "Wants" option in the service?
Please post the actual files you are using. There is no 'Wants' in the code you posted originally and I don't see that you've posted updated versions since.
You certainly don't need 'Wants' in the .service. See the examples in the manual page. Possibly you cannot have 'Wants' here - I'm not sure and you don't say where or how you're trying to use it.

Below are the file contents as they are now, I removed the "Wants" option from the .service units since it wasn't supposed to be there.
What is really curious now is that when I ran "systemctl list-timers" before posting this, the only timer showing "n/a" is the hourly one.
I haven't done any changes since yesterday when I removed the Wanted option, and yesterday all of them were "n/a".
It seems to me more and more like the table shown by systemctl list-timers isn't fully reliable?
In any case, if someone has a keen eye, it would be great to see if you can spot any mistakes in my files, really appreciate all the help so far.

NEXT                         LEFT                LAST                         PASSED        UNIT                         ACTIVATES
Wed 2017-11-08 00:00:00 CET  6h left             Tue 2017-11-07 00:00:11 CET  17h ago       logrotate.timer              logrotate.service
Wed 2017-11-08 00:00:00 CET  6h left             Tue 2017-11-07 00:00:11 CET  17h ago       man-db.timer                 man-db.service
Wed 2017-11-08 00:00:00 CET  6h left             Tue 2017-11-07 00:00:11 CET  17h ago       shadow.timer                 shadow.service
Wed 2017-11-08 00:00:00 CET  6h left             Tue 2017-11-07 15:07:05 CET  2h 28min ago  timer-daily.timer            timer-daily.target
Wed 2017-11-08 03:00:00 CET  9h left             Tue 2017-11-07 15:07:05 CET  2h 28min ago  timer-borgArch.timer         timer-borgArch.target
Wed 2017-11-08 15:24:29 CET  21h left            Tue 2017-11-07 15:24:29 CET  2h 11min ago  systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2017-11-13 00:00:00 CET  5 days left         Mon 2017-11-06 00:00:11 CET  1 day 17h ago timer-weekly.timer           timer-weekly.target
Fri 2017-12-01 00:00:00 CET  3 weeks 2 days left Wed 2017-11-01 00:00:06 CET  6 days ago    pamac-cleancache.timer       pamac-cleancache.service
Fri 2017-12-01 00:00:00 CET  3 weeks 2 days left Wed 2017-11-01 00:00:06 CET  6 days ago    timer-monthly.timer          timer-monthly.target
n/a                          n/a                 Tue 2017-11-07 16:00:00 CET  1h 35min ago  timer-hourly.timer           timer-hourly.target

timer-borgArch.timer

[Unit]
Description=Run borg backup daily for Arch Linux.

[Timer]
Unit=timer-borgArch.target
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

borgArchLocal.service

[Unit]
Description=Run borg backup for Arch Linux system to NAS.

[Service]
User=root
ExecStart=/home/user/.scripts/borg/borgArchLocal.sh

[Install]
WantedBy=timer-borgArch.target

borgArchNAS.service

[Unit]
Description=Run borg backup for Arch Linux system to NAS.

[Service]
User=root
ExecStart=/home/user/.scripts/borg/borgArchNAS.sh

[Install]
WantedBy=timer-borgArch.target

timer-borgArch.target

[Unit]
Description=timer-borgArch

timer-hourly.timer

[Unit]
Description=Hourly Timer

[Timer]
Unit=timer-hourly.target
OnCalendar=*-*-* *:00:00
Persistent=true

[Install]
WantedBy=timers.target

timer-hourly.target

[Unit]
Description=Hourly Timer Target

timer-daily.timer

[Unit]
Description=Daily Timer

[Timer]
Unit=timer-daily.target
OnCalendar=*-*-* 00:00:00
Persistent=true

[Install]
WantedBy=timers.target

timer-daily.target

[Unit]
Description=Daily Timer Target

timer-weekly.timer

[Unit]
Description=Weekly Timer

[Timer]
Unit=timer-weekly.target
OnCalendar=Mon *-*-* 00:00:00
Persistent=true

[Install]
WantedBy=timers.target

timer-weekly.target

[Unit]
Description=Weekly Timer Target

timer-monthly.timer

[Unit]
Description=Monthly Timer

[Timer]
Unit=timer-monthly.target
OnCalendar=*-*-01 00:00:00
Persistent=true

[Install]
WantedBy=timers.target

timer-monthly.target

[Unit]
Description=Monthly Timer Target

7thSon · 2017-11-14 16:41:41

So it seems that the timers keep triggering, but I noticed now that my borgArch backup times are a bit strange.
The time set in the timer-borgArch.timer is 03:00:00 every day, but my list of backups reads like this:

arch.2017-10-28                      Sat, 2017-10-28 09:32:44 [ca59f11f26e784e9814615584840dd5a2a5e56800f67277ce76f20d7459c864f]
arch.2017-10-29                      Sun, 2017-10-29 04:00:14 [7f3636b8230389709321db32f3791804cf0fab73e9ca9ab2408a85489ee29b4e]
arch.2017-10-30                      Mon, 2017-10-30 18:17:56 [7d9eb75864b6edd45848ac26880d7f2352d5834cd50b729d0785922db7b1b13e]
arch.2017-10-31                      Tue, 2017-10-31 04:00:15 [2984df4bb66a927d6ee8b821977a557f0a4ea166469d7ca5735d1ad0aa8e7057]
arch.2017-11-01                      Wed, 2017-11-01 08:17:42 [42d05eaa2930b6011932feea0b79a861cf7d0c598a804d1986415ce6678a6f75]
arch.2017-11-02                      Thu, 2017-11-02 04:00:04 [ff96a9756394802d1e7b04a6a359119be0f926d73329565baa6dee0557b089c4]
arch.2017-11-03                      Fri, 2017-11-03 04:00:02 [ead93817c8a86f6f8e3ef3ce538c926ee64c017f4b533234f4f57dcbbb8f8fee]
arch.2017-11-04                      Sat, 2017-11-04 04:00:07 [a65c4d53db9b96aa40ffd4ed68cb1dca04dfc011fc6bde0f0e98e21647416246]
arch.2017-11-05                      Sun, 2017-11-05 12:44:03 [75b68fb1447d50a3f15d177fd52414799eb3f9d856cab066cae624b2b24779e8]
arch.2017-11-06                      Mon, 2017-11-06 03:00:12 [4aa0d9bdba9189b05a529382e8babf821dc7baeae46e8393b7ecc0264ffd6319]
arch.2017-11-08                      Wed, 2017-11-08 03:00:07 [ed5e61f286e351d79d8ff041dd3e005a7d739fbe5a74bf300d0a9fd5e6aedf4c]
arch.2017-11-09                      Thu, 2017-11-09 21:44:46 [1c20b117bce2eb920440e5dc874bd3b045dd4ade8895ce7a136ccb28f931a9c2]
arch.2017-11-10                      Fri, 2017-11-10 03:00:07 [b4bcccedd90d6c8372b4897a5d9f2b24eb943f0aa076bfeb153cf8ec69776ab2]
arch.2017-11-11                      Sat, 2017-11-11 17:21:33 [c7c104e3479b556fa546b5becea5a61fbec8355894085e04c409a0a769da8acc]
arch.2017-11-12                      Sun, 2017-11-12 03:00:04 [1e19e7ef0758b4ed7480dafda487cf8ae887e317dbc053fa76a386135f60ada9]
arch.2017-11-13                      Mon, 2017-11-13 20:12:41 [201156c9f8e5f70a84a7e5d72ecd8b5b34a971e1a73b4a69b155fe8b67a5fca4]
arch.2017-11-14                      Tue, 2017-11-14 16:51:20 [8dc30bed8657ea38d31f631c32b675fa41d28aae79b4c45783d8cc66999748e6]

Notice the timestamps. I'm not sure if this has something to do with the timers or borg itself, but why there are so many backups done in the evenings is really puzzling.

7thSon · 2017-11-23 10:00:59

I'm still having issues with this, I checked my backups again today, and the script hasn't run since the 19th of November.
For some reason the timers I've created have stopped... and I have no idea why. I haven't changed them from the contents I posted above.

[user@arch ~]$ borg list /mnt/ntfs3/Backups/ArchLinux/
arch.2017-10-28                      Sat, 2017-10-28 09:32:44 [ca59f11f26e784e9814615584840dd5a2a5e56800f67277ce76f20d7459c864f]
arch.2017-10-29                      Sun, 2017-10-29 04:00:14 [7f3636b8230389709321db32f3791804cf0fab73e9ca9ab2408a85489ee29b4e]
arch.2017-10-30                      Mon, 2017-10-30 18:17:56 [7d9eb75864b6edd45848ac26880d7f2352d5834cd50b729d0785922db7b1b13e]
arch.2017-10-31                      Tue, 2017-10-31 04:00:15 [2984df4bb66a927d6ee8b821977a557f0a4ea166469d7ca5735d1ad0aa8e7057]
arch.2017-11-01                      Wed, 2017-11-01 08:17:42 [42d05eaa2930b6011932feea0b79a861cf7d0c598a804d1986415ce6678a6f75]
arch.2017-11-02                      Thu, 2017-11-02 04:00:04 [ff96a9756394802d1e7b04a6a359119be0f926d73329565baa6dee0557b089c4]
arch.2017-11-03                      Fri, 2017-11-03 04:00:02 [ead93817c8a86f6f8e3ef3ce538c926ee64c017f4b533234f4f57dcbbb8f8fee]
arch.2017-11-04                      Sat, 2017-11-04 04:00:07 [a65c4d53db9b96aa40ffd4ed68cb1dca04dfc011fc6bde0f0e98e21647416246]
arch.2017-11-05                      Sun, 2017-11-05 12:44:03 [75b68fb1447d50a3f15d177fd52414799eb3f9d856cab066cae624b2b24779e8]
arch.2017-11-06                      Mon, 2017-11-06 03:00:12 [4aa0d9bdba9189b05a529382e8babf821dc7baeae46e8393b7ecc0264ffd6319]
arch.2017-11-08                      Wed, 2017-11-08 03:00:07 [ed5e61f286e351d79d8ff041dd3e005a7d739fbe5a74bf300d0a9fd5e6aedf4c]
arch.2017-11-09                      Thu, 2017-11-09 21:44:46 [1c20b117bce2eb920440e5dc874bd3b045dd4ade8895ce7a136ccb28f931a9c2]
arch.2017-11-10                      Fri, 2017-11-10 03:00:07 [b4bcccedd90d6c8372b4897a5d9f2b24eb943f0aa076bfeb153cf8ec69776ab2]
arch.2017-11-11                      Sat, 2017-11-11 17:21:33 [c7c104e3479b556fa546b5becea5a61fbec8355894085e04c409a0a769da8acc]
arch.2017-11-12                      Sun, 2017-11-12 03:00:04 [1e19e7ef0758b4ed7480dafda487cf8ae887e317dbc053fa76a386135f60ada9]
arch.2017-11-13                      Mon, 2017-11-13 20:12:41 [201156c9f8e5f70a84a7e5d72ecd8b5b34a971e1a73b4a69b155fe8b67a5fca4]
arch.2017-11-14                      Tue, 2017-11-14 16:51:20 [8dc30bed8657ea38d31f631c32b675fa41d28aae79b4c45783d8cc66999748e6]
arch.2017-11-15                      Wed, 2017-11-15 03:00:02 [59b5900d686dcad70604b2aff451abfb6e24532b46688c60218a96062082b1fa]
arch.2017-11-16                      Thu, 2017-11-16 03:00:06 [c88835972ced31f233f4158e6eae8a306df5e1b2ac1a39fb0a7ed6a115ff0d8a]
arch.2017-11-17                      Fri, 2017-11-17 22:06:29 [c766b3ec828ccab649cdf24a7625e5b95842c1b469ff86212619d4febc6b458a]
arch.2017-11-19                      Sun, 2017-11-19 00:33:11 [f44cffbf31ba52de0fff5489e0c78a4f2cdc982ecd8eca8c2a8146cf78e35fe5]

[user@arch ~]$ systemctl list-timers
NEXT                         LEFT                LAST                         PASSED             UNIT                         ACTIVATES
Fri 2017-11-24 00:00:00 CET  13h left            Thu 2017-11-23 00:00:11 CET  10h ago            logrotate.timer              logrotate.service
Fri 2017-11-24 00:00:00 CET  13h left            Thu 2017-11-23 00:00:11 CET  10h ago            man-db.timer                 man-db.service
Fri 2017-11-24 00:00:00 CET  13h left            Thu 2017-11-23 00:00:11 CET  10h ago            shadow.timer                 shadow.service
Fri 2017-11-24 00:48:30 CET  13h left            Thu 2017-11-23 00:48:30 CET  10h ago            systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2017-12-01 00:00:00 CET  1 weeks 0 days left Wed 2017-11-01 00:00:06 CET  3 weeks 1 days ago pamac-cleancache.timer       pamac-cleancache.service
Fri 2017-12-01 00:00:00 CET  1 weeks 0 days left Wed 2017-11-01 00:00:06 CET  3 weeks 1 days ago timer-monthly.timer          timer-monthly.target
n/a                          n/a                 Sun 2017-11-19 00:33:11 CET  4 days ago         timer-borgArch.timer         timer-borgArch.target
n/a                          n/a                 Sun 2017-11-19 00:33:11 CET  4 days ago         timer-daily.timer            timer-daily.target
n/a                          n/a                 Sun 2017-11-19 00:33:11 CET  4 days ago         timer-hourly.timer           timer-hourly.target
n/a                          n/a                 Mon 2017-11-20 00:00:09 CET  3 days ago         timer-weekly.timer           timer-weekly.target

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

Any ideas? I'm stumped.

berbae · 2017-11-23 16:00:12

Hello.
Not everything is clear with your backups/timers procedure.

If you want to run backups once a day, why do you use the 'timer-hourly.timer' 'timer-weekly.timer' 'timer-monthly.timer' units?
You associated them to target units, but you didn't say what services are linked to these targets. This is rather unclear.

As shown in the code you provided, the timer-borgArch.timer unit will launch two borg backups simultaneously through the timer-borgArch.target unit, one locally and the other to a NAS server (because the default type of the services is 'simple' which doesn't wait for the script to finish).

Is this good?

And is the machine in 'suspend' mode when the timer should trigger? In this case you could look to the 'WakeSystem=' option of the timers.
Is the machine always on?

Finally do you get the same borg list of backups on the server as you get locally?
The times in the list you provided are somewhat curious.
How much time does the backups take to complete?

7thSon · 2017-11-26 21:43:46

berbae wrote:

Hello.
Not everything is clear with your backups/timers procedure.
If you want to run backups once a day, why do you use the 'timer-hourly.timer' 'timer-weekly.timer' 'timer-monthly.timer' units?
You associated them to target units, but you didn't say what services are linked to these targets. This is rather unclear.
As shown in the code you provided, the timer-borgArch.timer unit will launch two borg backups simultaneously through the timer-borgArch.target unit, one locally and the other to a NAS server (because the default type of the services is 'simple' which doesn't wait for the script to finish).
Is this good?
And is the machine in 'suspend' mode when the timer should trigger? In this case you could look to the 'WakeSystem=' option of the timers.
Is the machine always on?
Finally do you get the same borg list of backups on the server as you get locally?
The times in the list you provided are somewhat curious.
How much time does the backups take to complete?

The hourly, weekly and monthly timers are not associated with any services at all, I just created them for future use.
It might be a good idea to change the service type from 'simple' to something else now that you mention it, I will have to look into it.

I'm actually a bit uncertain if my system actually goes into a suspend state when I leave it for a while, I don't remember setting that up in any particular way, so I guess it's set to whatever Arch might have as default.
I checked XFCE power manager, the GUI says that my system is never set to go into suspended state, so maybe not? I might as well try setting the WakeSystem to try it out anyway.
The computer that is supposed to run these services and timers is always on, yes.

Yes, the list of backups that have been created is the same on my local machine as on the NAS.
I agree on the timestamps, they make no sense, I have no idea why it seems that the timers run on random times.
Also I just tested doing a backup, it took about 4 minutes.

cfr · 2017-11-27 00:43:07

7thSon wrote:

The hourly, weekly and monthly timers are not associated with any services at all, I just created them for future use.

Maybe it would be good to focus on one timer and figure that out first? It might simplify trying to disentangle things and save duplication of dead-end explorations.

I'm actually a bit uncertain if my system actually goes into a suspend state when I leave it for a while, I don't remember setting that up in any particular way, so I guess it's set to whatever Arch might have as default.

Arch does not do things like this by default. Why don't you just read the journal to see if the system suspends?

The computer that is supposed to run these services and timers is always on, yes.

Is the clock right?

I don't understand what your custom .target is supposed to do and why you aren't using a standard target. How does this target get activated? Why are your timers activating targets rather than services?

I don't really see why the files you posted got the scripts to run at all ....

Last edited by cfr (2017-11-27 00:54:35)

berbae · 2017-11-27 15:32:12

I made some tests with a timer triggering a target unit instead of a service unit.
My conclusion is that a target unit is not usable with a timer.
Because once the target is reached, after it has been started by the timer, it stays in 'Active' state, ie it doesn't stop.
And I found that the timer doesn't work any longer after that.
Apparently the unit started by the timer must not stay in 'Active' state to be started again by the timer.
So I propose this solution instead of what you tried:
For 'timer-borgArch.timer'

[Unit]
Description=Run borg backup daily for Arch Linux.

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
AccuracySec=1s

[Install]
WantedBy=timers.target

And for 'timer-borgArch.service'

[Unit]
Description=Run borg backup for Arch Linux system to local then to NAS.

[Service]
Type=oneshot
User=root
ExecStart=/home/user/.scripts/borg/borgArchLocal.sh
ExecStart=/home/user/.scripts/borg/borgArchNAS.sh

This should work as expected. I made tests here and this is good.

7thSon · 2017-11-27 22:05:53

cfr wrote:

7thSon wrote:
The hourly, weekly and monthly timers are not associated with any services at all, I just created them for future use.
Maybe it would be good to focus on one timer and figure that out first? It might simplify trying to disentangle things and save duplication of dead-end explorations.
I'm actually a bit uncertain if my system actually goes into a suspend state when I leave it for a while, I don't remember setting that up in any particular way, so I guess it's set to whatever Arch might have as default.
Arch does not do things like this by default. Why don't you just read the journal to see if the system suspends?
The computer that is supposed to run these services and timers is always on, yes.
Is the clock right?
I don't understand what your custom .target is supposed to do and why you aren't using a standard target. How does this target get activated? Why are your timers activating targets rather than services?
I don't really see why the files you posted got the scripts to run at all ....

I tried looking in journalctl, can't find anything that mentions suspending.
The clock is correct in my system, yes.

I read numerous guide online where people used targets to trigger multiple service units at one time, here's one:
https://jason.the-graham.com/2013/03/06 … same-timer

berbae wrote:

I made some tests with a timer triggering a target unit instead of a service unit.
My conclusion is that a target unit is not usable with a timer.
Because once the target is reached, after it has been started by the timer, it stays in 'Active' state, ie it doesn't stop.
And I found that the timer doesn't work any longer after that.
Apparently the unit started by the timer must not stay in 'Active' state to be started again by the timer.
So I propose this solution instead of what you tried:
For 'timer-borgArch.timer'
[Unit]
Description=Run borg backup daily for Arch Linux.

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
AccuracySec=1s

[Install]
WantedBy=timers.target
And for 'timer-borgArch.service'
[Unit]
Description=Run borg backup for Arch Linux system to local then to NAS.

[Service]
Type=oneshot
User=root
ExecStart=/home/user/.scripts/borg/borgArchLocal.sh
ExecStart=/home/user/.scripts/borg/borgArchNAS.sh
This should work as expected. I made tests here and this is good.

After editing my timer-borgArch.timer and creating a timer-borgArch.service to match your suggestion my system fails to start the timer:

systemctl start timer-borgArch.timer
Job for timer-borgArch.timer failed.
See "systemctl  status timer-borgArch.timer" and "journalctl  -xe" for details.

$ systemctl status timer-borgArch.timer
● timer-borgArch.timer - Run borg backup daily for Arch Linux.
   Loaded: loaded (/etc/systemd/system/timer-borgArch.timer; enabled; vendor preset: disabled)
   Active: inactive (dead) since Mon 2017-11-27 22:40:23 CET; 13min ago
  Trigger: n/a

journalctl -xe doesn't seem to show any relevant info, how else can I check this?

cfr · 2017-11-28 02:05:17

7thSon wrote:

I read numerous guide online where people used targets to trigger multiple service units at one time, here's one:
https://jason.the-graham.com/2013/03/06 … same-timer

The trouble is, it is extremely unclear how to adapt the .timer file in that example to activate a target. The instructions suggest the file is just the same as above, but clearly that can't be right as there's no corresponding service in this case.

The wrapper script option would presumably be straightforward. Have you considered that option?

I don't think you can use ExecStart more than once .... Otherwise, there'd be no point in the multiple-timer workarounds. At least, I think so ....

Last edited by cfr (2017-11-28 02:12:10)

berbae · 2017-11-28 10:20:07

What I proposed in my previous post works here, with two 'ExecStart' lines, which is good when the type is 'oneshot'.
I think what is told in the link from 'jason.the-graham.com' will work only once but cannot be repeated with 'OnCalendar' parameter or other.
I have tested this here and that doesn't work.

The timer which I gave to you, should have started without error.
But evidently you have to stop/remove what have been done before, and run 'systemctl daemon-reload' before trying again.

cfr · 2017-11-29 01:23:36

berbae wrote:

What I proposed in my previous post works here, with two 'ExecStart' lines, which is good when the type is 'oneshot'.

Oh, yes. You're quite right - sorry, I forgot that this was supported in that case.

Arch Linux

#1 2017-10-30 17:20:59

[SOLVED] systemd timer failing after first run?

#2 2017-10-31 02:43:23

Re: [SOLVED] systemd timer failing after first run?

#3 2017-10-31 02:53:54

Re: [SOLVED] systemd timer failing after first run?

#4 2017-10-31 07:33:24

Re: [SOLVED] systemd timer failing after first run?

#5 2017-10-31 23:51:46

Re: [SOLVED] systemd timer failing after first run?

#6 2017-11-01 07:21:50

Re: [SOLVED] systemd timer failing after first run?

#7 2017-11-02 01:31:15

Re: [SOLVED] systemd timer failing after first run?

#8 2017-11-04 10:03:04

Re: [SOLVED] systemd timer failing after first run?

#9 2017-11-04 14:28:57

Re: [SOLVED] systemd timer failing after first run?

#10 2017-11-04 15:20:43

Re: [SOLVED] systemd timer failing after first run?

#11 2017-11-04 16:28:35

Re: [SOLVED] systemd timer failing after first run?

#12 2017-11-04 17:04:06

Re: [SOLVED] systemd timer failing after first run?

#13 2017-11-05 15:53:37

Re: [SOLVED] systemd timer failing after first run?

#14 2017-11-05 23:32:14

Re: [SOLVED] systemd timer failing after first run?

#15 2017-11-07 16:46:59

Re: [SOLVED] systemd timer failing after first run?

#16 2017-11-14 16:41:41

Re: [SOLVED] systemd timer failing after first run?

#17 2017-11-23 10:00:59

Re: [SOLVED] systemd timer failing after first run?

#18 2017-11-23 16:00:12

Re: [SOLVED] systemd timer failing after first run?

#19 2017-11-26 21:43:46

Re: [SOLVED] systemd timer failing after first run?

#20 2017-11-27 00:43:07

Re: [SOLVED] systemd timer failing after first run?

#21 2017-11-27 15:32:12

Re: [SOLVED] systemd timer failing after first run?

#22 2017-11-27 22:05:53

Re: [SOLVED] systemd timer failing after first run?

#23 2017-11-28 02:05:17

Re: [SOLVED] systemd timer failing after first run?

#24 2017-11-28 10:20:07

Re: [SOLVED] systemd timer failing after first run?

#25 2017-11-29 01:23:36

Re: [SOLVED] systemd timer failing after first run?

Board footer