[pfranz]

Over the years I've hit issues where the daemon using traditional init will inherit the environment it gets launched from. So on boot it works as expected, but if a user restarts the daemon it can get subtle behaviors because of that user's environment. For this reason I've been itching to adopt an event-based init for many years (Upstart, being event-based, also addressed this).

I've had frustrations with systemd, but the few times I've wanted to write an init script I was glad it was trivial instead of cobbling something together for traditional init.

[fanf2]

The `service` command fixes problems with environment pollution, and the `start-stop-daemon` command makes init scripts easier to write.

[pfranz]

Of course. The fixes weren't unique to systemd. Upstart addressed those issues too. The problem, either branding or adoption, is that after literally decades it hadn't been widely adopted on sysv-style systems. `/etc/rc.d/init.d/functions` was never ubiquitous enough that you could trust it existed. I've downloaded software that required it on platforms that didn't offer it and meant troubleshooting and rewriting when I should have been on to the next thing.

Maybe because they /could/ be run directly if/when service existed without warning or penalty, it also wasn't widely used.

In practice, I hit it many many times in sysv-style systems. I've used systemd systems for much less time but haven't hit a similar issue since transitioning.