3 ms·

I mostly like systemd. I definitely like writing unit files a heck of a lot more than writing shell scripts; it's really easy to write bad shell, and we didn't

I mostly like systemd. I definitely like writing unit files a heck of a lot more than writing shell scripts; it's really easy to write bad shell, and we didn't have shellcheck to help us out back in the old days. The parts that I don't like, I don't use - it's really more of a monorepo than a monolith. That being said, I really wish there was more interest from the systemd folks in interoperating with containers and registries and all things OCI in general. Like the portable services they introduced in 239, the storage for the system extensions introduced in 248 is backed by either a directory or a disk image; meanwhile, there's an entire ecosystem of tools in the container world dedicated to the storage and distribution of root filesystems that they seem to be completely ignoring. I know there's nothing stopping me from using `umoci` or some such to pull and unpack a container and use the resulting directory as either a system extension or a source of portable services, but it'd be a lot cooler if that kind of functionality was baked in.

guenthert 6y ago
> 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.

guenthert 6y ago

> 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.