There’s also a few cases of feature and scope creep, including the infamous systemd-resolved.
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.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
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.