Why would you bother with this when you have systemd-timers with times in English?
Well, for one thing, here are 4 completely new concepts that I don’t particularly want to bother with.
I just want to run a command every minute. I don’t want to learn about unit, timer or event files and the differences between them.
Sure, you have to learn the system's particulars and both systems have corner cases that seem to pop up in even the simplest of uses
...however, cronjobs are a single entry in a single application. Systemd is a system backbone. Using it for everything when you know how to use it is straightforward. Almost no one knows how to use it.
Not as many people know how to use it because they keep hearing this bashing.
But for a beginner systemd is quite accessible (if you don’t come at it with init.d baggage), and its advanced features almost always end up being relevant for its basic tasks.
I had to figure it out from scratch on a server running live, and I’m alive to tell the tale.
hahahaha good joke, right? I'm not really arguing that systemd is too complex but more so nitpicking your use of 'beginner'. If you believe systemd is accessible to a beginner...we're working from 2 very different pictures of what a novice computer user or even a novice programmer is capable of.
Crontab is an application installed by default on most linux flavors and has a multi-decade history of simplistic and complex usecases.
Systemd is the building blocks of the entire operating system. How in the world is that beginner accessible?
Do you want to setup a daemon that starts when a specific network interface is online? This is infinitely easier in systemd.
Defining a unit file (a daemon) is a matter of a trivial definition file and a couple of commands, can’t get more accessible than that. We’re still talking Linux distro users, not your run of the mill consumer of course.
Do you want to master using all features that systemd has to offer? There’s obviously a learning curve.
I’m not arguing in favor of systemd _over_ crontab, but there’s no need to bash on systemd which is a perfectly fine piece of software that does what it says (whether it does too much is a different topic).
Cron expressions are used in many software components way beyond cron daemons.
Another systemd "change for change's sake" argument.
I would set up a service for something that needs to be more robust and complex.
If not, I think your comment is pretty irrelevant since there are still scenarios where you'd need to use cron.
I can use them as a user and non-root, I get to use journalctl and systemd status to check if it ran. The timers run independently of others and the timers are in English.
If you are using Devuan or something weird like that then sure, but nearly every other way I find systemd-timers better especially for debugability.
And Debian isn't exactly "weird".
https://www.debian.org/News/2015/20150426
So since April 25th, 2015.
The logic went, we didn't like PulseAudio, therefore we don't like the developer (Lennart Poettering). Lennart Poettering also made SystemD, therefore we automatically hate that. The main complaint was that it relied on DBUS.
Most of them switched to Gentoo because it supported OpenRC, ironically also reliant on DBUS.
EDIT: I found some additional strange results when trying to find the spelling of his name:
https://www.zdnet.com/article/lennart-poetterings-linus-torv...
https://bannedhipster.home.blog/2020/10/28/meet-your-nsa-han...
https://groups.google.com/g/comp.misc/c/wnFJ3-QDKdE
Looks like they believe SystemD is an attempt by the NSA to infiltrate and spy on Linux users.
> The sysvinit init system is still available in "Jessie".
I was asking if this had since changed, since last I'd paid attention you could in fact run Debian without systemd.
https://lwn.net/Articles/585319/ https://www.itwire.com/open-source/debian-revisits-systemd-v...
So, I guess I assumed that since there was hysteria around systemd becoming the default and the non-systemd users needing to create a new fork (Devuan) to get SystemD out of their Debian installs, it might have been to be compatible with other software:
https://www.devuan.org/os/announce/
"As many of you might know already, the Init GR Debian vote promoted by Ian Jackson wasn't useful to protect Debian's legacy and its users from the systemd avalanche.
This situation prospects a lock in systemd dependencies which is de-facto threatening freedom of development and has serious consequences for Debian, its upstream and its downstream."
Choice 2:B is also the "new" decision to expand and allow exploring alternatives to SystemD in 2019, which is a change I was unaware of as well:
https://lwn.net/Articles/804254/ https://www.debian.org/vote/2019/vote_002#textb
I'm sure this won't satisfy you, but I'm done. I've followed this for far too long as it is, and I don't need to rehash more dumb mailing list arguments.
Not at all, although if you have any services that use dbus it might get started by one of them. On my system there isn't even a dbus service file that could be used to start dbus directly through OpenRC. OpenRC works fine without any dbus installed, in fact I'm not even sure if it's even used for any functionality at all. Service control is done through a socket in /var/run/openrc/control (or something), at least on any system configuration I've seen.
Without systemd, you "need" elogind as a requirement which is a drop in replacement for systemd-logind. elogind relies on dbus, and in Gentoo needs to contact /run/dbus/system_bus_socket.
However, looking into it, it appears this is largely because of display manager compatibility. If you don't need a display manager, you very well might not need elogind, which means you might not need dbus. So OpenRC for embedded, deciding to manually control execution of your WM with Wayland or X11, or headless servers could still work, but you would need dbus to get display managers to work. I've been reading some blogs of people attempting to do exactly this and they seem to only get into issues with Gentoo and Debian without using elogind or systemd. That doesn't mean it's "required", though, they could just not know what they are doing.
When I was installing Gentoo I was using stage3 of hardened-selinux-openrc, I also had a huge issue enabling SELinux and it kept blocking OpenRC's access to DBus before finishing the boot sequence. I assume this was due to the elogind USE flag, but it seems it had compiled into it somehow, because I didn't initially have elogind turned on. I guess I just didn't know the relationship of elogind and OpenRC (not that this has made anything any clearer), I might actually try rebuilding that system's @world without the "elogind" USE flag just to see what happens (I don't really need a display manager anyway).
Yes, that's how I do it. At boot a service auto-logins on all vts and fires up an X server with my WM. Since I already have to enter a password to decrypt the disk this is OK. After half an hour idle/suspend the screen gets locked, so it's not worse than no auto-login.
Sadly, the documentation and wiki has detoriated in quality the last few years. For example I recently tried to look up how to run Xorg without suid, but the wiki had removed the simpler input-group based method in favor of this elogind stuff, which I consider to be worse than useless. Luckily the talk page pointed me in the right direction (history).
Personally, I put -* in make.conf's USE variable and only enable a few things I really want universally like threads, unicode, etc. Then I use flaggie to enable the flags I need when installing stuff. I check with emerge -a to get a list of everything with the possible flags, then enable/disable as necessary. Takes a bit longer the first time, but prevents stuff like this. Sometimes it can break stuff since that's not a supported configuration and might expose undeclared USE flag dependencies, but it's mostly OK.
Technically yes, but I expect that Illumos is more relevant
That comment rubs me the wrong way. To mirror the sibling, there's a lot outside the Linux+SystemD world - even your firewall probably doesn't use systemd (or linux for that matter, if you're in a professional environment), and neither does Alpine, that runs docker containers. (And love it or hate it, docker is in a lot of commercial production stuff.)
"There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy."
B) I do control my (professional environment) firewall. OpenBSD+PF is an amazing firewall combo, and the other common firewall, pfsense, uses FreeBSD. Neither use Linux; neither use systemd.
A bit error prone perhaps, but that is why you have crontab.guru.