Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Poettering: The Biggest Myths
Posted Jan 28, 2013 12:02 UTC (Mon) by davidstrauss (subscriber, #85867)
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 .
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 .
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?
Posted Jan 28, 2013 12:20 UTC (Mon) by davidstrauss (subscriber, #85867)
Posted Jan 28, 2013 12:25 UTC (Mon) by pbonzini (subscriber, #60935)
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.
Posted Jan 28, 2013 12:38 UTC (Mon) by davidstrauss (subscriber, #85867)
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.
Posted Jan 28, 2013 12:49 UTC (Mon) by davidstrauss (subscriber, #85867)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds