6 ms·

Systemd isn't one component, so you'd be mistaken assuming everything in the systemd project is necessary to start a service. But second to that, I'm not sure w

by pmden 8y ago

Systemd isn't one component, so you'd be mistaken assuming everything in the systemd project is necessary to start a service. But second to that, I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. As for why someone would make that 'trade-off' - I much prefer being able to add "Restart=on-failure" than using daemontools, and I don't have the luxury of working with one single distribution and remember the faff involved with initscripts differing between CentOS and Debian. My reasons aside, I'd think a more sensible question would be "why would you actively avoid using the init system that's shipping by default on what constitutes at least 90% of the Linux server market when you're using Linux?". I don't think eyes equate to quality and stability, but I do think Red Hat, and SUSE, and Canonical and Oracle selling server solutions using it will.

dozzie 8y ago
> I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. My guess: because the "another application" that parses nginx_enable=YES is a (rc) shell script instead of an ELF blob, so you can track its execution.
- andrewshadura 8y ago
  But do you need to?
  - dozzie 8y ago
    Yes, when something goes awry with the initscripts system. And systemd is not exactly famous for its transparency of execution and stability of options' behaviour.
- JdeBP 8y ago
  That is not actually true. It is of course parsed by a shell, not by a shell script, which is indeed an "ELF blob". Moreover, that shell is, on some operating systems, only one of the parsers. OpenBSD, for example, introduced a rule a few versions ago that rc.conf is not shell script. It is a set of key=value assignments that can be written and read by other programs too, not just by a full shell parser and not requiring a shell script parser. One such program is rcctl. Another is FreeBSD's sysrc.
alxlaz 8y ago
> But second to that, I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. That's true of both plain-text configuration files and Windows Registry keys ;-).

by pmden 8y ago

dozzie 8y ago

> I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. My guess: because the "another application" that parses nginx_enable=YES is a (rc) shell script instead of an ELF blob, so you can track its execution.

andrewshadura 8y ago
But do you need to?
- dozzie 8y ago
  Yes, when something goes awry with the initscripts system. And systemd is not exactly famous for its transparency of execution and stability of options' behaviour.
JdeBP 8y ago
That is not actually true. It is of course parsed by a shell, not by a shell script, which is indeed an "ELF blob". Moreover, that shell is, on some operating systems, only one of the parsers. OpenBSD, for example, introduced a rule a few versions ago that rc.conf is not shell script. It is a set of key=value assignments that can be written and read by other programs too, not just by a full shell parser and not requiring a shell script parser. One such program is rcctl. Another is FreeBSD's sysrc.

alxlaz 8y ago

> But second to that, I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. That's true of both plain-text configuration files and Windows Registry keys ;-).