I have a unit that normally I want running, but sometimes I want to manually shut it off for the day and restart it later automatically. So I have a timer to restart it OnCalendar=daily. This works, but sometimes I need to stop the unit twice because the timer immediately restarts the unit. Here's a simplified example with minutes instead of days: [Unit] Description=foo timer [Timer] Persistent=false OnCalendar=minutely AccuracySec=1 Unit=foo.service [Install] WantedBy=default.target --- [Unit] Description=foo service [Service] Type=simple ExecStart=/bin/sh -c 'while true; do sleep 1; done' [Install] WantedBy=default.target --- If I systemctl stop foo.service, and the timer had fired more than 1 minute ago (PASSED > 1m in systemdctl list-timers), it immediately refires and starts the unit. The unit always stays stopped until the next minute if I stop it twice. The docs make it sound like Persistent=false should not cause this, but clearly I'm misunderstanding. If it matters, the daily unit I'm actually interested in is a system unit, but the test unit is a user unit; the behavior is the same.

I am trying to to get my first systemd service working as desired. Here is what I have: gateway-watchdog.service:

# A systemd service for the Gateway Watchdog

[Unit]
Description=gateway-watchdog: Watchdog to ensure that Gateway (gateway.py) is running

[Service]
Type=simple
User=root
WorkingDirectory=/home/ubuntu/lora_gateway/
ExecStart=/home/ubuntu/lora_gateway/watchdog.sh

[Install]
WantedBy=multi-user.target

gateway-watchdog.timer:

[Unit]
Description=gateway-watchdog: Timer to run the associated gateway-watchdog service

[Timer]
# Run service 1 minute after boot
OnBootSec=1min
# Run service 15 minutes after the last run
OnUnitActiveSec=30s

[Install]
WantedBy=timers.target

watchdog.sh has these lines (contained in some if statements):

#!/bin/bash
...
if [[condition]]; then
    command="python3 gateway.py"
        # Process needs to be run in the background with '&'. If it isn't, the systemd service will treat this script
        # as still running and so not re-run it at the time specified by the timer service.
    echo "2 $(date +'%F %T'): Running: $command" >> $LOG_FILE_PATH
    eval "$command"
        # Command must be run using eval. If it isn't, the ampersand at the end of the command is effectively ignored
    exit
fi

What I need: The service will run watchdog.sh. If the if conditions in the script are true, watchdog.sh will launch python3 gateway.py as a separate process and then exit, and the service will no longer be considered active so that it will run again 30 seconds later. Through various combinations of different service Types (I've tried simple, oneshot, and forking), using & at the end of ExecStart and/or my command line, and/or using nohup, I am able to either launch and keep gateway.py alive, or have the service run every 30 seconds, but not both. When python3 gateway.py stays alive, it always stays part of the service's CGroup, so the service stays active (running). How can I change this behavior to achieve what I'm trying to do? Any thoughts are greatly appreciated. **EDIT**: I have updated the file contents above to reflect changes made based on suggestions from U. With the files as given above, sudo systemctl status gateway-watchdog.service gives:

● gateway-watchdog.service - gateway-watchdog: Watchdog to ensure that Gateway (gateway.py) is running
     Loaded: loaded (/etc/systemd/system/gateway-watchdog.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-01-13 01:45:25 UTC; 8s ago
TriggeredBy: ● gateway-watchdog.timer
   Main PID: 30684 (watchdog.sh)
      Tasks: 3 (limit: 4435)
     CGroup: /system.slice/gateway-watchdog.service
             ├─30684 /bin/bash /home/ubuntu/lora_gateway/watchdog.sh
             └─30696 python3 gateway.py

Jan 13 01:45:25 ubuntu systemd: Started gateway-watchdog: Watchdog to ensure that Gateway (gateway.py) is running.

Good: The gateway.py process stays running. Bad: The service does not run again 30 seconds later, because the previous run is still active. If I put the & back into command="python3 gateway.py &", sudo systemctl status gateway-watchdog.service gives:

● gateway-watchdog.service - gateway-watchdog: Watchdog to ensure that Gateway (gateway.py) is running
     Loaded: loaded (/etc/systemd/system/gateway-watchdog.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Thu 2022-01-13 01:49:05 UTC; 6s ago
TriggeredBy: ● gateway-watchdog.timer
    Process: 33724 ExecStart=/home/ubuntu/lora_gateway/watchdog.sh (code=exited, status=0/SUCCESS)
   Main PID: 33724 (code=exited, status=0/SUCCESS)

Jan 13 01:49:05 ubuntu systemd: Started gateway-watchdog: Watchdog to ensure that Gateway (gateway.py) is running.
Jan 13 01:49:05 ubuntu systemd: gateway-watchdog.service: Succeeded.

Good: The service is inactive, so it does run again 30 seconds later. Bad: The python3 gateway.py process dies immediately.

I was looking to get the exact formula that systemd uses for providing output such as this:

systemctl list-timers my

NEXT                        LEFT         LAST                        PASSED  UNIT                 ACTIVATES             
Tue 2025-06-03 14:49:55 BST 1min 57s left Tue 2025-06-03 14:46:55 BST 1min 2s ago my.timer my.service

A monotonic timer my does not store the NEXT value as a timestamp anywhere. It must be calculated somehow because the related timer unit properties look like this:

systemctl show my.timer | grep NextElapse
NextElapseUSecMonotonic=14h 53min 32.014313s

I am familiar with the differences between monotonic and calendar values, the relationship between the two during any particular boot is obvious with e.g. LAST value:

show my.timer | grep LastTrigger
LastTriggerUSec=Tue 2025-06-03 14:46:55 BST
LastTriggerUSecMonotonic=14h 50min 32.006179s

Anyhow I went to look at exactly how systemd list-timers command does it. In the process of nailing it down, I found GH issue of [*systemctl list-timers should be less confusing with the clocks it displays*](https://github.com/systemd/systemd/issues/12192) where it is stated: > The "systemctl lis-timers" thing shows all elapsation based on on CLOCK_REALTIME (it converts all timestamps for display), and that gets confusing if you suspended a couple of time in between I found the function [calc_next_elapse](https://github.com/systemd/systemd/blob/96e481bfbd6c52aabc72116f7ff479f11baeead1/src/systemctl/systemctl-list-units.c#L700) :

usec_t converted;

                if (next->monotonic > nw->monotonic)
                        converted = nw->realtime + (next->monotonic - nw->monotonic);
                else
                        converted = nw->realtime - (nw->monotonic - next->monotonic);

                if (timestamp_is_set(next->realtime))
                        next_elapse = MIN(converted, next->realtime);
                else
                        next_elapse = converted;

I figured nw is obtained as a "dual" timestamp that gets both CLOCK_REALTIME and CLOCK_MONOTONIC as clock_gettime(2) returns it. But the monotonic does not continue counting when the system is suspended while real clock does. Also I figured that NEXT could end up set to real time in the past - the code above accounts for it. I wonder if it is better to self-calculate NEXT of a monotonic timer as its monotonic value + the difference at the moment between e.g. LastTriggerUSec and LastTriggerUSecMonotonic or something completely different, e.g. systemctl show -P KernelTimestamp (which happens to equal to monotonic 0). Anyone has more in-depth knowledge of this or can point me to what I am missing out here?

I am writing a program that I would like to have the ability to schedule an action. This would work similar to the the TIME option in shutdown, where the user specifies a time and that information gets stored in a temporary file: /run/systemd/shutdown/scheduled Which contains a set of variables:

USEC=1742499354904002
WARN_WALL=1
MODE=reboot
UID=0
TTY=pts/0

At first I thought I could do something similar by having a service check for the existence of that file (with ConditionPathExists). If that file exists, read in those variables and start a second service that runs the program and has a temporary timer file, maybe like:

[Timer]
Environment=/run/systemd/customprogram/scheduled
OnCalendar=$(date -d "@${USEC}"  +"%a %Y-%m-%d %H:%M:%S") # converted

But systemd timers do not allow the Environment unit. It seems that shutdown does not use systemd timers but invokes some other method see here . Is there a simplistic, automated way to read a file to schedule a process with a variable time? I was designing this as a service because I would also be like to be able to send a signal to cancel or update the time as this program should only run a single instance at the "next" scheduled time.

I am testing a systemd timer and trying to override its default timeout, but without success. I'm wondering whether there is a way to ask systemd to tell us when the service is going to be run next. Normal file (/lib/systemd/system/snapbackend.timer): # Documentation available at: # https://www.freedesktop.org/software/systemd/man/systemd.timer.html [Unit] Description=Run the snapbackend service once every 5 minutes. [Timer] # You must have an OnBootSec (or OnStartupSec) otherwise it does not auto-start OnBootSec=5min OnUnitActiveSec=5min # The default accuracy is 1 minute. I'm not too sure that either way # will affect us. I am thinking that since our computers will be # permanently running, it probably won't be that inaccurate anyway. # See also: # http://stackoverflow.com/questions/39176514/is-it-correct-that-systemd-timer-accuracysec-parameter-make-the-ticks-slip #AccuracySec=1 [Install] WantedBy=timers.target # vim: syntax=dosini The override file (/etc/systemd/system/snapbackend.timer.d/override.conf): # This file was auto-generated by snapmanager.cgi # Feel free to do additional modifications here as # snapmanager.cgi will be aware of them as expected. [Timer] OnUnitActiveSec=30min I ran the following commands and the timer still ticks once every 5 minutes. Could there be a bug in systemd? sudo systemctl stop snapbackend.timer sudo systemctl daemon-reload sudo systemctl start snapbackend.timer So I was also wondering, how can I know when the timer will tick next? Because that would immediately tell me whether it's in 5 min. or 30 min. but from the systemctl status snapbackend.timer says nothing about that. Just wondering whether there is a command that would tell me the delay currently used. For those interested, there is the service file too (/lib/systemd/system/snapbackend.service), although I would imagine that this should have no effect on the timer ticks... # Documentation available at: # https://www.freedesktop.org/software/systemd/man/systemd.service.html [Unit] Description=Snap! Websites snapbackend CRON daemon After=snapbase.service snapcommunicator.service snapfirewall.service snaplock.service snapdbproxy.service [Service] # See also the snapbackend.timer file Type=simple WorkingDirectory=~ ProtectHome=true NoNewPrivileges=true ExecStart=/usr/bin/snapbackend ExecStop=/usr/bin/snapstop --timeout 300 $MAINPID User=snapwebsites Group=snapwebsites # No auto-restart, we use the timer to start once in a while # We also want to make systemd think that exit(1) is fine SuccessExitStatus=1 Nice=5 LimitNPROC=1000 # For developers and administrators to get console output #StandardOutput=tty #StandardError=tty #TTYPath=/dev/console # Enter a size to get a core dump in case of a crash #LimitCORE=10G [Install] WantedBy=multi-user.target # vim: syntax=dosini

Bit of a funny question: I have a systemd service where it is important that it actually executes (or fails) a fixed time after it is started. My understanding is that once Linux calls start on the service, it will execute as soon as it can. What I want is for Linux to call start, and then the service actually executes say 20s after this, or fails to start if the 20s condition is not met. The use case is something like: - Linux is woken up - It starts receiving data over a USB interface - A service is started that will process the data - The service processes the data - The service finishes processing the data - Linux shuts down Is it possible to configure a timer to do this? The aim is to be able to say that the service will definitely be awake and running 20s (say) after Linux wakes.

I have multiple Redhat & CentOS 7 servers that are used only during working hours. I am looking into using the systemd-shutdownd service to shut down each machine at 6-30pm on workdays. Systemd appears to be a cleaner solution than cron jobs. Google shows that there is a schedule file that this service uses, but I have not been able to find how to implement it. Also, I'd like a way to stop the auto-powerdown in case I work late on a particular day.

Following up on https://unix.stackexchange.com/questions/744160/schedule-a-job-every-20-days , > This is for renewing purpose, thus can be done sooner than 20 days. But I'm doing it from my laptop, which would be put into sleep most of the time. Thus guarantee execution is a must (which I read that cron is lack of). I chose systemd.timer over crom as I was under the impression that _"it would even work when the scheduled time passes by during my system went in sleeping mode, after it wakes up"_ However, it turns out to be not the case for me. Per its man page, the only close option is the Persistent= one: > Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive. Such triggering is nonetheless subject to the delay imposed by RandomizedDelaySec=. This is useful to catch up on missed runs of the service when the system was powered down. Note that this setting only has an effect on timers configured with OnCalendar=. However, I just realized that I am using OnUnitActiveSec=20d instead of the required OnCalendar=, so having Persistent=true will not be helping for my https://unix.stackexchange.com/questions/744160/schedule-a-job-every-20-days case, right? Is it possible for systemd.timer to catch up on missed runs of the services, scheduled with OnUnitActiveSec=, after the computer system has waken up from sleep? PS. All my systemd packages:

libpam-systemd:amd64_249.11-0ubuntu3.6
 libsystemd0:amd64_249.11-0ubuntu3.6
 python3-systemd_234-3ubuntu2
 systemd_249.11-0ubuntu3.6
 systemd-sysv_249.11-0ubuntu3.6
 systemd-timesyncd_249.11-0ubuntu3.6

I'm using a systemd timer and unit to automatically trigger a backup job. But currently it runs only at one moment in the evening. Is it possible to have it run at multiple moments by declaring it in the same timer? This is how it's now: [Unit] Description=Run luky-borg-backup every night [Timer] OnCalendar=21:00 AccuracySec=1h Persistent=yes [Install] WantedBy=timers.target Should be something like this: [Unit] Description=Run luky-borg-backup every night [Timer] OnCalendar=10:00,21:00 AccuracySec=1h Persistent=yes [Install] WantedBy=timers.target

I've created a systemd job using systemd-run --on-calendar .... Now I've replaced it with proper .timer and .service files, but I'm not able to remove the old one. I can stop it and disable it, but when I call systemctl list-timers it still appears with its arbitrary name run-r0d0dc22.... I also looked for its .timer file, but I couldn't find them.

I have a script that updates my google drive. I made a systemd unit to run this script, and a timer that runs the unit every 10 seconds, which both work. However, when I get disconnected from internet, the script fails and systemd stops running the it even if the internet comes back on. Is there any way I can make systemd keep on running the script, or is there a way to have systemd run the script only if there is an internet connection? Here are the files /etc/systemd/system/grive.service: [Unit] Description=Syncronize google drive folder [Service] User=my_name ExecStart=/home/my_name/bin/update-grive /etc/systemd/system/grive.timer: [Unit] Description=Timer for how often to syncronize google drive folder [Timer] OnUnitActiveSec=10s OnBootSec=10s [Install] WantedBy=timers.target /home/my_name/bin/update-grive: #!/usr/bin/env bash cd /home/my_name/gdrive grive

I've written a short script to copy and encrypt my home dir for backup. I do this using

gpg --symmetric

I call this from my backup.service file, and it works fine: when I run systemctl --user start backup.service from gnome-terminal, I get a graphical prompt to enter the password for encryption, and I see an output file created successfully. However, when I put this in a backup.timer unit, and try to run that with systemctl --user start backup.timer :

~/bin$ systemctl --user status backup.timer
● backup.timer - Daily backup schedule
     Loaded: loaded (/home/xxx/.config/systemd/user/backup.timer; disabled; vendor preset: en>
     Active: active (waiting) since Fri 2024-09-06 15:13:34 CEST; 6s ago
    Trigger: Sat 2024-09-07 00:00:00 CEST; 8h left
   Triggers: ● backup.service

It just hangs like this, and the password prompt dialog doesn't appear. I'm guessing that timer units don't have access to the environment. I've checked that necessary variables like XAUTHORITY and DISPLAY are set via systemctl --user show-environment. What can I do to troubleshoot this? For completeness, I have created a minimal reproducible example. These are the files:

~$ cat ~/.config/systemd/user/test-password.service
[Unit]
Description=Test password prompt

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'dd if=/dev/zero count=100 | gpg --symmetric > /tmp/test.gpg'

and

~$ cat ~/.config/systemd/user/test-password.timer
[Unit]
Description=Test password prompt timer

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

I have this timer:

$ systemctl cat ansible-pull.timer
# /etc/systemd/system/ansible-pull.timer
[Unit]
Description=Starts ansible-pull
Requires=ansible-pull.service

[Timer]
OnStartupSec=10min
OnUnitActiveSec=6h

[Install]
WantedBy=timers.target

Calling this service:

$ systemctl cat ansible-pull.service
# /etc/systemd/system/ansible-pull.service
[Unit]
Description=Runs ansible-pull

[Service]
Type=oneshot
User=ansible
ExecStart=/usr/bin/ansible-pull

And it generally works as expected (runs 10 mins after boot and then every 6h), except that it also runs once immediately during boot, which I'd like to avoid. I would have expected this for a timer with Persistent=true, but it's not set here and defaults to false. Some more debugging data:

$ systemctl list-dependencies --reverse ansible-pull.timer
ansible-pull.timer
● └─timers.target
●   └─basic.target
○     ├─initrd.target
●     └─multi-user.target
●       └─graphical.target

$ systemctl list-dependencies --reverse ansible-pull.service
ansible-pull.service
● └─ansible-pull.timer

$ find /{etc,usr/lib}/systemd/ -name ansible-pull.\*
/etc/systemd/system/ansible-pull.service
/etc/systemd/system/ansible-pull.timer
/etc/systemd/system/timers.target.wants/ansible-pull.timer

I wanted to run a service that runs once per day (exact time of day is not important right now). My interpretation of > OnUnitInactiveSec= defines a timer relative to when the unit the timer is activating was last deactivated. is that there will be a specified pause between the unit being run (and thus inactive again) and the next invocation. My units are defined like this: Service: ~~~lang-systemd-unit [Unit] Description=User Check (%i) Documentation=man:user-check@.service man:user-check(8) After=multi-user.target AssertPathExists=/etc/user-check/common.conf AssertPathExists=/etc/user-check/%i.conf [Service] Type=simple EnvironmentFile=/etc/user-check/common.conf EnvironmentFile=/etc/user-check/%i.conf ExecStart=/usr/bin/user-check \ $CHECK_SELECTION --notification-template=${NOTIFICATION_TEMPLATE} \ $OTHER_OPTIONS RestartPreventExitStatus=1 2 ~~~ Timer: ~~~systemd-unit [Unit] Description=User Check (%i) Timer Documentation=man:user-check@.timer man:user-check@.service AssertPathExists=/etc/user-check/%i.conf [Timer] OnUnitInactiveSec=1day Unit=user-check@%i.service [Install] WantedBy=timers.target ~~~ The timer is both, enabled and started (actually I have four instances). Like this: ~~~lang-text # systemctl status user-check@pw-expiration.timer ● user-check@pw-expiration.timer - User Check (pw-expiration) Timer Loaded: loaded (/usr/lib/systemd/system/user-check@.timer; enabled; vendor preset: disabled) Active: active (elapsed) since Fri 2024-06-28 13:55:28 CEST; 2 days ago Docs: man:user-check@.timer man:user-check@.service Jun 28 13:55:28 v04 systemd: Stopped User Check (pw-expiration... Jun 28 13:55:28 v04 systemd: Stopping User Check (pw-expiratio... Jun 28 13:55:28 v04 systemd: Started User Check (pw-expiration... ~~~ The service unit had been executed once when the timer was started. I was expecting the timer to fire over the weekend, but it did not. What's wrong? Is there a "timer checklist"? I also tried an override using OnUnitActiveSec=15min, but 55 minutes passed since the unit had been active. When trying OnCalendar=hourly the last activation was an hour ago, but still nothing happened. It seems "systemctl edit" still requires a "reload" of the unit; doing so seemed to enable the calendar timer, but the original timers just don't work (see the n/a). The output of systemctl list-timers is: ~~~lang-text # systemctl list-timers NEXT LEFT LAST PASSED UNIT Mon 2024-07-01 15:00:00 CEST 35min left n/a n/a user-check@auth-fail. n/a n/a n/a n/a user-check@grace-logi n/a n/a n/a n/a user-check@pw-expirat ~~~

I like to keep my custom unit files in their own directory away from /etc. In 247 this worked well, using something like the following: systemctl enable /path/to/unit.service This also worked with templates, even those that had an associated timer: systemctl enable /path/to/timed-unit@.* After which you would instantiate: systemctl enable timed-unit@instance.timer However in 252 when trying to enable the files using pathnames, I now get the following errors: Failed to enable unit: Destination unit timers.target is a non-template unit. or: Failed to enable unit: Destination unit multi-user.target is a non-template unit. The docs indicate that if a template lists a service (in this case via WantedBys), then it needs a DefaultInstance or instance provided on enabling. This kind of makes sense, so either the behaviour has been tightened up, or a bug has been fixed in 252. However providing an instance to the path results in a file not found error (as would be expected). I could probably create the symlinks myself, but is there any way to have systemd register a unit file on the filesystem to be enabled with an instance later? https://www.freedesktop.org/software/systemd/man/systemd.unit.html#%5BInstall%5D%20Section%20Options

I have a problem where on rare occasions my Type=simple systemd service hangs or gets caught in a loop. This causes its timer to stop scheduling the service because, as confirmed with sudo systemctl status myservice, the service is still running when it should have long exited. I haven't yet figured out the bug but it isn't critical. But in the mean time I don't want it to stop scheduling future runs. Is there a way to specify in the systemd service file a maximum run time, after which it will force stop? [Unit] Description=scripts should run and exit but occasionally hangs or infinite loop [Service] SyslogIdentifier=myservice Environment='MYVAR=myvar' User=deanresin Type=simple ExecStart=/usr/bin/python3 /home/deanresin/myscript

I use cloud-config to install and configure DCOS cluster. Normally agentinstall.service service takes 5 minutes to complete. Is it possible to instruct to systemd to execute agentconfigure.service _only after_ agentinstall.service completed?

#cloud-config
coreos:
  units:
    - name: "agentinstall.service"
      command: "start"
      content: |
        [Unit]
        Description=agent_setup
        After=network.target

        [Service]
        Type=simple
        User=root
        WorkingDirectory=/tmp
        ExecStartPre=/bin/curl -o /tmp/dcos_install.sh  http://bootstapnode-0.dev.myztro.internal:9090/dcos_install.sh 
        ExecStartPre=/bin/chmod 755 dcos_install.sh
        ExecStart=/bin/bash dcos_install.sh slave

        [Install]
        WantedBy=multi-user.target
    - name: "agentconfigure.service"
      command: "start"
      content: |
        [Unit]
        Description=agent_config
        After=agentinstall.service

        [Service]
        Type=simple
        User=root
        WorkingDirectory=/opt/mesosphere/etc/
        ExecStartPre=/bin/echo "MESOS_ATTRIBUTES=cluster:uploader" >> /opt/mesosphere/etc/mesos-slave-common
        ExecStartPre=/bin/rm -f /var/lib/mesos/slave/meta/slaves/latest
        ExecStart=/usr/bin/systemctl restart dcos-mesos-slave

        [Install]
        WantedBy=multi-user.target

Thank you.

I have a service that runs a python script:

[Unit]
Description="Daily python service"

[Service]
WorkingDirectory=/home/ubuntu/python_project/
ExecStartPre=/bin/bash -c 'truncate -s 0 /var/log/project.log /var/log/project_error.log'
ExecStart=/home/ubuntu/.conda/envs/test/bin/python -u main.py
StandardOutput=append:/var/log/project.log
StandardError=append:/var/log/project_error.log

[Install]
WantedBy=multi-user.target

I want this to run daily at a specific time:

[Unit]
Description=Run service daily

[Timer]
OnCalendar=*-*-* 12:00:00
Persistent=true

[Install]
WantedBy=timers.target

When I reload the daemon, enable the timer, and start the timer, it runs the first day. But after the first day it stops running automatically, unless I manually stop the service. Why is this happening? And how do I get around this?

(x-mas.service) [Unit] Description=Celebrate X-Mas [Service] Type=simple ExecStart=/usr/sbin/x-mas-day [Install] WantedBy=multi-user.target (x-mas.timer) [Unit] Description=Add "X-Mas" to the calendar [Timer] OnCalendar=*-12-25 00:00:00 Unit=x-mas.service [Install] WantedBy=timers.target (buy-presents.service) [Unit] Description=Get your wallet out Requires=x-mas.service Before=x-mas.service [Service] Type=simple ExecStart=open-amazon-dot-com.sh [Install] WantedBy=multi-user.target (buy-presents.timer) [Unit] Description=Buy presents Before=x-mas.timer Requires=x-mas.timer [Timer] OnActiveSec=1 AccuracySec=no-pressure? RandomizedDelaySec=true? [Install] #WantedBy=timers.target RequiredBy=x-mas.timer Clearly there is still plenty of time from today to _buy presents_ so optimized flexibility in scheduling before the 'x-mas deadline' is desired, but it was not immediately obvious to me on first reading [systemd.timer(5)](https://man.archlinux.org/man/systemd.timer.5) how to even relate timers to other timers. Can this be done with systemd units only?

It was recently pointed out to me that an alternative to cron exists, namely systemd timers. However, I know nothing about systemd or systemd timers. I have only used cron. There is a little [discussion in the Arch Wiki](https://wiki.archlinux.org/index.php/Systemd/Timers) . However, I'm looking for a detailed comparison between cron and systemd timers, focusing on pros and cons. I use Debian, but I would like a general comparison for all systems for which these two alternatives are available. This set may include only Linux distributions. Here is what I know. Cron is very old, going back to the late 1970s. The original author of cron is Ken Thompson, the creator of Unix. Vixie cron, of which the crons in modern Linux distributions are direct descendants, dates from 1987. Systemd is much newer, and somewhat controversial. Wikipedia tells me its initial release was 30 March 2010. So, my current list of advantages of cron over systemd timers is: 1. Cron is guaranteed to be in any Unix-like system, in the sense of being an installable supported piece of software. That is not going to change. In contrast, systemd may or may not remain in Linux distributions in the future. It is mainly an init system, and may be replaced by a different init system. 2. Cron is simple to use. Definitely simpler than systemd timers. The corresponding list of advantages of systemd timers over cron is: 1. Systemd timers may be more flexible and capable. But I'd like examples of that. So, to summarise, here are some things it would be good to see in an answer: 1. A detailed comparison of cron vs systemd timers, including pros and cons of using each. 2. Examples of things one can do that the other cannot. 3. At least one side-by-side comparison of a cron script vs a systemd timers script.