You are not logged in.
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)
Offline
Don't you need a
WantedBy=timers.target
somewhere?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Are you sure you enabled it as well as started it?
Offline
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.
Are you sure you enabled it as well as started it?
Yes, I double checked this before.
Offline
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 workCould 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)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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.
Offline
Maybe https://bbs.archlinux.org/viewtopic.php?id=231408 helps?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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)
Offline
Just another guess, maybe a systemctl daemon-reload needs to be done to invoke the changes.
Offline
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".
Offline
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?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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)
Offline
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?
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)
Offline
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.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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
Offline
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.
Offline
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.
Offline
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?
Offline
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.
Offline
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)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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.
Offline
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
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?
Offline
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)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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.
Offline
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.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline