- cross-posted to:
- linux@kbin.social
- homelab
- selfhosted@lemmy.world
- cross-posted to:
- linux@kbin.social
- homelab
- selfhosted@lemmy.world
After a few conversations with people on Lemmy and other places it became clear to me that most aren’t aware of what it can do and how much more robust it is compared to the usual “jankiness” we’re used to.
In this article I highlight less known features and give out a few practice examples on how to leverage Systemd to remove tons of redundant packages and processes.
And yes, Systemd does containers. :)
The dependency system takes a bit to understand but compared to like upstart it was a massive improvement.
Everybody gangsta until
A start job is running for ... (10s / 1min 30s)
Or, even worse,
A start job is running for ... (10s / no limit)
lol, that brought back memories
I don’t see how exactly that is systemd’s fault.
You are blaming it for having proper dependency handling?
I’m blaming it for making it a pain in the ass to debug dependency problems and for having the confusing, non-intuitive, overly verbose and redundant syntax that probably caused the problem in the first place.
Like, who the hell can memorize all the subtle differences in behavior between
After=
,Requires=
,Wants=
,Requisite=
,BindsTo=
,PartOf=
,UpHolds=
and then all their “reverse” equivalents?You’re right that the difference isn’t overly obvious. However, for most services,
Wants=
is enough. I think some of these (likeRequisite=
) came from actual users’ demands where they had to solve corner cases in their setup that systemd did not allow with the existing features. I think especiallyUpheldBy=
is a smart addition; it adds restarting to a service only if that services is used as a dependency for the one it upholds.