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

Poettering: The Biggest Myths

Poettering: The Biggest Myths

Posted Jan 27, 2013 13:06 UTC (Sun) by hazard (guest, #3695)
In reply to: Poettering: The Biggest Myths by davidstrauss
Parent article: Poettering: The Biggest Myths

Hi,

Thanks for the well-argumented and informative response, appreciated.

> Your experience with SysV init seems to obscure its rougher edges to you. There's nothing obvious at all about SysV init in terms of the metadata-in-comments at the top of init scripts, run levels, rc.d, and the inconsistent suite of service-management utilities like update-rc.d and chkconfig. There's also the litany of executables invoked from within the init scripts like daemonize, start-stop-daemon, and runsv. Subtle errors in using these tools can open many security errors related to improper privilege dropping and inheriting too much of the admin's session.

You're right, with my 17-year experience, the internals and workarounds for particular flavors of SysV are very well known to me by now.

Actually, this is the core issue: systemd, as a complete replacement, makes all these years of experience obsolete and irrelevant. However, if we take commercial deployments, who is systemd's target audience? Existing sysadmins, who know SysV already.

If you force these people to learn something new, they would expect something intuitive and easy to understand based on their existing SysV experience. They would expect some "upgrade" based on the core SysV principles: they'd have to learn new things, but not start from scratch.

The way I see it, most of the new functionality could be implemented without a complete eradication of SysV concepts.

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.

Small real-life example: About a year ago, I was given a Fedora laptop. I needed to configure it so that a specific application automatically starts on tty1 after booting (in order to show measurement results on screen). Unfortunately IT techs didn't heed to my advice to use older Fedora and I got a new one with systemd in. I planned to perform this configuration in 5-10 minutes, based on my existing knowledge, but it took me close to one hour and numerous searches on Google to figure out how to do it. Moreover, I had to touch like 3-4 config files in order to implement it.

I definitely didn't feel that systemd made it more easy for me to perform this task, I just felt that systemd makes my years of experience with SysV irrelevant and we should be careful not to install systemd on production systems, since at least due to lack of knowledge it'll take our sysadmins much longer to troubleshoot.


(Log in to post comments)

Poettering: The Biggest Myths

Posted Jan 27, 2013 14:01 UTC (Sun) by niner (subscriber, #26151) [Link]

So your complaint is that it's different and you have to learn something new. Well if you don't like learning, you should look for a different job. If I complained loudly every time something I knew in technology became obsolete, noone would like to talk to me anymore, since all I'd do was complaining.

I would love to know, how you would implement systemd's features without departing significantly from SysV init. Especially systemd's ability to reliably kill a daemon and all it's child processes. This feature alone would make me switch to systemd immediately, since it makes cluster failover much more reliable. File systems can only be unmounted if all processes accessing them are killed. So we need reliable killing to unmount and switch the drbd node to secondary.

I will not for one second miss the whole "oh the daemon could not write it's PID file, but it started anyway and now the init script cannot stop it anymore" mess... Or the init script shows a green "done" but it didn't notice that apache died immediately afterwards.

systemd solves real problems for real users. It does so at the cost of and hour or two of learning how to use it versus the 17 years of experience one needed to get SysV based systems to run reliably.

Poettering: The Biggest Myths

Posted Jan 27, 2013 14:32 UTC (Sun) by hazard (guest, #3695) [Link]

> So your complaint is that it's different and you have to learn something new. Well if you don't like learning, you should look for a different job.

I expected that someone will appear and oversimplify my thoughts down to this.

There are reasons why Cisco keeps IOS syntax unchanged, why GUI apps keep using "floppy disk" icon to save files and why Linus insists to keep kernel's user-level API unchanged.

And these reasons are: to preserve compatibility and to preserve existing knowledge.

Try coming to any serious enterprise and tell them to switch all servers to Linux, just because "it's better". And if their IT responds that they don't know Linux, tell them that they should look for a different job if they don't like to learn.

Sorry, real life doesn't work this way. What people know DOES matter, what your existing customer base wants also DOES matter.

I may learn systemd; or I may as well switch to some other distro which listens to its user-base.

Poettering: The Biggest Myths

Posted Jan 27, 2013 14:50 UTC (Sun) by hazard (guest, #3695) [Link]

To make it clear, I never said that systemd doesn't bring improvements. systemd does offer numerous quite-nice-features.

However, in my opinion it was completely unnecessary to wipe out existing SysV principles in order to implement those quite-nice-features.

Actually it seems to me that the main reasons to throw SysV concepts out were to implement features which many users don't really care for, like use of targets instead of runlevels.

You can implement a daemon which would launch scripts from /etc/init.d/rcS.N and use /etc/inittab, you can introduce special functions in the scripts to support reliable service launch and PID capture, you can still have this daemon to listen for callbacks from the services to indicate succesful startup, catch service startup output in a structured log, etc. You can even provide OPTIONAL ability for parallel startup for those who want it, while keeping the traditional startup sequence by default.

Poettering: The Biggest Myths

Posted Jan 27, 2013 15:13 UTC (Sun) by niner (subscriber, #26151) [Link]

If you want, you _can_ still use systemd as if it was just a SysV implementation and have scripts in /etc/initd (or was it /etc/rc.d or /etc/init.d/rc.d on your distro?). I actually still use them (or rather the rc<daemonname> symlinks in /usr/sbin to them) out of habit. But most of them are nice and redirect to systemd to do what I mean.

"You can implement a daemon which would launch scripts from /etc/init.d/rcS.N and use /etc/inittab, you can introduce special functions in the scripts to support reliable service launch and PID capture, you can still have this daemon to listen for callbacks from the services to indicate succesful startup, catch service startup output in a structured log, etc."

In other words, one could create new infrastructure to support those features and rewrite every single init script to use it. Administrtors would have to learn a lot again about what new magical commands one would have to use to start a daemon.

But why not use this chance to go a little further and make another leap in usability and features? I still remember the WTF look on my dad's face, when I showed him how to fix the ordering of the init scripts on his server by editing some magical comments in bash scripts.

"You can even provide OPTIONAL ability for parallel startup for those who want it, while keeping the traditional startup sequence by default."

I have not had a purely sequential startup on my systems for a decade, since SUSE's init already started init scripts with the same number in parallel. So systemd does not even deviate here from SysV. It just fixes the mentioned WTF problems.

Poettering: The Biggest Myths

Posted Jan 27, 2013 15:30 UTC (Sun) by hazard (guest, #3695) [Link]

> In other words, one could create new infrastructure to support those features and rewrite every single init script to use it. Administrtors would have to learn a lot again about what new magical commands one would have to use to start a daemon.

Yes, but that can be done as a limited incremental change in the init scripts. Users would still know where to look and what to expect. In case of systemd, the approach is to wipe out everything and replace it with something completely different.

> But why not use this chance to go a little further and make another leap in usability and features?

Very simply, to allow people to use their existing knowledge and preserve backwards compatibility.

Too big a leap and you get your customers against you. Remember GNOME 3, Windows 8, etc.

> I still remember the WTF look on my dad's face, when I showed him how to fix the ordering of the init scripts

That's not a big problem. A big problem is when I get WTF face from my sysadmins. :)

Poettering: The Biggest Myths

Posted Jan 27, 2013 15:50 UTC (Sun) by niner (subscriber, #26151) [Link]

"In case of systemd, the approach is to wipe out everything and replace it with something completely different."

Which is simply not true. On my systems there are still a lot of init scripts still in use despite using systemd as init. None of our own custom init scripts needed even a single change. But of course we will replace them by real systemd unit files at some convenient time.

"That's not a big problem. A big problem is when I get WTF face from my sysadmins. :)"

Well my dad _is_ a sysadmin with decades of expierience with Netware and Windows. Stupidly overcomplicated things like SysV init scripts almost made him give up on Linux and stay with those systems. Because really, that 17 years of experience with something so mundane like the way to start and stop services on a server actually are worth something shouts that there's somthing wrong with the system.

Poettering: The Biggest Myths

Posted Jan 27, 2013 16:04 UTC (Sun) by drago01 (subscriber, #50715) [Link]

> That's not a big problem. A big problem is when I get WTF face from my sysadmins. :)

Go fire them and hire new ones. Seriously technology is not static a thing ... a sysadmin that cannot spend a few hours (at most) to learn a new system that is actually way easier to use then the old one has chosen the wrong job.

Poettering: The Biggest Myths

Posted Jan 31, 2013 15:54 UTC (Thu) by nye (guest, #51576) [Link]

Conversely it could be said that a sysadmin who is happy to spend a few hours here and there learning to use something new that solves problems *they don't have* is too ready to waste time.

Poettering: The Biggest Myths

Posted Jan 31, 2013 17:02 UTC (Thu) by davidstrauss (subscriber, #85867) [Link]

> Conversely it could be said that a sysadmin who is happy to spend a few hours here and there learning to use something new that solves problems *they don't have* is too ready to waste time.

A boss managing sysadmins with that attitude has zero respect for employee skill development or finding improved ways to do even the company's own work. It creates a workplace that hires people and spits them out ten years later with no recent skill development. Around here, the Bay Area, that approach couldn't even retain a good sysadmin. They'd quit for a company that shows them more respect.

But, maybe you don't have the experience to understand that. I've actually owned companies employing engineers and sysadmins for the last eight years, both here in and in Austin. The way to keep good people is to go out of your way as an employer to foster careers and skill development through side projects, training, books, conferences, and community involvement.

Poettering: The Biggest Myths

Posted Feb 2, 2013 19:11 UTC (Sat) by nix (subscriber, #2304) [Link]

The Bay Area is unusual. I was considered almost freakish in the City of London for wanting to keep my (software development) skills up to date. Just use what everyone else is using! Follow the herd and learn the hot stuff only when everyone else learns it! Baaaa.

Poettering: The Biggest Myths

Posted Feb 2, 2013 22:04 UTC (Sat) by davidstrauss (subscriber, #85867) [Link]

> The Bay Area is unusual. I was considered almost freakish in the City of London for wanting to keep my (software development) skills up to date. Just use what everyone else is using! Follow the herd and learn the hot stuff only when everyone else learns it!

I've done lots of work in London for The Economist and Cap Gemini. While they're both conservative in their technology choices, I'd have trouble generalizing it to the London area as a whole, mostly based on me having such a small sample size of organizations.

I've already mentioned Austin in my post, too, but devops culture aggressively focused on improving sysadmin work also extends to Portland (Puppet Labs), Seattle (Opscode), Austin/Chicago (bcfg2 and devops events), Berlin (systemd), New York, Boston, and a host of other cities with major projects or conferences devoted to improving the the way we do things.

Poettering: The Biggest Myths

Posted Feb 4, 2013 13:09 UTC (Mon) by nye (guest, #51576) [Link]

The point is, I'm sure you're not seriously suggesting that every time some new idea comes along, every sysadmin in the world should either be chomping at the bit to spend hours learning about it or be labelled as 'incompetent' and fired.

That's what I was responding to, and it's absurd. Nobody would ever get anything done.

I was attempting to make a rhetorical point, and clearly didn't do very well. I'm not suggesting that wanting to improve one's skills is a bad thing, but characterising anyone who doesn't immediately want to jump onto every new bandwagon as lazy and incompetent is appalling.

Poettering: The Biggest Myths

Posted Feb 4, 2013 14:28 UTC (Mon) by anselm (subscriber, #2796) [Link]

I'm not suggesting that wanting to improve one's skills is a bad thing, but characterising anyone who doesn't immediately want to jump onto every new bandwagon as lazy and incompetent is appalling.

I think that with systemd we're quickly getting past the »new bandwagon« stage. With the major enterprise-type distributions (RHEL and SLES) slated to replace System V init by systemd in the foreseeable future, administrators of machines based on these distributions, along with their spinoffs such as CentOS or Scientific Linux, could do worse than start getting used to systemd. On many other popular distributions, systemd is at least an option that is available to those interested in it, and it is quite likely that most of these distributions will also move over in time.

The nice thing is that systemd, for all it is being dissed by the traditionalists, is in fact in many ways an improvement on the tangle of »System V init plus distribution-specific init scripts plus various distribution-specific bits of infrastructure not actually part of System V init but tacked on to make it work in practice« that many system administrators are saddled with. In my experience, it doesn't take long for somebody who approaches systemd with an open mind to see that there actually might be something to it after all. Also, using systemd in place of System V init isn't exactly rocket science; it's not as if system administrators were suddenly forced to learn Mandarin in order to be able to keep their systems running.

Poettering: The Biggest Myths

Posted Feb 4, 2013 19:16 UTC (Mon) by davidstrauss (subscriber, #85867) [Link]

> I'm sure you're not seriously suggesting that every time some new idea comes along, every sysadmin in the world should either be chomping at the bit to spend hours learning about it or be labelled as 'incompetent' and fired.

No, I'm saying that "a few hours here and there learning to use something new" isn't a bad thing. I put that in quotes because that's what you actually said was bad.

Arguing that's valuable is hardly saying that "every time some new idea comes along, every sysadmin in the world should either be chomping at the bit to spend hours learning about it or be labelled as 'incompetent' and fired."

Don't create straw men out of my arguments.

Poettering: The Biggest Myths

Posted Feb 6, 2013 12:08 UTC (Wed) by nye (guest, #51576) [Link]

>Don't create straw men out of my arguments.

I didn't. That's why I said "I'm sure you're not" before paraphrasing the argument that the other guy made, specifically to point out that what you're arguing for is *not* what I'm arguing against.

I'm trying to say that you can support the idea that people might want to educate themselves without jumping right to "and anyone who doesn't always want to do that is incompetent".

Poettering: The Biggest Myths

Posted Jan 31, 2013 18:51 UTC (Thu) by smurf (subscriber, #17840) [Link]

Aww. So what you're saying is that there actually _is_ a sysadmin out there who never needs to figure out whether a given service is running, and if so, why not?
And thus, a less cumbersome/error-prone way to do that won't be of _any_ use to said sysadmin? Not even if … oh well, I'm not going to repeat myself again.

Anyway. I feel for them. I really do.

You see, in _my_ company sysadmins with _that_ attitude will quickly find themselves with exactly one remaining task: clean out their desk.

Poettering: The Biggest Myths

Posted Feb 4, 2013 13:13 UTC (Mon) by nye (guest, #51576) [Link]

>Aww. So what you're saying is that there actually _is_ a sysadmin out there who never needs to figure out whether a given service is running, and if so, why not?

I'm saying that there are loads of people who keep saying that they don't need systemd because they have no need for the facilities it provides, and that maybe - just maybe - they might not be lying.

>You see, in _my_ company sysadmins with _that_ attitude will quickly find themselves with exactly one remaining task: clean out their desk.

If this childish posturing makes you feel important, go right ahead.

Poettering: The Biggest Myths

Posted Feb 4, 2013 14:35 UTC (Mon) by anselm (subscriber, #2796) [Link]

I'm saying that there are loads of people who keep saying that they don't need systemd because they have no need for the facilities it provides, and that maybe - just maybe - they might not be lying.

They may not desperately need systemd's facilities but they might actually appreciate them once they have them available.

This »We don't need this« attitude reminds me of some of the Windows administrators I encounter in the Linux workshops I teach. These often refuse to have anything to do with pipelines, regular expressions, etc. on the grounds that they »don't need this« on their Windows machines, so these features can be of no conceivable worth whatsoever. Some of them are of a sufficiently agile mind to see that using these facilities on Linux does in fact make some things easier, even to a point where they find they have less drudge work to do on Linux than on Windows, but others never quite seem to get it.

Poettering: The Biggest Myths

Posted Feb 4, 2013 16:12 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

I'm saying that there are loads of people who keep saying that they don't need systemd because they have no need for the facilities it provides, and that maybe - just maybe - they might not be lying.

And they might be more believable if they appeared to be more familiar with exactly what facilities systemd provides. It appears to me that a substantial fraction of the resistance to systemd is based around ignorance of what it actually does and doesn't do. People seem to have made up their minds that they're happy with existing init systems and then looked for reasons to dislike systemd rather than finding out in detail about the potential advantages and disadvantages.

Poettering: The Biggest Myths

Posted Feb 6, 2013 12:29 UTC (Wed) by nye (guest, #51576) [Link]

To begin with, personally I'm actually not one of those people who doesn't have those problems. I do on occasion want to be able to do things that systemd makes easier, and am in principle very much in favour of systemd, though in practice I'm not actually willing to try it for myself yet until it's had at least another couple of years to mature - let's say jessie (Debian 8.0).

However, I have a great sympathy for those who are in that position, because that's where I was (and actually still am) with PulseAudio (which, I'll note, still doesn't work properly with Wine on 64-bit systems, at least not on Debian, and still provides no benefits I actually care about).

This is roughly how the exchange sounds from that perspective:

Person A: Try this new snibulator; it's great!
Person B: I'm happy with my old snibulator, thanks.
A: But this one allows you to snibulate even when you're under water!
B: Huh, that sounds cool, but I've never needed to do that.
A: Well you're just too stupid to realise that you need this after all.
B: Please stop telling me what to do.
A: Stop being so hostile! You're clearly too lazy to spend the time to work out that you really need waterproof snibulation. If I had any employees like you, I'd fire them on the spot! I'm so important!

The last line is the one that really grates on me, because it's so arrogant and so aggressively obnoxious. And I haven't hardly even had to exaggerate in my paraphrasing; many of the responses really are that hyperbolic.

Poettering: The Biggest Myths

Posted Feb 6, 2013 19:00 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> …with PulseAudio (which, I'll note, still doesn't work properly with Wine on 64-bit systems, at least not on Debian, and still provides no benefits I actually care about).

It Works For Me™ on Fedora. Rawhide no less (in December; not sure about this month yet). As for features, I keep an instance of MPlayer streaming some internet radio at work. It's nice to be able to mute it and still play some video with sound and then go back and unmute the stream seamlessly.

Poettering: The Biggest Myths

Posted Jan 27, 2013 14:51 UTC (Sun) by ovitters (subscriber, #27950) [Link]

You're suggesting that systemd requires loads of time to digress. I don't get why though. Could you please explain in practice?

I mean, I still can use chkconfig, service and dump a sysvinit script using systemd. Those are not the systemd ways, but it works fine anyway.

I also wonder why you think you represent an entire user-base or that you aren't listened to?

The most confusing thing about systemd for the distro I help out in is that we disabled the syslog daemon by default. That takes getting used to, no matter how easy it is to reenable it again.

Poettering: The Biggest Myths

Posted Jan 27, 2013 15:18 UTC (Sun) by hazard (guest, #3695) [Link]

Firstly I never wrote that I represent entire user-base. However, I do feel that many sysadmins share the same feelings about systemd as I do. At least I never heard praise of systemd from any of my peers.

systemd requires time to understand in its entirety. I'm not speaking about ability to start or stop particular service or init-script, I'm speaking about understanding the grand picture of how the new startup works in detail, what all those files in /lib/systemd mean and how they interact with each other.

Without having a good grasp on the startup process overall, one is unable to quickly troubleshoot issues. This causes a commercial risk of longer downtime, as sysadmins will take longer to bring the system up in case of a fault.

Poettering: The Biggest Myths

Posted Jan 27, 2013 18:04 UTC (Sun) by jwarnica (guest, #27492) [Link]

So don't upgrade to a system that uses systemd.

What is the problem?

Poettering: The Biggest Myths

Posted Jan 27, 2013 18:36 UTC (Sun) by larryr (guest, #4030) [Link]

So don't upgrade to a system that uses systemd.
What is the problem?

The problem for me is I want the other updates to the other 99% of the software on the system. I am not a sysadmin by profession or by choice, but I need to be for the things I want to do with the system. Understanding the holistic and specific impacts of using of systemd for everything it takes to do what I want has taken me many hours, and I suspect it will take many more. But I am not going to introduce the even greater risk of switching to a different system to avoid using systemd.

Poettering: The Biggest Myths

Posted Jan 27, 2013 18:49 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> systemd requires time to understand in its entirety.
Sysvinit based init schemes take orders of magnitudes more time and they even work differently on different distros.

> Without having a good grasp on the startup process overall, one is unable to quickly troubleshoot issues. This causes a commercial risk of longer downtime, as sysadmins will take longer to bring the system up in case of a fault.
This is a short-term problem that is easily offset by systemd's relative simplicity in the long term.

Poettering: The Biggest Myths

Posted Jan 27, 2013 23:13 UTC (Sun) by ovitters (subscriber, #27950) [Link]

If the init system was intended to be changed every few years, then I'd understand your point. But it is one change in 10+ years (depending on distro, etc).

So 'change is bad': agree. But this is a one-time change. Obviously there is pain in relearning things. But there are also loads of benefits, e.g. systemctl status $SERVICE actually gives meaningful output. Furthermore, you can have systemd reliably detect crashed services and have them restart automatically (no need for some monitor script). Things like this I see as hugely beneficial. One one server amavis dies every few months for reasons unknown. Restart and it'll work for months again. Pretty nice if that is supported instead of yet another monitoring script.

Regarding representing the entire user-base, you said:

Sorry, real life doesn't work this way. What people know DOES matter, what your existing customer base wants also DOES matter.

I doubt anyone fully knows what (e.g. Fedora) users want. Maybe they want systemd, maybe not. You suggest that change is bad and to me you were trying to speak on behalf of everyone with above. Misread that.

Poettering: The Biggest Myths

Posted Jan 28, 2013 4:20 UTC (Mon) by raven667 (subscriber, #5198) [Link]

I am a sysadmin and have been for around 15 years and I think that systemd is awesome so now you have some praise from your peers 8-)

I find systemd to be thorough well thought out, and am excited after doing some troubleshooting that required interaction with systemctl, loginctl and journalctl by how simple it makes things. In a way it reminds me of OpenBSD, which I also find to be well organized. The problems it solves are not fundamentally difficult, starting processes in a controlled environment, and clears away a lot of confusion by just, doing, that.

Poettering: The Biggest Myths

Posted Feb 6, 2013 5:45 UTC (Wed) by vonbrand (guest, #4458) [Link]

But as the knots SysVinit would tie the system into (by willy-nilly starting stuff "in order" when some precondition was delayed for whatever reason, something didn't start because of a mistake and the whole line of dominoes came down leaving no clue) are next to impossible with systemd, this point is moot...

Poettering: The Biggest Myths

Posted Jan 27, 2013 17:26 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> There are reasons why Cisco keeps IOS syntax unchanged, why GUI apps keep using "floppy disk" icon to save files and why Linus insists to keep kernel's user-level API unchanged.
Yeah, it's probably for the same reason that systemd still supports SysV init scripts, /dev/initctl and all that crap. Seriously, who are you trying to shit here?

Poettering: The Biggest Myths

Posted Jan 28, 2013 13:36 UTC (Mon) by pboddie (guest, #50784) [Link]

Perhaps you would make your point better by pointing to the documentation for those compatibility features instead of assuming that someone who is honestly reporting their concerns has a hidden agenda and has to be "called out" over it.

I know it's fashionable to tell existing users to "get with the program" and to assume that they have just as much time to read up on all the new stuff as the people who made that stuff had to develop it, but the recommended transition happens a lot easier if you don't ridicule those people as the first thing you do.

Poettering: The Biggest Myths

Posted Jan 28, 2013 13:52 UTC (Mon) by niner (subscriber, #26151) [Link]

Information about these compatibility features is contained in man systemd which at less than 400 lines of text should be short enough to warrant a reading by someone who obviously has enough time to post multiple messages about systemd. Wouldn't it be prudent to at least read a minimum of documentation before claiming missing compatibility?

Poettering: The Biggest Myths

Posted Jan 27, 2013 17:03 UTC (Sun) by smurf (subscriber, #17840) [Link]

>> Actually, this is the core issue: systemd, as a complete replacement,
>> makes all these years of experience obsolete and irrelevant.

No it does not. Your /etc/rcX.d/SYY.foobar script still works as-is. In fact, on Debian (if it uses the LSB functions) it transparently redirects itself to systemd, so your basic "/etc/init.d/foobar restart" invocation stanza does the right thing.

Your assertion that

>> most of the new functionality could be implemented without
>> a complete eradication of SysV concepts.

is misleading. Most, probably. All, no way. Just read the systemd.service manpage. Lots of what it can do require assistance from /sbin/init; when you're done implementing all of that, and then write another heap of fragile helper programs along the lines of Debian's(?) start-stop-daemon to do whatever can be done withoout /bin/init's help, you have basically created a wholly new startup system anyway. So, you can just as well drop that idea and use systemd. :-P

Just answering the question "is server FOO running" in traditional SysV is an exercise in fragility. PID file exists? Contents match a running process? With the same executable and/or process name? (Oops, does your SysV init script checks THAT? What happens if you rename inetd to inetd.OLD before restarting?)
If not, can we safely restart it – are all its child processes dead yet? What if two sysadmins restart a service at roughly the same time, would that cause a problem?

And so on.

Yeah, we old fogeys need to learn a few new magic incantations, but let's face it: they are a whole lot less fragile than the ones they replace, and they tell us a lot more about the state of the system. Given the choice between what "systemd status foo" does for me and what I had to do before to figure out what's going on (grep through ps, verify that the server I do see doesn't happen to run in some chroot-ish namespace, grep through a few syslog files), the choice is a no-brainer. Even for me.

Poettering: The Biggest Myths

Posted Jan 27, 2013 21:07 UTC (Sun) by pizza (subscriber, #46) [Link]

>Yeah, we old fogeys need to learn a few new magic incantations, but let's face it: they are a whole lot less fragile than the ones they replace, and they tell us a lot more about the state of the system. Given the choice between what "systemd status foo" does for me and what I had to do before to figure out what's going on (grep through ps, verify that the server I do see doesn't happen to run in some chroot-ish namespace, grep through a few syslog files), the choice is a no-brainer. Even for me.

This. A thousand times this.

Poettering: The Biggest Myths

Posted Jan 28, 2013 2:19 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

You know, regarding your example with spawning something on a serial tty: if I assume right you'd have edited /etc/inittab and add a new specialized line there, for your purpose, right?

As it turns out this already didn't work anymore long before systemd came along. And that's because Fedora and RHEL 6 used Upstart for a while, and Upstart already dropped support for inittab entirely.

In systemd, we could actually relatively nicely have provided compatibility with most features of inittab with a "generator" tool, which can extend systemd's dependency tree nicely from external configuration in other formats, such as inittab. However, given that Upstart already dropped support for inittab we decided there was no point in reintroducing it again.

So anyway, for this specific issue you cannot actually blame us systemd folks, blame Upstart instead please. (Not saying you can't blame us for a lot of other changes, but hey, for this specific one we do not take any credit.)

Lennart

Poettering: The Biggest Myths

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

doing a quick bit of googleing here, it looks like RHEL is shipping support for inittab in it's upstart driven versions.

This makes a lot of sense to me, the lack of inittab support in upstart is a mistake. It's too bad that systemd is copying this mistake. It will just require people to work around it.

Poettering: The Biggest Myths

Posted Jan 29, 2013 10:01 UTC (Tue) by michich (subscriber, #17902) [Link]

No, one cannot use inittab in RHEL 6 to spawn any custom services. The RHEL 6 Migration Planning Guide says:
The /etc/inittab file is deprecated, and is now used only for setting up the default runlevel via the initdefault line. Other configuration is done via upstart jobs in the /etc/init directory.
... and then goes on to describe how to setup a custom getty instance using an upstart job.

Poettering: The Biggest Myths

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

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

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