| |||||||||||||
Poettering: The Biggest MythsPoettering: The Biggest MythsPosted Jan 28, 2013 12:02 UTC (Mon) by davidstrauss (subscriber, #85867)In reply to: Poettering: The Biggest Myths by pbonzini Parent article: Poettering: The Biggest Myths
> When people mean sysvinit usually they only care about /etc/rc.d.
You'll have to clarify which people you're referring to. Without knowing, I have to assume you're just speaking for yourself.
In any case, let's review the rule you've proposed for for what qualifies as "SysV init" (or, really, what's more accommodating to long-time SysV init users).
== Upstart ==
Upstart is "SysV init" because it allows rc.d for traditional init scripts. Unfortunately, it lacks first-class support for the SysV init scripts themselves. By "first-class," I mean where administrators can control the SysV services using normal Upstart commands and have the services participate in dependencies trees with other services. This is not possible on an Upstart machine [1].
Upstart's rc.d support does not extend to native Upstart services. There's not even an equivalent of enabling and disabling configured services in Upstart. You could use symlinks from /etc/init, but it wouldn't be a standard approach supported by any CLI tools or configuration management utilities like Puppet or Chef.
Adapting a SysV init-based service to run as a first-class citizen on an Upstart machine requires complete conversion to a native Upstart service. Once that's done, the service is simply always enabled (because of the aforementioned lack of rc.d or equivalent for native services).
== systemd ==
systemd is apparently *not* "SysV init" because it lacks rc.d. However, is does have first-class support for /etc/init.d scripts, including support for native systemd service management commands, integration into dependency trees with other services, and automatic mapping of the LSB runlevels to the systemd equivalents [2].
While systemd lacks rc.d support, it has a superset of the rc.d/runlevel capability with named targets. And, as long as the administrator has been using chkconfig (or equivalent) to enable or disable services, there's no change in the commands to enable or disable services -- whether systemd native or SysV-based.
So, which one is really more of a departure for long-time SysV init administrators?
[1] http://askubuntu.com/a/14823
(Log in to post comments)
Poettering: The Biggest Myths Posted Jan 28, 2013 12:20 UTC (Mon) by davidstrauss (subscriber, #85867) [Link]
One correction: Upstart apparently now has support to disable native services. But, it's not via rc.d and it doesn't support disabling SysV init-style services the same way as the new method for native services.
Poettering: The Biggest Myths Posted Jan 28, 2013 12:25 UTC (Mon) by pbonzini (subscriber, #60935) [Link]
> You'll have to clarify which people you're referring to. Without knowing, I have to assume you're just speaking for yourself.
For example the guy that started this thread (http://lwn.net/Articles/534260/). In general most of the practical complaints I heard about systemd (i.e. not "oh but the Unix way") are about /etc/rc.d.
For upstart, nobody did the work of converting most services to native, which is why you hear screams of horror for RHEL7's systemd but not for RHEL6's upstart. The transition was hardly visible.
FWIW, you're preaching to the choir. I like systemd.
Poettering: The Biggest Myths Posted Jan 28, 2013 12:38 UTC (Mon) by davidstrauss (subscriber, #85867) [Link]
> For example the guy that started this thread (http://lwn.net/Articles/534260/). In general most of the practical complaints I heard about systemd (i.e. not "oh but the Unix way") are about /etc/rc.d.
It's pretty arcane to go rooting around in rc.d when there are tools like chkconfig that have handled such needs for years. systemd still tracks which services are enabled for a target using symlinks, so it's no more or less "the Unix way" than rc.d.
> For upstart, nobody did the work of converting most services to native, which is why you hear screams of horror for RHEL7's systemd but not for RHEL6's upstart. The transition was hardly visible.
Upstart pretty much leaves the SysV init side of things alone and does its own thing. That has a low impact on administrators when you don't convert any of the services over, but it creates a schizophrenic mess once you have a mix. (It's actually alright with *only* native Upstart services, too.)
That's still pretty different from Upstart being more like SysV init or more accommodating to experienced SysV init users.
Poettering: The Biggest Myths Posted Jan 28, 2013 12:49 UTC (Mon) by davidstrauss (subscriber, #85867) [Link]
Looking back at the referenced post (regarding rc.d expectations) again, it seems that the author was actually looking at the init.d script rather than the enabled/disabled symlink structure, which is what I usually think of when someone mentions "rc.d." So, chkconfig obviously wouldn't handle what he was trying to do.
Oh well.
|
|||||||||||||