systemd's Growth Over 2022

[sinepgib]

Also you argue that it's a 'standard .service unit'. Well for people who manage systems that's true, but some users hire other people to manage systems, and they just use the machines. Now they are forced to wrap their heads around systemd

I don't understand your point here. Who's scratching their head? The hired sysadmin or the user who's paying for one anyway?

search forever trying to look up what the right service type is, or even the name of the man page that will explain the information.

Which is much easier to do thanks to cohesion than guessing which daemon you need and learning its custom config syntax.

just because systemd is more capable, that doesn't mean that dumping complexity on the end user is somehow necessary or a good thing.

Are you seriously calling .ini files more complex for an end user than "lol use bash and cross your fingers"?
Honestly, cron was obviously optimized for simplicity of implementation, not ease of (correct) use. There's a lot of responsibility put in the user that simply isn't there with timers.

and I really don't mind the timer scheme, I'm just saying the experience is overly cumbersome, and because it is, I expect that it will get replaced with something more convenient over time.

I wouldn't mind something more convenient. I can't really think of something, but it's always welcome. Thing is, neither cron nor its acolytes are in any way more convenient in my experience. Something else might be.

[Berniyh]

Well that's not really true, cron worked for a long time, and most users were okay with the edge cases.

Sorry, but that really isn't an argument.
Just because people always did something in a certain way does not mean that it should be done like this or even is a good idea.

Also you argue that it's a 'standard .service unit'. Well for people who manage systems that's true, but some users hire other people to manage systems, and they just use the machines. Now they are forced to wrap their heads around systemd, search forever trying to look up what the right service type is, or even the name of the man page that will explain the information. just because systemd is more capable, that doesn't mean that dumping complexity on the end user is somehow necessary or a good thing. and I really don't mind the timer scheme, I'm just saying the experience is overly cumbersome, and because it is, I expect that it will get replaced with something more convenient over time.

It's not that complicated (mainly referring to systemd units in general, I don't think timers are that different) and actually with a simple search on your favorite search provider you'll find many tutorials explaining very clearly what needs to be done.
e.g. https://wiki.archlinux.org/title/Systemd/Timers

Personally, I've never actively used cron (nor systemd timers). So inspired by this discussion (which honestly surprised me) I had a look at both and I found crontab very weird, tbh. I had to look at the manpage, but even with that it takes a long time to figure out what it is trying to tell me, especially because the formats of the fields are pretty weird as well.
systemd timers on the other hand have a relatively descriptive syntax, so by just looking at a timer unit, I was instantly able to figure out what it'll do.

Now, as I've said, I don't really use either one, so I'm surely not an expert. But from an outsider's perspective, I can't really understand your claim that cron is easier.
Maybe if you've worked for 20 years with it, but that is very subjective. Also, it would be the same if you've worked with systemd timers for 20 years.

[ll1025]

i understand that you really want to insult me,

I really don't, I think you are inexperienced with this aspect of systemd and that doesn't make you bad at computers but it does mean you should temper your criticism.

Your defense of the twenty extra steps that systemd timer launched services have over crontab is that it's necessary.

Systemd timers are not that many more steps than crontab, and involve a lot less error.

One can just look at questions and answers on stackexchange to see how ridiculous the format is in its utter esotericity.

Are systemd service unit files wordy? Sure. That's generally a good thing in computers, because layers of abstraction allow us to focus on the important things. Cron files make you think long and hard about how to translate your "I want this to run every second tuesday of the month" into a string of numbers, and then berates you if you make a mistake that causes it to run only in February because obviously it's your fault for misplacing a digit.

Just compare these two; consider what a newbie day-job Windows admin would make of cron vs systemd timers:

0 8 * * 3

OnCalendar=Wed 08:00

Also you argue that it's a 'standard .service unit'. Well for people who manage systems that's true, but some users hire other people to manage systems, and they just use the machines. Now they are forced to wrap their heads around systemd,

You're getting access to cron on a systemd system but you don't understand systemd?

I don't know what to tell you other than-- no offense, but your inability to administer the single most common service / init system in use today is you on you.

search forever trying to look up what the right service type is, or even the name of the man page that will explain the information.

Here you go. It's a systemd unit file, so it would be systemd.unit.

just because systemd is more capable, that doesn't mean that dumping complexity on the end user is somehow necessary or a good thing.

There is a difference between verbosity and complexity. Assembly and cron are both more terse, and more complex than their alternatives. Systemd timers are way more verbose, but its also trivial for a neophyte to look at the timer file and understand when it will execute and what it will execute. Trying to do many things in cron devolves into incredibly complex logic-- for instance, patching (alongside the windows fleet) every second tuesday of the month with cron would involve cron calling a script that then has to implement a date check internally, and hopefully there are no bugs in your bespoke script.

Systemd timers let you just specify something like,

# Execute on Tuesdays if it's between the 8th and 14th of the month
OnCalendar=Tue *-*-8..14 20:00

[Berniyh]

Well, regarding the man pages, he does have a point. systemd ships over a thousand man pages.
Ok, many of those are actually documentation of APIs etc., but even those in sections 1, 5 and 8 that are more relevant to admins/users are clustered into over 250 man pages.
But that's not only a problem with systemd, in general the man page system is a horrible artifact of the early times of computers.
Don't get me wrong, it's still nice to have them around for the special circumstances (no network, no GUI etc.), but 99.999% of the time it's a UI that is just annoying in times were we have much better possibilities.
And don't come and tell me about info, which is just as bad as man. (Actually systemd doesn't provide info pages.)
In case of systemd, every page should, at the top, have something like "You can use nicely formatted documentation at https://...", that would help a lot if it were actually nicely formatted.

It also doesn't help that if you're search just for systemd, you'll find https://systemd.io and that page clearly is not targeted towards admins and users, but towards developers and distributors. This is made worse by the fact that this isn't even pointed out on the home page, so I suspect that as a user, you'll arrive at this page, spend about 5-10 minutes trying to find the information for users, just to realize that it isn't really there. All that you'll find is the link to the online version of the man pages, but as I said the man page format is horrible and the information is heavily clustered.
Surely, you can find a lot of help by just searching for stuff, but you also have to admit, that – from a user perspective – the systemd documentation really isn't great.
They could significantly improve there and it would be really helpful.

[sinepgib]

Well, regarding the man pages, he does have a point. systemd ships over a thousand man pages.
Ok, many of those are actually documentation of APIs etc., but even those in sections 1, 5 and 8 that are more relevant to admins/users are clustered into over 250 man pages.
But that's not only a problem with systemd, in general the man page system is a horrible artifact of the early times of computers.
Don't get me wrong, it's still nice to have them around for the special circumstances (no network, no GUI etc.), but 99.999% of the time it's a UI that is just annoying in times were we have much better possibilities.
And don't come and tell me about info, which is just as bad as man. (Actually systemd doesn't provide info pages.)
In case of systemd, every page should, at the top, have something like "You can use nicely formatted documentation at https://...", that would help a lot if it were actually nicely formatted.

It also doesn't help that if you're search just for systemd, you'll find https://systemd.io and that page clearly is not targeted towards admins and users, but towards developers and distributors. This is made worse by the fact that this isn't even pointed out on the home page, so I suspect that as a user, you'll arrive at this page, spend about 5-10 minutes trying to find the information for users, just to realize that it isn't really there. All that you'll find is the link to the online version of the man pages, but as I said the man page format is horrible and the information is heavily clustered.
Surely, you can find a lot of help by just searching for stuff, but you also have to admit, that – from a user perspective – the systemd documentation really isn't great.
They could significantly improve there and it would be really helpful.

While I agree appealing to a wider public would be a feature, I find man pages convenient actually. I never got around understanding info pages tho.
Besides, I would compare those numbers to what they actually cover: a given daemon for random functionality in The Old Ways (TM) Unixes tend to have three or more pages. If you get a more integrated solution it is to be expected to have a similar number per functionality.

[fitzie]

Sorry, but that really isn't an argument.
Just because people always did something in a certain way does not mean that it should be done like this or even is a good idea.

It's not that complicated (mainly referring to systemd units in general, I don't think timers are that different) and actually with a simple search on your favorite search provider you'll find many tutorials explaining very clearly what needs to be done.
e.g. https://wiki.archlinux.org/title/Systemd/Timers

Personally, I've never actively used cron (nor systemd timers). So inspired by this discussion (which honestly surprised me) I had a look at both and I found crontab very weird, tbh. I had to look at the manpage, but even with that it takes a long time to figure out what it is trying to tell me, especially because the formats of the fields are pretty weird as well.
systemd timers on the other hand have a relatively descriptive syntax, so by just looking at a timer unit, I was instantly able to figure out what it'll do.

Now, as I've said, I don't really use either one, so I'm surely not an expert. But from an outsider's perspective, I can't really understand your claim that cron is easier.
Maybe if you've worked for 20 years with it, but that is very subjective. Also, it would be the same if you've worked with systemd timers for 20 years.

cron absolutely is quirkly, but the reason why it is easier is you run a command, it brings up an editor, you add the shell command you want with a time spec format, which is quite similar to the systemd OnCalendar construct, and then save the file and it is in place, and will email you the output of the command. i'm not saying there's some sort of grand flaw in systemd's approach, but i think could do a lot to assist users using their tools. systemd takes a packagers view of the world, and they could spend some more time thinking about the users.

[fitzie]

I really don't, I think you are inexperienced with this aspect of systemd and that doesn't make you bad at computers but it does mean you should temper your criticism.


Systemd timers are not that many more steps than crontab, and involve a lot less error.

One can just look at questions and answers on stackexchange to see how ridiculous the format is in its utter esotericity.

Are systemd service unit files wordy? Sure. That's generally a good thing in computers, because layers of abstraction allow us to focus on the important things. Cron files make you think long and hard about how to translate your "I want this to run every second tuesday of the month" into a string of numbers, and then berates you if you make a mistake that causes it to run only in February because obviously it's your fault for misplacing a digit.

Just compare these two; consider what a newbie day-job Windows admin would make of cron vs systemd timers:

0 8 * * 3

OnCalendar=Wed 08:00

You're getting access to cron on a systemd system but you don't understand systemd?

I don't know what to tell you other than-- no offense, but your inability to administer the single most common service / init system in use today is you on you.



Here you go. It's a systemd unit file, so it would be systemd.unit.


There is a difference between verbosity and complexity. Assembly and cron are both more terse, and more complex than their alternatives. Systemd timers are way more verbose, but its also trivial for a neophyte to look at the timer file and understand when it will execute and what it will execute. Trying to do many things in cron devolves into incredibly complex logic-- for instance, patching (alongside the windows fleet) every second tuesday of the month with cron would involve cron calling a script that then has to implement a date check internally, and hopefully there are no bugs in your bespoke script.

Systemd timers let you just specify something like,

# Execute on Tuesdays if it's between the 8th and 14th of the month
OnCalendar=Tue *-*-8..14 20:00

the thing I don't understand is why do you think I'm incapable of using systemd? did I at any point say I didn't understand how to setup timers? In fact I described the process as creating two files, placing them in the right directory and then running the a series of commands to activate/test them. Is it because I think systemd timers are a hassle to use when a simple cron job will suffice? All the bells and whistles and correctness in systemd is grand, but for cron the user just has to understand a small timespec, one command with crazy -e for edit and -l for list options, and then they are good to go. next you are going to tell me how dangerous crontab -r is, right? that I actually agree with ( i have a cronjob to back up my crontab). I'm not saying cron is perfect and I actively discourage its use in various contexts. but i will continue to use it for convince's sake, and I hope one day systemd is replaced (or improved) with something as convenient.

[Berniyh]

While I agree appealing to a wider public would be a feature, I find man pages convenient actually. I never got around understanding info pages tho.
Besides, I would compare those numbers to what they actually cover: a given daemon for random functionality in The Old Ways (TM) Unixes tend to have three or more pages. If you get a more integrated solution it is to be expected to have a similar number per functionality.

Of course if there is a lot of functionality, the documentation will be large, too. And I'm not saying they should cram it all into one man page.
(Which is e.g. something that zsh does with zshall, because the split zsh man pages are horrible. How am I – as a user – supposed to know in which man page to look?)
The thing is that man pages are just not a concept to cram huge amount of documentation into. It just does not provide a good work flow.
I also don't know what the point is of having man pages about the interfaces. Nobody in their right mind would – when developing a program with e.g. journald support – look at the man pages instead of some nicer formatted html documentation.

man pages do a good job of explaining the basic functionality in extend to the --help out, but if you stuff too much stuff into them, it just get's confusing and tedious.
e.g. the man page for a systemd service should say something like:
A complete guide can be found under https:// ....
Here is some of the typical verbs that you would use in a service
....

And here are a few examples
....
End

[Berniyh]

cron absolutely is quirkly, but the reason why it is easier is you run a command, it brings up an editor, you add the shell command you want with a time spec format, which is quite similar to the systemd OnCalendar construct, and then save the file and it is in place, and will email you the output of the command. i'm not saying there's some sort of grand flaw in systemd's approach, but i think could do a lot to assist users using their tools. systemd takes a packagers view of the world, and they could spend some more time thinking about the users.

When I look at crontab, I want to get the hell out of there, it's just a very weird format.
Luckily I can live without it.

btw, in my opinion, one of the most important features of systemd is that you can define stuff at a --user level. That's not possible with traditional Linux services (which I think also includes cron).
Hence, I can define e.g. a systemd timer that cleans out my ~/.cache/foo directory if it takes up more than X GB of data and I don't have to have superuser privileges for that.
As an admin, I can also provide such a timer that is off by default but the user can activate if he wants to (possibly via a gui).
Using crontab, you can of course run stuff as a specific user, but you still ne su privileges to define that.

Overall, the --user functionality of systemd has improved so many things in the last years. It improved the KDE Plasma startup (at least on my end), I can now reliably start mpd or similar programs during login (which previously kind of worked, but failed for unknown reasons about 5-10% of the time).
It's much easier to switch on/off pulseaudio or pipewire(-pulse), since all you have to do is start/stop the respective --user services (previously pulseaudio would instantly come up again being activated by dbus or something like that).
The timers also fit nicely into that new type of workflow.

[sinepgib]

btw, in my opinion, one of the most important features of systemd is that you can define stuff at a --user level. That's not possible with traditional Linux services (which I think also includes cron).
Hence, I can define e.g. a systemd timer that cleans out my ~/.cache/foo directory if it takes up more than X GB of data and I don't have to have superuser privileges for that.
As an admin, I can also provide such a timer that is off by default but the user can activate if he wants to (possibly via a gui).
Using crontab, you can of course run stuff as a specific user, but you still ne su privileges to define that.

AFAICT nothing stops you from having your own cron running as your user that will run commands as your user. The thing limiting you there is not traditional services but sysvinit. If you use runit or s6 you fire your own supervision tree under your user that manages services in a manner quite similar to systemd --user.

I still find cron jobs untestable, but being unable to run in a user session is (I think) not one of its many issues.