Systemd Timers vs. Cron: A Job Security Play

Description

A screenshot of a comment thread from a minimalist, text-based forum, likely Hacker News. The first comment, posted by user 'AlexITC', asks a question: 'Any reason to use systemd timers instead of cron jobs?'. A nested reply from user 'casey2' delivers the punchline: 'Exactly 1. Job security.'. The visual is simple, focusing entirely on the text exchange, which is displayed in a clean, proportional font against a light-colored background. This meme captures a common debate in the Linux and DevOps communities. Cron is the traditional, universally understood tool for scheduling tasks, while systemd timers are a more modern, integrated, but often more complex alternative. The joke is a cynical take on engineering choices, suggesting that opting for a more complex or less-known technology can make an engineer's role more indispensable, thereby creating job security. It's a humorous critique of over-engineering and the motivations behind technology selection

Comments

Anonymous ★ Top Pick The best part about replacing all the cron jobs with a complex web of systemd timers is that the next person who has to maintain it will probably be you, five years from now, with no memory of how it works

Anonymous ★ Top Pick

The best part about replacing all the cron jobs with a complex web of systemd timers is that the next person who has to maintain it will probably be you, five years from now, with no memory of how it works
Anonymous

I replaced five cron lines with a .service, a .timer, and a 12-page runbook - now management thinks we invented a proprietary scheduling platform, so I’m safe until the next reorg
Anonymous

The real systemd timer advantage is that when your 3am cron job fails, you can blame it on a transient unit dependency failure in the journal instead of admitting you forgot to escape a percent sign
Anonymous

The real reason to use systemd timers? So you can spend three hours writing unit files, service dependencies, and debugging 'Failed to start timer: Unit not found' errors - all to accomplish what a single line in crontab does. But hey, at least you'll have plenty of job security explaining to the next engineer why a simple scheduled task now requires understanding socket activation, target dependencies, and the systemd journal. Cron: boring, reliable, and dangerously easy to understand
Anonymous

If your 2am backup needs a unit, a target, a Wants= graph, and journald archaeology, congratulations - you’ve turned ‘crontab -e’ into an employee retention program
Anonymous

Cron is for 03:00; systemd timers are for being the only person who can explain why it didn’t run at 03:00 after DST - WantedBy=job-security.target
Anonymous

Systemd timers: because 'you can't fire me, I know WTF this unit file does' beats cron every time
@cmdrosmium 2y

well it's true, systemd timers is more reliable than cron and they have kinda better security because of systemd's features
@dsmagikswsa 2y

We can also check the status of systemd task, right?
@samorosnie 2y

Let's start some flamewar about systemd
1. @SamsonovAnton 2y
  
  Not until some explains what is wrong with cron jobs with regard to security, and how exactly systemd is better in this aspect.
  
  @Box_of_the_Fox 2y
  
  It seems like there's nothing wrong with Cron regarding security, just systemd looks to be better as you can use its built in security features like these https://www.ctrl.blog/entry/systemd-service-hardening.html or at least that's what someone pointed out on Reddit
  
  @CcxCZ 2y
  
  Anything systemd does there can be done with discrete tool too.
  
  @SamsonovAnton 2y
  
  Anything that ${tool} does, can be done with another tool, too. 😁
  
  @CcxCZ 2y
  
  And yet the entire argumentation for using systemd seems to be "but systemd has feature X built-in" as if "write programs to work together" wasn't one of the guiding principles of design of Unix systems from the early days. Often using false comparisons like these. Cron doesn't do security sanboxing? Duh! You know what it does? Runs arbitrary program including over a dozen of sandboxing solutions, each with it's advantages and disadvantages.
  
  @RiedleroD 2y
  
  the reason I use systemd is because I know how to use it. I don't know how to make cron do its job.
  
  @CcxCZ 2y
  
  Nothing against people choosing the tools they want. Personally I'm not fan of the traditional cron design, hence I'm mostly using snooze I linked above.
  
  @mekosko 2y
  
  Does at least one init give you the same ease of creating your own service files as systemd, that it's enough for you to write a toml file and everything works?
  
  @RiedleroD 2y
  
  as someone who's written several systemd service files over the years: they suck, are awful, and complete utter garbage. But once they work, they do work.
  
  @mekosko 2y
  
  Have you ever written services for other inits?
  
  @RiedleroD 2y
  
  no, but it can't be worse than the unintuitive shit systemd does
  
  @mekosko 2y
  
  Most of them are not even declarative
  
  @RiedleroD 2y
  
  what does that mean again?
  
  @mekosko 2y
  
  You're just writing a bash script using the init API
  
  @RiedleroD 2y
  
  sounds not that bad tbh
  
  @mekosko 2y
  
  https://wiki.gentoo.org/wiki/OpenRC/User_services
  
  @RiedleroD 2y
  
  I have better things to do than read that tbh, sorry if you wanted an informed discussion
  
  @SamsonovAnton 2y
  
  The main advantage of OpenRC or SysVinit is that it gives you the power of shell scripting. The main disdvantage of OpenRC or SysVinit is that it gives you the power of shell scripting. That is, you can do whatever you want and however you want, but you have to implement it yourself, even the most basic tasks; and you have to do it each time you write a new service script. So, SystemD is much like C#, and OpenRC / SysVinit is like C++ or even plain C.
  
  @RiedleroD 2y
  
  the two things often needed in systemd services are simply starting the service and restarting the service if it crashes. I've literally never needed more than that and I don't even know what else systemd could theoretically offer me.
  
  @CcxCZ 2y
  
  First, you should distinguish between SysV init and SysV rc system. (Conflating these was actually part of the disinformation campaign during the Debian vote on systemd support) Init is the PID1 and on both the old SysV and BSD systems it didn't do much besides running the rc system, reaping children and making sure gettys stay up. And rc system is what actually starts your services. I believe the closest match to old-style SysV rc is the system you'd find on Slackware (unless they decided to change it since I last saw it) where it just executes a bunch of (shell) scripts from a directory in alphabetical order and it's users responsibility to order them correctly and all that. There was a plenty of incompatible iterations on those. RedHat's was common among rpm distros, Debian's insserv and finally Gentoo's baselayout later split up into separate OpenRC package. Feature of all these rc systems is that they are init independent since they background tasks without any supervision or any other feature that would hook into init. And you can even use several of them in parallel unless you need automatic dependency resolution across services in different rc systems. In parallel to rc systems there was evolution of supervisors, mostly stemming from DJB's daemontools. The rationale for those was extreme focus on reliability. Signalling a PID stored in a file is racy and any system with memory overcommit enabled is prone to killing processes under memory pressure even if there are no bugs in the daemon - so restarts are necessity. To accomplish this you generally want "rooted" supervision tree, meaning parent of the supervisor is also supervised and so forth up to PID 1 which can't be killed without the system itself going down. Daemontools was usually run from inittab on sysv-init systems (same for daemontools-encore fork and perp), while runit ships it's own maybe too minimalist init implementation and s6 provides hooks for the few features needed of init that are needed of init on Linux that aren't part of supervisor's task already (specifically special signal handling and shutdown chainloading) and provides s6-linux-init-maker to generate that configuration. There are several rc systems built specifically to run above a supervisor and launch supervised services. My favourite is s6-rc but you may also be interested in anopa or the system in VoidLinux. Unlike sytemd that tries to be everything and kitchen sink the daemontools-derived supervisors tend to have very well defined scope and implement it very well. They run executables, keep them up and allow you to send signals to them reliably; all in very straightforward fashion.
  
  @callofvoid0 2y
  
  TL;DR
  
  @RiedleroD 2y
  
  my god I'm going to read all that… tomorrow.
  
  @mekosko 2y
  
  > it just executes a bunch of (shell) scripts from a directory in alphabetical order and it's users responsibility to order them correctly and all that Thats why systemd rocks
  
  @CcxCZ 2y
  
  You're comparing it to rc system literally from 1980s. Of course proper dependencies have been a feature of every major reimplementation.
  
  @mekosko 2y
  
  It's enough that these are fucking shell scripts
  
  @SamsonovAnton 2y
  
  Well, in the Linux distro I'm currently using (home-brew LFS), init, service and other relevant utilities provided by sysvinit package, and /etc/init.d and /etc/rc.d base scripts are provided by lfs-bootscripts package. How would you call that?
  
  @RiedleroD 2y
  
  > reaping children 👀 that's one letter away from disaster
  
  @kitbot256 2y
  
  it is job security. Having an expertise in a field that makes you unique, so you won't get fired.
Felix 2y

i read it like "everybody can do cronjobs, systemd will keep me relevant"
@ygerlach 2y

You can deploy systemd timers as part of a debian package
@RiedleroD 2y

I mean, systemd gives you logging for free
@zaphod357 2y

systemd-list-timers brings clarity that cron never had Plus, you can test without having to mess with your config
@zaphod357 2y

And disable from the command-line
@CcxCZ 2y

I prefer running https://git.vuxu.org/snooze/about/ under s6.
@callofvoid0 2y

I still don't get it

Use J and K for navigation

Systemd Timers vs. Cron: A Job Security Play

Description

Categories

Comments

Related Memes

Production Stack Traces Chase Dev

On-Call Alert? It Can Wait Until Office Hours

It's Push to Prod Friday: Hand on the Detonator