3 ms·
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
by pfranz 6y ago
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 6y agoThe `service` command fixes problems with environment pollution, and the `start-stop-daemon` command makes init scripts easier to write.
- pfranz 6y agoOf 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.