User: Password:
|
|
Subscribe / Log in / New account

Poettering: The Biggest Myths

Poettering: The Biggest Myths

Posted Jan 28, 2013 10:49 UTC (Mon) by pbonzini (subscriber, #60935)
In reply to: Poettering: The Biggest Myths by hazard
Parent article: Poettering: The Biggest Myths

> Unfortunately this is not the case and systemd designers preferred to throw out anything that reminds of SysV boot process. People like me simply don't understand why they have to spend hours learning new system when the old one wasn't "broken enough" for them. Once RHEL7 comes out, they'd just plainly reject it and look for a CentOS fork that keeps SysV in.

That's called RHEL6. It will be supported for several years after RHEL7 comes out.


(Log in to post comments)

Poettering: The Biggest Myths

Posted Jan 28, 2013 10:58 UTC (Mon) by dlang (subscriber, #313) [Link]

so you want to encourage people to not upgrade to RHEL7??!?!

just being techincally better (assuming systemd is), isn't enough to drive people to switch to something different.

If it was there wouldn't be nearly as many peole using Windows :-)

but even in the *nix space, look at syslog. For many years syslog-ng was out there and nobody disputed that it was a better syslog daemon than what everyone was using, but for the majority of the people plain syslog wasn't 'broken' enough for them to be willing to take on the load of learning a completely different config syntax.

rsyslog displaced sysklog very rapidly in part because it didn't force people who didn't want to use the new features to learn new ways of doing the same thing (and those wanting to do something different were willing to learn how)

I know people keep repeating how systemd doesn't force you to change, you can still use init scripts, but that's not how it's being used and setup in the distros using it so far.

Poettering: The Biggest Myths

Posted Jan 28, 2013 11:15 UTC (Mon) by pbonzini (subscriber, #60935) [Link]

> so you want to encourage people to not upgrade to RHEL7??!?!

Absolutely not, just pointing out the obvious: it's not like RHEL7's release will represent a flag day for everyone using RHEL. Not for systemd, not for anything else.

Of course the RHEL7 documentation will cover systemd, but even the training material covering systemd for RHCSA and RHCE courses will likely come out a few months later (at least that was the case for RHEL6).

> I know people keep repeating how systemd doesn't force you to change, you can still use init scripts, but that's not how it's being used and setup in the distros using it so far.

I agree, and that's why a "RHEL7 without systemd" fork just cannot exist.

Poettering: The Biggest Myths

Posted Jan 28, 2013 17:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

I looked at syslog-ng a couple of times, and while it's better, it's not that MUCH better. There are no "killer features" for me there, so I just don't bother.

Poettering: The Biggest Myths

Posted Jan 28, 2013 21:27 UTC (Mon) by dlang (subscriber, #313) [Link]

> There are no "killer features" for me there, so I just don't bother.

That is my exact point.

'killer features' for me

with syslog-ng there were a LOT of features that were absolutly killer for people who needed them, but it turns out that the vast majority of people were happy with what they had, and so the pain of having to change how everything currently worked in order to get new features that they didn't care about was enough to prevent just about any distro from switching to syslog-ng as the default syslog

along comes rsyslog, and while it's config files have some 'new, strange' stuff up at the beginning, the main part of the config files looks just like classic syslog, and it's maintained. Within a year, just about every distro switched to using rsyslog as the default, and it didn't bother anyone because their configs either 'just worked' (if they were included), or were dead trivial to adapt.

Now, several years later, there is a significant uptick in the number of people doing things with rsyslog that could never have been done with sysklog (but that could have been done with syslog-ng), in part because the transition was evolutionary, with full support (not just in theory, but in practice by the distros) for using the old style configs.

Poettering: The Biggest Myths

Posted Jan 28, 2013 11:19 UTC (Mon) by davidstrauss (subscriber, #85867) [Link]

> That's called RHEL6. It will be supported for several years after RHEL7 comes out.

RHEL6 runs Upstart, not SysV init.

Poettering: The Biggest Myths

Posted Jan 28, 2013 11:21 UTC (Mon) by pbonzini (subscriber, #60935) [Link]

When people mean sysvinit usually they only care about /etc/rc.d.

Poettering: The Biggest Myths

Posted Jan 28, 2013 12:02 UTC (Mon) by davidstrauss (subscriber, #85867) [Link]

> 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
[2] http://docs.fedoraproject.org/en-US/Fedora/16/html/System...

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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds