Feature Request: systemd timers

[risen]

Would it be possible to generate systemd units + timers for every task instead of editing the crontab?

There's some advantages to job units + timers, like cgroups, ability to depend on other systemd units, easier management and debugging, output to journald etc.

[taketo1113]

I understand the usefulness of systemd timers, and I agree they provide several advantages.
At the same time, cron and systemd timers have different configuration parameters and behaviors. For now, I think it might make sense to support systemd timers via a separate library rather than integrating them directly into whenever, to keep the core simpler.

For example, we would need to abstract differences in logging and handle features that exist only on one side, such as MAILTO in cron or Persistent in systemd timers. This could increase implementation and maintenance complexity in the the core project.

That said, I'm interested in the motivation behind this.
What use cases do you have in mind for using systemd timers with whenever?

[risen]

So, the reason I'm asking is for a few reasons:

• I'm looking into a different deploy system. Quadlets, systemd portable services, or the (future) systemd OCI container support would pick up timers and automatically work.
• Ensuring long-running jobs don't step on their own toes is easier.
• Monitoring them is easier, even just systemctl list-timers is helpful.
• The (stdin/stderr) output was logged in a basic log file without timestamps. Figuring out what exactly went wrong where seems easier with journalctl.
• The lines in the crontab were getting unwieldy with lots of bash -c, rbenv exec, etc wrappers, setting up env vars etc. I was looking to DRY this up a bit.
• Currently I'm deploying using mina and using systemd --user instance to keep services up and running. Since I'm using systemd already, it seemed easier to just have timers too. This become more obvious was hitting ENV differences between what the app (puma and job worker) was using and what was available in the user's crontab.

I haven't moved to timers yet, but I did start using a myapp-rake@.service template unit for rake tasks. I'll share just FYI:

schedule.rb:

env 'XDG_RUNTIME_DIR', "/run/user/#{Process.uid}"

set :job_template, nil

job_type :rake, "systemctl --user start \"myapp-rake@:task\""

A line in the crontab looks like this:

0 * * * * systemctl --user start "myapp-rake@myapp:some_task"

The template unit for rake tasks:

# /srv/user/.config/systemd/user/myapp-rake@.service
[Unit]
Description=Rake task: %I
OnFailure=myapp-failure@%n.service

[Service]
Type=exec
Environment=RAILS_ENV=production
EnvironmentFile=-/srv/user/myapp/shared/.env
WorkingDirectory=/srv/user/myapp/shared/current
ExecStart=rbenv exec bundle exec rake %I
SyslogIdentifier=myapp-rake-%i
TimeoutStartSec=1h

The myapp-failure@.service is a bit hacky for now, but it looks a little something like this:

# /srv/user/.config/systemd/user/myapp-failure@.service
[Unit]
Description=Failure notification: %i

[Service]
Type=oneshot
Environment=RAILS_ENV=production
EnvironmentFile=-/srv/user/myapp/shared/.env
WorkingDirectory=/srv/user/myapp/current
ExecStart=/usr/bin/bash -c ' \
  { \
    DASHED=$${RAILS_ENV//_/-}; \
    echo "Subject: [MYAPP-$${DASHED^^}] %i failed on $$(hostname)"; \
    echo "To: $${WATCHDOG_RCPT}"; \
    echo ""; \
    echo "Systemd unit %i has failed in the $${RAILS_ENV} environment."; \
    echo ""; \
    echo "--- Status ---"; \
    systemctl --user status %i; \
    echo ""; \
    echo "--- Logs ---"; \
    journalctl --user -u %i -n 50 --no-pager; \
  } | /usr/sbin/sendmail -t'

[taketo1113]

@risen Thank you for letting me know.

If we are going to support systemd timers, I think it would be better to implement it as a separate gem. What do you think?

If you're interested in creating a separate gem, I would be happy to help, for example by setting up a GitHub organization for whenever and providing support as needed.