There’s also a few cases of feature and scope creep, including the infamous systemd-resolved.
Systemd, your job is to launch services, manage logs, and do timers and relaunches on a service crash. DNS is out of scope, leave that to existing services.
You’ve misunderstood something.
systemd-resolved is one of the services that uses systemd’s service management system
You’re saying “don’t use this service management system to manage your services”
I agree, though my biggest headache has been with systemd handling mounts. You have to modify a ton of units to add After and Required to make sure the NFS shares you have in fstab get mounted before starting services that depend on them. And then if the package maintainer updates their unit files, all your changes disappear!
Such a huge headache compared to the classic init.d that mounted everything very early – with just the occasional “boot delayed a couple seconds because your share was offline” or such.
There’s also a few cases of feature and scope creep, including the infamous
systemd-resolved.Systemd, your job is to launch services, manage logs, and do timers and relaunches on a service crash. DNS is out of scope, leave that to existing services.
resolved is entirely optional and disabled by default, I use it on case of non-mobile devices but leave it on laptops etc.
DNS resolution isn’t something exotic, it makes sense for systemd to implement it in a simple optional daemon
You’ve misunderstood something.
systemd-resolved is one of the services that uses systemd’s service management system
You’re saying “don’t use this service management system to manage your services”
I may have written that in a confusing way. I’m saying systemd’s job is service management. Systemd-resolved is an unnecessary bit of scope creep.
systemd-resolved is a service. It’s not scope-creep. It’s its own thing built in the systemd framework.
I agree, though my biggest headache has been with systemd handling mounts. You have to modify a ton of units to add
AfterandRequiredto make sure the NFS shares you have in fstab get mounted before starting services that depend on them. And then if the package maintainer updates their unit files, all your changes disappear!Such a huge headache compared to the classic init.d that mounted everything very early – with just the occasional “boot delayed a couple seconds because your share was offline” or such.
You’re not supposed to modify shipped unit files, that’s why systemd supports drop in snippets