43

Here are some points about those two: checking what your cron job really does can be kind of a mess, but all systemd timer events are carefully logged in systemd journal like the other systemd units based on the event that makes things much easier. systemd timers are systemd services with all their capabilities for resource management, IO CPU scheduling, .....


22

The state of currently active timers can be shown using 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....


16

Straight from the horse's mouth, so to speak: https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement An excerpt from the page above: Benefits The main benefits of using timers come from each job having its own systemd service. Some of these benefits are: Jobs can be easily started independently of their timers. This ...


14

if myjob.service contains no [Install] block, then it is sufficient to just disable the timer. The timer was the only thing starting the .service file, so with the .timer disabled, nothing will start the .service file. Also remember to run systemctl --user stop myjob.timer. Disabling the timer prevents it from being started on the next boot, but it does not ...


7

From @phg comment and answer, I found a page with the answer. The timers are cumulative and you need to reset them first otherwise the previous entry stays around. This is useful for calendars, but it works the same with all timers. Having one entry which resets the timer before changing it to a new value works as expected: # This file was auto-generated ...


7

A quick search for [systemd users] found this answer as the first result for you: The systemd user instance is started after the first login of a user and killed after the last session of the user is closed. Sometimes it may be useful to start it right after boot, and keep the systemd user instance running after the last session closes, for instance ...


6

Every 2 hours at 30 minutes past the hour should be OnCalendar=00/2:30 # iow hh/r:mm 00/2 - the hh value is 00 and the repetition value r is 2 which means the hh value plus all multiples of the repetition value will be matched (00,02,04..14,16..etc) 30 - the mm value, 30 will match 30 minutes past each hour I left the date and the seconds out since, ...


5

As of version 233, systemd supports using "~" in its calendar syntax to specify dates relative to the end of the month. OnCalendar=*-02~03 means the third last day in February (the 26th or 27th, depending on whether or not it's a leap year) Mon *-05~07/1 and Mon *-05~01..07 are synonyms for the last Monday in May. https://github.com/systemd/systemd/blob/...


5

An answer to this question is to swap User=nobody not with User=ziga but with User=root in /etc/systemd/system/battery.service. Somehow even if user ziga has all the privileges of using sudo command it can't execute systemctl hibernate inside of the bash script. I really don't know why this happens. So the working files are as follows: /etc/systemd/system/...


5

This is systemd timer behaviour that is triggered by a system clock that was at one point erroneously set to a time in the future, the year 2092 in your case: Zeal Jagannatha (2017-05-26). systemd timers do not reset after a time/date change. systemd bug #6036. GitHub.


5

For the simple use case, use WantedBy=timers.target. See man systemd.special: timers.target A special target unit that sets up all timer units (see systemd.timer(5) for details) that shall be active after boot. It is recommended that timer units installed by applications get pulled in via Wants= dependencies from this unit. This is best ...


5

Is it possible to have it run at multiple moments by declaring it in the same timer? Yes. See this excerpt from man systemd.timer (my emphasis): OnCalendar= Defines realtime (i.e. wallclock) timers with calendar event expressions. See systemd.time(7) for more information on the syntax of calendar event expressions. Otherwise, the semantics are ...


4

systemd timer units can take multiple OnCalendar= specifications, so when you're creating your override to run at 3am, you're actually adding that time (making it run twice daily, at midnight and 3am.) When you list the timer, it will show you the next schedule for it and, unless you're running that command between midnight and 3am, what you'll see is the ...


3

You could be looking in the wrong place. Units can be in several places. $ systemctl cat systemd-tmpfiles-clean.service # /lib/systemd/system/systemd-tmpfiles-clean.service ... (you can also see a command here: $ systemctl status systemd-tmpfiles-clean.service ● systemd-tmpfiles-clean.service - Cleanup of Temporary Directories Loaded: loaded (/lib/...


3

You could use ExecStartPost=/bin/systemctl start some-other-service if the Type= is oneshot. Read about the details in man systemd.service To review a full list of directions, use man systemd.directives, which lists all the directions and where they are documented.


3

I was also having the same problem and could not figure out why units would always run at startup regardless of the Persistent setting in the .timer file and it took me a while but I finally found the cause (pointed in the right direction by @alexander-tolkachev's comment). The problem is that I have always included something like WantedBy=basic.target in ...


3

I am not aware of a way to get this done with systemd, as I think it is only concerned about starting and running of units. As in, you can use After= to force a unit to start only AFTER the specified one has started, or both start in parallel. Wants= will cause the specified units to be started in parallel (if the wanted units are not yet started/active), ...


3

Until the Systemd bug is fixed, I used this workaround to get the timers in sync again: Touch all files with broken timestamps in /var/lib/systemd/timers Reboot the machine Now, systemctl list-timers shows sane output again. According to the Arch documentation, deleting the timestamp files should also be safe: If a timer gets out of sync, it may help ...


3

I was also looking for an explanation and the man-pages on a recent Raspberry Pi Jessie image sort of gave me one. I first looked here: man 7 systemd which then lead me to look at: man 5 systemd.unit which provided the following: RequiresMountsFor= Takes a space-separated list of absolute paths. Automatically adds dependencies of type Requires= ...


3

Arch Linux supplies btrfs-progs with a .timer unit file for btrfs-scrub that can be activated with: systemctl enable btrfs-scrub@-.timer The dash ("-") after the @ symbol is used to indicate the root directory, see the ArchWiki page for more on this: https://wiki.archlinux.org/index.php/Btrfs#Start_with_a_service_or_timer To check the status, use: ...


3

You're using an invalid time range. When using BEGIN..END, END must be later than BEGIN. Obviously, 00 is earlier than 05 so 05..00 errors out. You need OnCalendar=*-*-* 05..23:*:00 This will run your script every minute from 05:00 until 23:59. I assume that was your intent. If instead you wanted to run from 05:00 until 0:59 you would use OnCalendar=*-*-*...


3

Welcome to StackExchange. Your output says that feh can't open the X server. You should set a couple of values in wallpaper.server User= Set this the user you want to set the wallpaper for. Environment=DISPLAY=:0 Needs to go in the Display section. This post explains why both are needed.


3

To stop all currently running timers, you can simply use: systemctl stop '*.timer' To restart the timers later, you’ll have to remember which ones were running at the time. timers=$(systemctl list-units --type=timer --state=active --no-legend | awk '{print $1}') systemctl stop $timers # ... systemctl start $timers (Apparently patterns for units don’t ...


3

You can find detailed description how to specify time for timer unit in man systemd.time: Examples for valid timestamps and their normalized form: hourly → *-*-* *:00:00 So I guess the value you want to put there is: *-*-* *:50:00 Also: Either time or date specification may be omitted, in which case the current day and 00:00:00 is implied, ...


3

You're meant to provide the name of the unit, not the path to a file. You should have done instead: systemctl enable ftc-data.timer systemctl start ftc-data.timer systemctl enable ftc-data.service


2

May be you shoul try to add first start after boot, like this: [Timer] OnBootSec=15min OnUnitActiveSec=2m


2

Add Restart=always to the service unit, so systemd will keep bringing up the service if it crashes. On a side note you should use OnUnitInactiveSec instead of OnUnitActiveSec. OnUnitInactiveSec=10s (or 20s) will start the service 10 seconds after it stopped. This way you make sure it doesn't get called twice and possibly avoid banning for DOSing google


2

It seems there is no problem with the Persistent option and suspend. The problem seems to be that Persistent=true only works if the timer has had a chance to trigger at least once, i.e. if LAST is not n/a. But my computer is normally suspended at midnight, so the timer has never triggered.


2

Add an extra directive OnActiveSec=0s to the [Timer] stanza. The systemd maintainer explains how this works.


2

List timers, and show journal for the journal/log unit history: systemctl list-timers # replace motd-news with mytimer journalctl -u motd-news.timer Output: -- Logs begin at Fri 2018-11-02 13:17:39 CDT, end at Sat 2018-11-03 11:20:59 CDT. -- Nov 02 13:17:52 pop-os systemd[1]: Started Message of the Day. Nov 02 18:45:46 pop-os systemd[1]: Stopped Message ...


Only top voted, non community-wiki answers of a minimum length are eligible