2 ms·

> I definitely like writing unit files a heck of a lot more than writing shell scripts; No argument there (even though declarative programming languages aren't

> I definitely like writing unit files a heck of a lot more than writing shell scripts; No argument there (even though declarative programming languages aren't universally favored over imperative ones), but why does this come up so often? On a typical Linux desktop or server there are hundreds, if not thousands of packages installed, yet only a few dozen init scripts. Almost no tool or application is typically run as service requiring such.

zootboy 6y ago
Possibly it's because initscripts were such a painful experience that they weren't used as extensively. I find myself making systemd units often for small things that I wouldn't have wanted to write a whole initscript for. Just the dependency resolution features alone make it fantastic. It's only a few lines to specify a network dependency, a filesystem dependency, another service dependency, timeout and retry behaviors, monitoring and alerting on failures, etc. Plus it goes beyond just init. The scheduling features mean I'm turning to it instead of something like cron for doing repeated tasks on a server. Again, there's just a bunch of quality-of-life improvements there, like dependencies, better and more granular logging, error reporting, retries with limits, etc.
jordemort 6y ago
> Almost no tool or application is typically run as service requiring such. I build embedded systems and appliances; it sounds like you might have to deal with this a lot less frequently than I do. I don't have to deal with it as frequently in the age of systemd though, because more projects are providing unit files now that it's everywhere, and it's a lot easier to glance at a systemd unit someone else wrote and decide if it's correct than it is to audit a random shell script and figure out what needs to be added or changed to get it to work correctly in your distro of choice.
- guenthert 6y ago
  > it sounds like you might have to deal with this a lot less frequently than I do. That'll be the case. When I did work on an embedded system (enterprise storage system) different groups worked on different services (and some used hair-rising shell scripts to start their service), but our team's service was started via xinetd and we didn't spend all that much time on that aspect.

zootboy 6y ago

Possibly it's because initscripts were such a painful experience that they weren't used as extensively. I find myself making systemd units often for small things that I wouldn't have wanted to write a whole initscript for. Just the dependency resolution features alone make it fantastic. It's only a few lines to specify a network dependency, a filesystem dependency, another service dependency, timeout and retry behaviors, monitoring and alerting on failures, etc. Plus it goes beyond just init. The scheduling features mean I'm turning to it instead of something like cron for doing repeated tasks on a server. Again, there's just a bunch of quality-of-life improvements there, like dependencies, better and more granular logging, error reporting, retries with limits, etc.

jordemort 6y ago

> Almost no tool or application is typically run as service requiring such. I build embedded systems and appliances; it sounds like you might have to deal with this a lot less frequently than I do. I don't have to deal with it as frequently in the age of systemd though, because more projects are providing unit files now that it's everywhere, and it's a lot easier to glance at a systemd unit someone else wrote and decide if it's correct than it is to audit a random shell script and figure out what needs to be added or changed to get it to work correctly in your distro of choice.

guenthert 6y ago
> it sounds like you might have to deal with this a lot less frequently than I do. That'll be the case. When I did work on an embedded system (enterprise storage system) different groups worked on different services (and some used hair-rising shell scripts to start their service), but our team's service was started via xinetd and we didn't spend all that much time on that aspect.