Ask Slashdot: Can You Say Something Nice About Systemd?

ewhac writes: "I'm probably going to deeply deeply regret this, but every time a story appears here mentioning systemd, a 700-comment thread of back-and-forth bickering breaks out which is about as informative as an old Bud Light commercial, and I don't really learn anything new about the subject. My gut reaction to systemd is (currently) a negative one, and it's very easy to find screeds decrying systemd on the net. However, said screeds haven't been enough to prevent its adoption by several distros, which leads me to suspect that maybe there's something worthwhile there that I haven't discovered yet. So I thought it might be instructive to turn the question around and ask the membership about what makes systemd good. However, before you stab at the "Post" button, there are some rules...

Bias Disclosure: I currently dislike systemd because — without diving very deeply into the documentation, mind — it looks and feels like a poorly-described, gigantic mess I know nothing about that seeks to replace other poorly-described, smaller messes which I know a little bit about. So you will be arguing in that environment."

Nice Things About systemd Rules:

1. Post each new Nice Thing as a new post, not as a reply to another post. This will let visitors skim the base level of comments for things that interest them, rather than have to dive through a fractally expanding tree of comments looking for things to support/oppose. It will also make it easier to follow the next rule:
2. Avoid duplication; read the entire base-level of comments before adding a new Nice Thing. Someone may already have mentioned your Nice Thing. Add your support/opposition to that Nice Thing there, rather than as a new post.
3. Only one concrete Nice Thing about systemd per base-level post. Keep the post focused on a single Nice Thing systemd does. If you know of multiple distinct things, write multiple distinct posts.
4. Describe the Nice Thing in some detail. Don't assume, for example, that merely saying "Supports Linux cgroups" will be immediately persuasive.
5. Describe how the Nice Thing is better than existing, less controversial solutions. systemd is allegedly better at some things than sysvinit or upstart or inetd. Why? Why is the Nice Thing possible in systemd, and impossible (or extremely difficult) with anything else? (In some cases, the Nice Thing will be a completely new thing that's never existed before; describe why it's good thing.)

We will assume out of the gate that systemd boots your system faster than ${SOMETHING_ELSE}, so no points for bringing that up. Bonus points are awarded for:

• Personal Experience. "I actually did this," counts for way more than, "The docs claim you can do this."
• Working Examples. Corollary to the above — if you did a Nice Thing with systemd, consider also posting the code/script/service file you wrote to accomplish it.
• Links to Supporting Documentation. If you leveraged a Nice Thing, furnish a link to the docs you used that describe the Nice Thing and its usage.

Comments

What Does Systemd Mean to Me?

[eldavojohn]

"What Does Systemd Mean to Me?"
By
eldavojohn

Systemd has a nice ring to it. The way the syllables roll off my tongue pleases me greatly. It could be the title of a great anime series. It could even be the lost name of an ancient forgotten god-king. It might even be the name I give my first born. It sounds much more authoritative and genuine than sysvinit or upstart or inetd. For instance from my non-technical fourth grade perspective this is what I interpret the others to mean:

• sysvinit - A cheap knockoff of systemd. Sounds sort of like a sexually transmitted disease phase like syphilis virus initialization.
• upstart - Sounds like you don't know what the hell is going on. "This young upstart" ... leave it to the pros, greenhorn. Leave it to systemd.
• inetd - What are we, fishing here? You netted? You netted what? At least tell us what you netted. Is it a record breaking fish? Also, nice try with the cheap 'd' knockoff at the end. Leave it to the originals. Leave it to ... systemd.

Contrary to your base assumptions, systemd does not actually boot faster on my Pentium II (Intel inside) system. I just like the way it sounds.

• Personal Experience - I actually stood up at dinner last night and slammed my fist down on the table and yelled at my wife that "WE WILL ONLY USE SYSTEMD IN THIS HOUSE FROM NOW ON" and I flung her iPad against the wall, shattering it. And then I got down on my knees in tears -- having seen the light -- and swore fealty to systemd.
• Working Examples - Three nights ago I stole away into the night across town to the Olafsen's house (a predominantly Norwegian family) and (being predominantly of Swedish descent myself) spray painted on the front of their new home: "SYSTEMD BOOT HOME" in blood red paint. This was a Nice Thing in a "never forget" sorta way. I then got down on my knees in tears and applied the spray paint liberally to my upper lip -- the same condition in which I write this post for you, dear reader.
• Links to Supporting Documentation - [1]

Re:What Does Systemd Mean to Me?

[Anonymous Coward]

We need to stay on topic, let's talk about Rampart.

Re:What Does Systemd Mean to Me?

[therealkevinkretz]

We've had problems a few times with systemd (usually the next boot after an upgrade to a package). Without exception, the failed boot occured with next-to-no meaningful error on the console and was more difficult to debug than if it had been using sysvinit. I personally, as a sysadmin for ~16 years, don't see a problem with sysvinit that justifies tearing it out of Linux for a more complicated, more opaque replacement.

Re:What Does Systemd Mean to Me?

[ACE209]

ok - comments can be closed I think.

There should be no more to say here.

Re:What Does Systemd Mean to Me?

[Jane Q. Public]

Come back when you've done the research and can back up your bias with evidence, thats the only way people can come to a reasoned decision about anything

Better yet, come back... somewhere else. OP's attempt to establish new and different rules for a Slashdot discussion is probably doomed to failure.

Re:What Does Systemd Mean to Me?

[dgatwood]

It works way better than AUTOEXEC.BAT.

Re:What Does Systemd Mean to Me?

[thegarbz]

I personally, as a sysadmin for ~16 years, don't see a problem with sysvinit that justifies tearing it out of Linux for a more complicated, more opaque replacement.

So your 16 years of experience has highlighted two things:
1. You don't realise how insanely complicated the init system is for how little it does. Let's face it you're probably an expert that can code an init script in your sleep. But why does starting a simple service require some 200 lines of scripting. Why does after the 200 lines of scripting the init system not keep track of the service's running status. The number of times I've come across failed starts, failed stops, or service already running when it's clearly not is incredible.
2. You don't realise systemd is not about the init system, but about complete system management. Init is just a small part of it.

Re:What Does Systemd Mean to Me?

[epyT-R]

Actually, I know I've found a genuine concern troll when a community is generalized negatively,with words like 'safe' and 'diversity' thrown around when the troll gets called out on its bullshit victimhood routine.

Re:What Does Systemd Mean to Me?

[robinsc]

Erm shouln'd that be initd not inetd ?

Re:What Does Systemd Mean to Me?

[whoever57]

1. You don't realise how insanely complicated the init system is for how little it does. Let's face it you're probably an expert that can code an init script in your sleep. But why does starting a simple service require some 200 lines of scripting

I've seen that argument before and it make no sense to me. All that has happened is that the lines of code have moved from a script to a binary. Sysadmins don't routinely edit init scripts, so the number of lines in them isn't important.

Re:What Does Systemd Mean to Me?

[thegarbz]

Actually it makes a lot of sense when you think about it. Do you routinely code a new windowing system every time you write an application, or do you code with some toolkit or framework which provides you an easy way to display a window? Do you write a new sound card driver every time you want the computer to beep?

No. Programming is done with APIs, repetitive tasks are done with libraries, and critically tasks which are required to be done every time something happens should be managed by an application and not coded individually every time.

The init process itself is basic. A master process tracks children, a filename decides when to start a service, and a script then manages that start-up. So why is it that sshd which can be started with a single command requires a 200 line script to get going at boot time? Why is it that most of those lines are duplicated. From the point of view of a programmer, and an end user (who has on several occasions debugged problems which were the result of an init script not working properly), a 6 line upstart file, or a 10 line systemd file are far better for something that accomplishes the same thing.

The other problem is that the init scripts are effectively programs that manage the process itself, and they are often based on very manual tasks. I've lost count the number of times I've typed in "service xxxx start" got "service already running PID blah" as a response, and then typed "service xxxx stop" only to get a "Failed" message. Much of the task of the init system which is now manually programmed on a per application basis and maintained manually for each distribution really should be passed on to some helper application.

Sysvinit definitely has it's share of problems. People just put on rose coloured glasses in the wake of the politically charged systemd comments.

Re:What Does Systemd Mean to Me?

[whoever57]

The other problem is that the init scripts are effectively programs that manage the process itself, and they are often based on very manual tasks. I've lost count the number of times I've typed in "service xxxx start" got "service already running PID blah" as a response, and then typed "service xxxx stop" only to get a "Failed" message. Much of the task of the init system which is now manually programmed on a per application basis and maintained manually for each distribution really should be passed on to some helper application.

Many of the problems with sysvinit have been solved in OpenRC. For example, OpenRC uses dependencies to define the order in which the services are started. My point is that such a radical change as systemd is not required to deal with many of the issues in sysvinit.

One of the things I keep reading about systemd is that it will re-start services that have stopped. This is such a non-issue to me that I really don't care, plus, as other people have noted, there are many ways processes could die that I don't want them to be re-started without some intervention to investigate and fix the cause of the daemon dying (for example, mysqld running out if disk space).

From the point of view of a programmer, and an end user (who has on several occasions debugged problems which were the result of an init script not working properly), a 6 line upstart file, or a 10 line systemd file are far better for something that accomplishes the same thing.

But if there is a bug that prevents something from working properly, you need to debug how many lines of code from systemd, running as PID 1, versus a script. What your argument boils down to is that you don't expect systemd to have bugs.

Re:What Does Systemd Mean to Me?

[thegarbz]

Oh dear. This post is full of what I imagine is knowledge of systemd gained by reading slashdot comments. Let's go through it.

Many of the problems with sysvinit have been solved in OpenRC. For example, OpenRC uses dependencies to define the order in which the services are started. My point is that such a radical change as systemd is not required to deal with many of the issues in sysvinit.

Systemd is not just about the init system. It's about complete system management from hardware, services, logins, and amongst that also the init system. It would be a very strange world indeed where we replaced everything except sysvinit and then used OpenRC for the rest. Yes the problems are solved. Yes you can add several other helper programs to achieve systemd's feature set in the init system without actually using systemd, but then that really isn't what it is all about, and a wide clusterfuck of many different programs used to manage a common task is exactly what systemd is replacing. (Yes it's not Unix and they never claimed it to be)

One of the things I keep reading about systemd is that it will re-start services that have stopped. This is such a non-issue to me that I really don't care, plus, as other people have noted, there are many ways processes could die that I don't want them to be re-started without some intervention to investigate and fix the cause of the daemon dying (for example, mysqld running out if disk space).

Before I talk about why restarting services would be a good idea I should mention to you that this is configurable. Not just configurable, but highly configurable. You can opt to restart a service based on the exact exit code of the process. Currently there's talk about restarting a service based on what the service logs to the system when it dies. The choice is all yours. You can set mysqld to die. You can set sshd to attempt multiple restarts before dying. Different services, and different applications which they are used have different requirements, and in many cases random non-serious crashes due to users hitting edge cases would benefit from an attempted restart to minimise downtime.

But if there is a bug that prevents something from working properly, you need to debug how many lines of code from systemd, running as PID 1,

Let me stop you there for the first part. There is NOT VERY MUCH RUNNING AS PID1. The core systemd process exists pretty much only to catch orphans and start up some of the 70+ other systemd functions. This PID1 argument needs to be killed as it is a very serious issue which causes a lot of angst, and in most cases is completely incorrect. For all the bugs in systemd I believe there has yet to be one that causes a kernel panic (what happens when PID1 dies).

versus a script. What your argument boils down to is that you don't expect systemd to have bugs.

No that's not what my argument is. My argument is I expect systemd to be a sole source of fixable bugs. One place for a bug to exist, vs every single init script re-inventing a wheel over and over again. Systemd has bugs. But init scripts have bugs too, and the bugs in init scripts are often the cause of trying to implement some function common to the entire system incorrectly. I would like to point out again, 200 lines to start sshd on my system. Close to that again for the next service. Upstart and systemd both achieve the same thing in under 20. There's a lot of be said combining repeated functions into a single library or helper application exposing an API. That is programming 101 right there. For all the good things to be said about init scripts there certainly are a lot of projects out there attempting to replace this very component of them.

Re:What Does Systemd Mean to Me?

[therealkevinkretz]

I understand that it has other features. But it fucks up the init system, which is pretty important.

Re:What Does Systemd Mean to Me?

[whoever57]

Many of the problems with sysvinit have been solved in OpenRC. For example, OpenRC uses dependencies to define the order in which the services are started. My point is that such a radical change as systemd is not required to deal with many of the issues in sysvinit.

Systemd is not just about the init system. It's about complete system management from hardware, services, logins, and amongst that also the init system.

Standard systemd supporter response. "we should systemd because it will fix all the problems in sysvinit .... what's that, they are fixed in OpenRC ... don't look at sysvinit .. look at the shiny over here instead". The point is that a major plank of the argument of systemd is about sysvinit and it simply isn't valid.

Before I talk about why restarting services would be a good idea I should mention to you that this is configurable. Not just configurable, but highly configurable. You can opt to restart a service based on the exact exit code of the process.

Again, you missed my central point. The value is being able to restart services automatically is exceedingly low. Processes don't die on my servers and if they do, it needs human involvement to investigate.

Let me stop you there for the first part. There is NOT VERY MUCH RUNNING AS PID1. The core systemd process exists pretty much only to catch orphans and start up some of the 70+ other systemd functions

As you point out, the very services that are replacing much of the functionality in those init scripts are running as PID 1, so your argument is irrelevant. Just because not much is running as PID 1 does mean that nothing is running as PID 1.

I would like to point out again, 200 lines to start sshd on my system.

On my Gentoo system, running OpenRC the init file for sshd is 87 lines, of which 13 are blank, and 4 more are comments. So, really 70 lines. Furthermore, those init scripts don't change much -- any bugs will have been worked out. Because systemd centralizes this, the code will change all the time.

Re:What Does Systemd Mean to Me?

[thegarbz]

Standard systemd supporter response. "we should systemd because it will fix all the problems in sysvinit .

Wow. Just Wow. Did you even read my post or just blindly hit reply? Let me re-write that very first line for you so you can enjoy it again: "Systemd is not just about the init system"

Again, you missed my central point. The value is being able to restart services automatically is exceedingly low. Processes don't die on my servers and if they do, it needs human involvement to investigate.

Um. Ok false and false. I tried to point out the fallacy of latching on to the restarting processes concept and pointed out that it is optional and configurable but since you're obsessed with the concept lets address it. There are cases where once a service is down it should stay down. But surprise surprise there cases where things happen for no reason (e.g. random non-persistent hardware error), or things happen for very rare isolated issues that are unlikely to be realised again soon. In those cases there is great value in attempting an automatic restart to minimise downtime for trivial issues, providing a) log records are preserved so an admin can check, b) the admin is notified and it all doesn't happen silently, and c) the action is configurable in a way that limits the attempted restarts, or limits the conditions which would initiate a restart.

Systemd does all of the above, or none of the above. But feel free to freak out over a feature you don't want which is entirely optional in the install.

As you point out, the very services that are replacing much of the functionality in those init scripts are running as PID 1, so your argument is irrelevant.

Do we have a language barrier here? I invite you to scroll up and re-read what I said. I'm not even going to bother paraphrasing it at this point.

Just because not much is running as PID 1 does mean that nothing is running as PID 1.

You're right. We should do away with PID1 all together. Who needs a system that catches orphaned processes and then hands over startup to another system (all systemd does at PID1). You can enjoy forever staring at the last line of the kernel initialisation.

On my Gentoo system, running OpenRC the init file for sshd is 87 lines, of which 13 are blank, and 4 more are comments. So, really 70 lines. Furthermore, those init scripts don't change much -- any bugs will have been worked out. Because systemd centralizes this, the code will change all the time.

*Golfclap* Ok so you achieved a reduction of slightly more than half compared to the 90% I was talking about, but let's ignore that supposed victory of starting what is one of the simplest services that linux could start. I suppose we should all hide under our tables because the world itself must be unstable. Imagine it, the Linux kernel itself could change and then everything in the world would break. ... Or not. That's how you code in highschool before you learn of the concepts of debugging and testing.

But you've raise another interesting point, you're using OpenRC which is neither here nor there, but I decided to look up my Mint setup and check out the sshd init file. It's 167 lines. So even though both the distributions I have access to in this room are based from Debian, they both have very different init scripts, that must be maintained by someone on a per installation basis. Then there are the different ways different systems handle the configurations too with some init scripts having it at the top, some having a separate config file they read in as variables, some just reading command line arguments in as one line and appending them to the start command. If you think this horrendous cluster-fuck is in any way more stable or consistent then using a common stable code base to get things done (which it looks like you were implying) then I suggest seeking professional help.

Re:What Does Systemd Mean to Me?

[WorBlux]

A common base while having common procedures also has common weaknesses and drawbacks. Like in agrigulture, monocultures are easily managed and highly productive, but are very suspectable to pathogenic agents.

It freakin' works fine

[CajunArson]

I've done migrational upgrades to System-d with Arch Linux with zero problems in addition to using it with new installations. It works fine, and I'm still really confused about the jihad-level hatred it seems to engender in some people.

Re:It freakin' works fine

[binarylarry]

Remember how awesome pulseaudio is? Well what if we made your ENTIRE SYSTEM that awesome?

Re:It freakin' works fine

[Anonymous Coward]

Pulseaudio works fine.

People think it sucks; the reality is that the implementation in Lolbuntu was done poorly, giving the non-competent people a bad taste of it.

I used it in its first versions, and it handled my 5.1 setup perfectly, switched to headphones when I plugged them. And it had per-application volume working out of the box.

It's one of the first things I install when I install Debian.

Re:It freakin' works fine

[Anonymous Coward]

Are you trying to imply that all the hatred I've heard about pulseaudio was also unjustified?

Only if you have a setup like Potterings, since he rewrote the pulseaudio configuration to work on his computer and just deleted features he wasn't using to "keep it easy".

Sort of like how if you're using systemd in an NFS world you're going to have a bad day, since he still hasn't made their dependency resolution work correctly with networked filesystems. Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc, I suppose we'll need the kernel rewritten to support a systemd-mount program to solve this problem, which will of course be incompatible with standard mount.

Re:It freakin' works fine

[Anonymous Coward]

This has been my experience too. I am confused in some ways that parallel the original story submitter. There are always complaints about systemd every time a story about it comes up. There are some legitimate ideological criticisms, and that will always be subjective to some degree as people have varying ideas about how a system should be built and different thresholds for deviations from the path they prefer. But the problem is that very few people stick to such an argument, and those that do get disregarded.

The complaints that get time and attention tend to be "concrete" technical problems. I use scare quotes, because quite frequently the things they complain about though end up being flat out wrong. Some times people say systemd can't do something specific, but then someone links to a guide that says exactly how to configure that way. Or even worse, links are made to TFM saying that is the default way of doing things, so it does it out of the box with no extra configuration. Or going the other way, complaints that it does one thing, but both TFM and my experience actually using it give that it does not.

But the posts pointing out quite clearly that someone making a specific complaint doesn't know what they are talking about gets ignored, or attracts more false complains and ends up modded down as a troll. In the end, it seems like 90+% of the arguments about systemd end up to being people who don't use it, and never even RTFM, but act like they're guess and assumptions is exactly how it works.

I'm not saying systemd is necessarily a good thing, and that switching to it is the right path forward. But actually discussing that with any expectation that people are going to talk about systemd and not some imagined strawman has become impossible.

Re:It freakin' works fine

[serviscope_minor]

I've done migrational upgrades to System-d with Arch Linux with zero problems in addition to using it with new installations. It works fine, and I'm still really confused about the jihad-level hatred it seems to engender in some people.

But "works fine" isn't really a Nice Thing as defined in TFS. I mean for very large values of "worked fine", so did the old scripts. It's not like my computers only became usable this year.

"works fine" is the minimum acceptable level for an init system.

Re:It freakin' works fine

[AmiMoJo]

Think back to the epic holy wars of the past. Emacs vs. Vi. Big vs. Little Endian. Motorola vs. Intel. Amiga vs. Atari ST. ASCII vs. EDBIC.

Some people go to war over which part of their dick they are supposed to cut off. Some people go to war over a text editor. It's human nature.

Re:It freakin' works fine

[Anonymous Coward]

because people don't like stuff forced down their throat... most admins have a natural aversion against LOSS OF CONTROL... and pottering is your domina that forgot to give you the safe word.

Re:It freakin' works fine

[binarylarry]

I'm looking forward to the next follow up:

Ask Slashdot - Can you say something nice about Florian Mueller?

or no even better:

Ask Slashdot - Can you say something nice about Slashdot Beta?

Re:It freakin' works fine

[psmears]

Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc,

Really? I confess I haven't looked at how to configure systemd much, but from what I have seen, that sort of setup could be supported easily enough by writing the right unit files (or whatever they're called) and specifying the dependencies. What's the issue that prevents that working?

Re:It freakin' works fine

[CajunArson]

"Heh... Have you used *ANY* Linux audio on most Linux distributions? If so, you've used it."

No... really.. I haven't used it.
I have a real soundcard (Xonar) in my main machine that just passes a signal through TOSlink to my receiver. While libpulse is installed as a required dependency, I literally do not have the pulse audio server package installed.

All of my Linux boxes are *highly* customized, no kitchen-sink Ubuntu stuff going on here. I fully admit that I'm not setup to do professional audio editing or anything like that, but sound most certainly works and it doesn't require pulseaudio.

Re:It freakin' works fine

[thegarbz]

Remember how awesome pulseaudio is? Well what if we made your ENTIRE SYSTEM that awesome?

Oh I could only dream. Imagine that, a system which can cope with plug and play and access to multiple pieces of hardware at the same time. A system which can seemlessly switch outputs as hardware becomes available. My god that would be an amazing system.

Actually you've demonstrated the parent's point very well. Pulseaudio like systemd solves very real problems. It had teething issues and now seems to work rather well. If my experience with systemd will be anything like it is with Pulseaudio then I say bring it on.

Re:It freakin' works fine

[LWATCDR]

Emacs, Amiga, Motorola, ascii.

Actually I had an Amiga and it was a better system but I still thought the ST was cool. It was the PC that sucked and still won. BTW before anyone goes of how the PC was open when the Amiga launched you had 286s, running MS-Dos that limited you to 640 of real memory with out a lot of tricks and a 33mb partition limit on hard drives.
Oh and the OS did not handle graphics, printing, or audio. If you wanted to do any of those you had to do it all yourself. Every program had to have a bunch of printer drivers to print and you just usually hoped that your printer could emulate an epson, Okidata, or Diablo printer.

Re:It freakin' works fine

[mrex]

I used it in its first versions, and it handled my 5.1 setup perfectly, switched to headphones when I plugged them. And it had per-application volume working out of the box.

AKA the "I like PulseAudio because I coincidentally owned the hardware it actually supported well" comment.

Re:It freakin' works fine

[CaptainDork]

* EBCDIC

Re:It freakin' works fine

[idontgno]

Hey, it's not HIS fault your cow wasn't spherical enough!

Re:It freakin' works fine

[DrXym]

People had a holy war in support EBCDIC?

Re:It freakin' works fine

[Anonymous Coward]

For the first several years of it's existence, the only problem pulseaudio solved on my system was the ability to run at all - as in, when pulseaudio was installed and "activated", the system didn't run.

Stock fedora implementation, completely unstable and unusable. Had to strip it out every time I reinstalled until around FC13 or so, after which it finally allowed my system to actually run.

That in mind, my "positive" thing to say about systemd is that unlike PulseAudio, the first version of it that Fedora installed didn't drag my system to a screeching (literally! Had to unplug the speakers.) halt.

Re:It freakin' works fine

[Anonymous Coward]

Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc,

Really? I confess I haven't looked at how to configure systemd much, but from what I have seen, that sort of setup could be supported easily enough by writing the right unit files (or whatever they're called) and specifying the dependencies.

Yes, exactly. So, by developing a clear understanding of systemd syntax and dependency specification, you should be able to solve the dependency problem that rc/sysvinit solved fifteen years ago by specifying that dependent processes start after their requirements.

This is actually a silly example. If all of the start-up processes are loaded sequentially, then order is really not a hard thing to sort out. You can do it manually, in your head, and your brain can process what's going to happen. Systemd introduces a massive complication by allowing init processes to happen in parallel. So, now you've got this horrible optimization to do, where you separate all of the separate init processes into mutually independent sequences that start in parallel. So, your brain can tell that you should start network file systems only after you've started the network, but how about the audio driver? Can you start named in one process while starting apache in another?

My point is that the dependency issue is really something that systemd introduces, and the benefit of its automatic dependency resolution is only relevant in the context of systemd. If it's really important to you that your computer be able to start multiple daemons in parallel, rather than wait the 5 seconds it takes to start bind before starting apache or samba or whatever, then systemd does that and solves the problems it introduces. If you'd rather understand what happens as your system starts up and not trust someone else's optimization, then systemd is not for you.

Re:It freakin' works fine

[jedidiah]

Yes but at least pulseaudio seems easy enough to turn your back on. If you have a lowend system or just no tolerance for errors, you can rip out pulseaudio easily enough.

That doesn't seem to be the case.

I wish I could say that about systemd but that doesn't seem to be the case. It even violates that design aspect of Unix.

The real problem is that nothing was broken before. So the absolute best you can hope for is "it didn't break things".

Re:It freakin' works fine

[belgianpainter]

So for you pulseaudio worked. But for many other people it didn't. The nice thing though is that it was very easy to not use pulseaudio. The problem with systemd is that, for some reason, so many other things have become dependent on it.

Re: It freakin' works fine

[myowntrueself]

I have used Linux for 15 years without any problems.

I've used Linux since the kernel versions started with a 0.

If you haven't had any problems you aren't trying hard enough.

Re:It freakin' works fine

[satch89450]

In banking apps, they still do have holy wars for EBCDIC. Decimal math instead of binary math or (brrrrrr) floating-point math. There are still a lot of legacy systems running multiple levels of emulation, all the way down to 407 accounting machines.

Re: It freakin' works fine

[jones_supa]

I have used Linux for 15 years without any problems.

Think again. For example, do you remember in the past 15 years you experiencing any of the following while using Linux?

- the desktop is tearing (vsync problem)
- suspend or hibernate is not working properly
- you get a blank screen when X.org starts
- making manual modifications to the system as a workaround for a bug
- a power management issue has bitten you, such as the system consuming too much power, overheating, or fan spinning constantly

I am not making comparison to Windows or Mac here, because they have their similar bag of problems. Your claim was about using Linux without any problems.

Re:It freakin' works fine

[LVSlushdat]

I'm on Ubuntu, and if I want to get an HP USB headset to work, I gotta rip out Pulseaudio and go back to Alsa, where the USB headset *just works*, kinda like it does when I use it on (shudder) Windows... In Windows (and Alsa) you plug the USB headset in, your audio out goes to the headset, your mike audio comes from the headset mike.. You pull the USB plug out and audio is back to internal mike and speakers... I spent days fucking around trying to get this to work in PA, then read an article that basically said "Alsa is the only way to get one of these headsets to work".... Sure, I know, *somebody* here is gonna pipe up and say "I had NO trouble getting USB audio to work right on Pulse".... yippy for you.. THAT was NOT my experience... I've been working with Linux since 1994, started with Slackware.. so I'm not a rank noobie.. And on another note, I suspect Pat and I will get reacquianted here pretty soon, since I have it on good authority he hates systemd as much as a LOT of us do and since every other distro seems to be going that way, its likely back to Slackware for moi...

Re:It freakin' works fine

[Bill_the_Engineer]

Don't be an EBCDIC! ;)

Re:It freakin' works fine

[Barsteward]

can you list those things that are dependant on systemd so we can start to compile a list?

Re:It freakin' works fine

[Wheely]

I wish you hadnt posted this as Anonymous Coward.

It is extremely good and currently has a score of 0.

Re: It freakin' works fine

[Anonymous Coward]

All you've really done is admit you can't mentally visualize a dependency graph. Why should init be at best only 1/n efficient on an n-core system?

Re:It freakin' works fine

[Troy Baer]

Newer versions of GNOME (3.8 and after?) rely on a DBus API of systemd's logind component, for reasons I've never seen adequately explained.

The talk of forcing all cgroup interactions to go through systemd would in effect make anything that interacts with cgroups or cpusets such as hwloc, TORQUE, and SLURM rely on systemd. I can't imagine that the developers of hwloc, TORQUE, and SLURM are especially happy about that.

Re:It freakin' works fine

[Eunuchswear]

Sort of like how if you're using systemd in an NFS world you're going to have a bad day, since he still hasn't made their dependency resolution work correctly with networked filesystems.

Huh? Works for me.

Re:It freakin' works fine

[davydagger]

its something new, and just like a jihad, not in holy scriptures.

Someone has to learn something new, and that pisses them off.

Re:It freakin' works fine

[elgaard]

what pulsed solves is not very important problems, for me at least.
But it introduces strange problems, besides eating CPU-cycles and RAM.

For example, I resently spent some time debugging why icedove occasinally froze. It turned out that it was trying to play a sound, but that went wrong because the user starting icedove was not the same as the user starting the desktop even though both were in the audio group.

It should be possible to make pulse work in system mode, but I could not get it to work well. But deinstalling pulseaudio and just using ALSA works perfectly.

Re:It freakin' works fine

[tlhIngan]

Actually you've demonstrated the parent's point very well. Pulseaudio like systemd solves very real problems. It had teething issues and now seems to work rather well.

The problem stems from the fact that they solve very hard problems. Audio IS hard - it's not just putting a stream to a card and having a beep come out from a speaker anymore - nowadays audio is FAR more complex. Most computers now have various ways to get audio in and out - a hardware ADC/DAC (sound card), Bluetooth, HDMI, digital (S/PDIF, TOSLINK), built in speakers/microphones, etc. etc. etc.

And the one you use at a given time depends on what you're doing. If you're on a VoIP call, you want to have its audio routed to a communications port (which may or may not be separate from the main audio out), you may or may not want to mute the main audio (or just lower the volume), and so forth.

Then there's the common case of mixing - you're watching a YouTube video and someone IMs you, so you need to mix the two streams together to play it out the main output.

Oh, now you unplugged the laptop from your desk and what was using the optical or HDMI audio outputs now needs to switch to the onboard speaker and microphone.

It turns out init isn't all that simple either. Because even SysVInit is fairly complex - it has to reap zombies (every process has init as its parent, eventually). It has to manage daemons (yes, even SysVInit has to manage daemons - take a look, you probably have a bunch of lines where it manages getty). It also has to run the hack that are RC scripts which appear to implement a lamer version to manage daemons. Oh yeah, it also has to shutdown and restart the computer, too. (And I don't mean stopping daemons and such, either).

So after all this, SysV already handles two forms of daemon management (each with their own plusses and minuses), it has to reap processes (to free up kernel resources), shuts down or reboots the computer, and it also has to handle starting up the computer.

Re: It freakin' works fine

[LWATCDR]

At the time it was the only way to make a computer at the price and performance of the Amiga. Also at the time no one knew the future. Windows 95 was a decade away. Windows was a bad joke. Mac OS was stuck in black and white and at a price point well beyond the Amiga and ST.
One does wonder what have happened if the Amiga was based on http://en.wikipedia.org/wiki/C... instead of Tripos.

Re:It freakin' works fine

[kthreadd]

Of course stuff was broken. Stuff is always broken. Sysvinit was broken. Systemd is better but is probably also broken, one day it may as well be replaced by something else. The good part is, we are making progress. Over time the new stuff tend to be less broken than the stuff that came before it. You might tell yourself that nothing was broken before, but chances are it just happened to work well for you. Because if it wasn't broken, then that would be the first time in the history of the planet that a software project was infallible; and that would be amazing.

Re:It freakin' works fine

[ratboy666]

"Learn something new"...

I have a tablet computer. Using Fedora on it. Mostly all right. Some frustrating bits. The dpi setting is dead wrong. Would have been a simple fix in the "old" init system. I would have simply added dpi correction before the X server came up.

Now, I am *just* an old-time Unix user. And, I do have other things to do... So, I posted a question to Fedora support. The response? Um... zero.

Sure, it's in the init.... somewhere. I really don't want to "learn" a new init system. Why should I want to? So, I applied corrections to my most-used applications instead.

Pulseaudio? works fine, sure. Except that the last time I tried it with something other than Gnome, my xbell no longer sounded.

So, use Gnome. Gnome needs systemd.

So, use systemd.

I am sure my dpi issues will be sorted. Hopefully before I retire this tablet - but I doubt it.

The best thing about systemd? It does start processes and reaps. On Fedora, it respects "service" and "chkconfig"

The logs are larger, which concerns me -- this is a SSD based tablet. All of the logging in my programs was broken by it. It only took 2 days to fix.

Re:It freakin' works fine

[Aighearach]

Nonsense, it is a load of crap. He even wants to throw away parallel startup. Why? "If all of the start-up processes are loaded sequentially, then order is really not a hard thing to sort out." Well, shucks Wilbur, this is like the guy that is against fuel injection because carburetors are easier to understand. Nevermind that fuel injection is better in every way, and that the technology is easy to work on for properly trained mechanics.

So, your brain can tell that you should start network file systems only after you've started the network, but how about the audio driver? Can you start named in one process while starting apache in another?

This is actually so much easier than you imagine... if understanding the dependencies is too hard for you, don't re-order them. You should not need to, it is not a normal part of system administration or software development. Let the good people who develop your distro worry about these hard parts. Trust that they hire or appoint people smart enough to understand their job, and get on with your life.

There is no new dependency "issue," there are just new capabilities.

If you'd rather understand what happens as your system starts up and not trust someone else's optimization, then systemd is not for you.

The bad news is, since a person with this concern doesn't understand how really any of the boot process and software works, distros are not for you and you should write your own because that is the only way you're going to understand what it does. The argument really falls on its face. If people understand what their computer is doing at that level, they can understand parallel startup. Sorry, they can.

Re: It freakin' works fine

[ogdenk]

There was a SysV UNIX port for the Amiga as well as the Atari TT030.

The ST should have been a PC & Mac killer. It held its own for a long time but the tech got stale, they didn't dump enough R&D into it fast enough and they fell behind.

The ST had a CPU that could keep up with the 286, built-in MIDI and HDD controller, 512-color palette, half decent sound and a color 100% mouse-driven GUI. For half the price of a Mac and much cheaper than a 286. Good times.

Re:It freakin' works fine

[Aighearach]

lol yeah, 15 years ago we were crying about how SysV sucks and somebody please replace it, and the replacements were all more broken than those shitty initscripts... until systemd came along and at a minimum, had a less broken design. OK, now that is a huge improvement; the suck is all related to implementation! That is suckiness that goes away, rapidly. YaY!

Re:It freakin' works fine

[Aighearach]

They're all reminiscing about the old days where moving the audio from one output to another required restarting the app and restarting it with different command line options, and "per-application volume control" was the responsibility of the app, and if an app didn't have it, tough.

And integrating networking was impossible, you needed special server software that bypassed the sound system and did the networking by hand, and had its own mixers outside the sound ecosystem.

Re:It freakin' works fine

[Wing_Zero]

well, the devs at XBMC (now kodi i guess) pulled pulseaudio from the main ISO because it introduced some very annoying randomness.

I start with that, add Plex, lxde, Steam and a few emulators. up till the last two, you don't need pulse-audio. so i manually start it via terminal command, and then launch steam. well, steam audio seems flakey, sometimes works, sometimes not, i load up a emulator, and i can play for about 10-20 minutes, the audio will lock up, and i have a loud buzz of what ever sound was playing at the moment of lockup. i have to reboot to get the audio to reset. stopping pulse-audio, logging out, no good.

outside of those 2 applications, alsa-audio works flawless for me.

Re: It freakin' works fine

[digitalPhant0m]

If you haven't had any problems you aren't trying hard enough.

If you haven't had any problems you are lying.

Fixed that for you.

Re:It freakin' works fine

[dhasenan]

You mean a rocky start, stability within two or three years, better user interface options, and a few features that are really awesome but I don't use all that often, for an overall moderate improvement?

Re:It freakin' works fine

[gmack]

This is news to me. My main PC (debian jessie) has four cifs mounts on startup and they all come up with no trouble. The only systemd issue I've had so far was a minute and a half hang on startup that I couldn't spot but that was fixed by the latest debian update making the startup process actually tell me what it was doing. Turns out I had a swap entry in /etc/fstab from an old drive I removed ages ago and systemd was giving it a full 90 seconds in case it was slow to initialize rather than not there.

Re:It freakin' works fine

[gmack]

Legacy? 5 years ago we had to interface with a bank who used XML with EBCDIC fields.

Re: It freakin' works fine

[jones_supa]

Do you remember problems something as basic as keyboard?

I certainly have no problems remembering how they recently broke the keyboard in many LG laptops.

Re: It freakin' works fine

[Gr8Apes]

No kidding. Linux in its 0 and 1.x version days was a hobbyist activity, requiring more than a little work and understanding to get going. Slackware was awesome when it came out, but even then it was less than straightforward unless you happened to have just the right hardware (that phrase sure sounds familiar, Solaris, Windows, OS/2, OSX all have/had similar issues)

Re:It freakin' works fine

[mattventura]

I couldn't care less that systemd exists. If you don't like something, don't use it. I use it on a laptop for the fast boot time, and it works fairly well there, but there's enough legitimate complaints about systemd that we need alternatives.

The problem is that other things are starting to depend on systemd. GNOME being the worst offender. Not that I use it, but who knows what DE could depend on systemd next. It's like being told that if you use bash, you must use emacs.

Re:It freakin' works fine

[Anonymous Coward]

Ask Slashdot - Can you say something nice about Slashdot Beta?

It lets me switch to Slashdot Classic.

Re:It freakin' works fine

[QuesarVII]

And how do you stop all those mounts if you want to? There is no more netfs initscript on RHEL7 - if you want to stop all nfs mounts, you have to do them 1 by 1, with "systemctl stop mountpoint.mount".

Re:It freakin' works fine

[Zeromous]

I don't use automount because it is flakey. Admittedly this seems to be a solved problem on Ubuntu. But on RHEL7, you best be using automount or you are going to have a bad time. But with solutions like this, who needs problems? It will be the first of many RHEL6 it is.

Re:It freakin' works fine

[Zeromous]

> Let the good people who develop your distro worry about these hard parts.

I needed RHEL7 in January. It sort of works in November. I work in devops and know better than anyone developers can not be trusted to sort the shit out for us.

Re: It freakin' works fine

[BitwizeGHC]

I don't think you'd find any proponents of EBCDIC who didn't wear a blue suit and have a six-figure salary riding on the continued use of IBM mainframes.

Re: It freakin' works fine

[BitwizeGHC]

The Amiga: the Lamborghini Countach of computer hardware. Sexy, innovative, considered pure awesomeness in its day... but stuck forever in the 1980s in terms of design and engineering.

Re:It freakin' works fine

[TechyImmigrant]

I one tried to get MythTV to work with Pulseaudio.

There may be unsolved crimes from that era, but I couldn't tell you if it was me. I had my memory of that time wiped to save me further anguish.

Re:It freakin' works fine

[ChrisMaple]

About 1 time out of 50, pulseaudio just doesn't work - no sound - and the system has to be rebooted (although I suppose killing the daemon and starting it again would suffice.)

PulseAudio Multiband EQ runs about 10 minutes and slowly starts distorting more and more severely. it's as if it were building up a DC bias and running up against a limit.

Re:It freakin' works fine

[doom]

Clearly if the OP really wanted to talk about systemd, he should've asked people to talk about pulseaudio.

Re:It freakin' works fine

[grcumb]

Thanks for at least being honest.

"Because I, personally, was not consulted about this change, I'm outraged on the internet and will wage a holy war of FUD."

You do get that the FOSS community is in its very essence about consultation? That consultation and cooperation are the only fucking way this whole fucking open source thing is going to work?

Yes, people get shirty when their input is ignored. No, it is not fucking FUD when we say, 'You have no right to ignore the complaints of roughly half of everyone who actually gives a shit about this topic.' It is not FUD when people highlight at length and in detail the many, many ways that systemd's design sucks.

Maybe systemd will get better. Most software does. But until its developers grow up enough to actually argue the thing on its merits and not simply to dismiss every criticism as aversion to change, it's going to face strident opposition.

Re:It freakin' works fine

[unrtst]

Here's an idea. Rather than bicker about this point (parallel startup with dependency resolution versus manually ordered one at a time startup), could some nice systemd dev add support for (or show an example of how to do) startup the old way using systemd?

Given that systemd has (presumably) good dependency resolution, it should be not only possible but somewhat easy to define start up job dependencies such that they run one at a time in order. For example, add a bunch of units (or whatever they're called) that are just 001 - 999 and each depend on the former (so 999 depends on 998, 998 on 997, ... 002 on 001). Then, for each actual unit that does stuff, give it one dependency of the numbered startup where you want it to run (ex. sysstat depends on 001, lvs2-monitor on 002, iptables on 008, network on 010, etc).

There's probably a better/easier way to do that, but I imagine something like that would work. Having this option/example would take care of at least this concern from systemd adoption.

As a side note, this comment of yours is BS:

if understanding the dependencies is too hard for you, don't re-order them. You should not need to, it is not a normal part of system administration or software development.

If I write some daemon, I'm going to have to get it started with the system (and yes, I've written several, and it used to not be uncommon for users to do this). Under traditional sysvinit systems, something like a simple symlink to the right /etc/rc3.d/SNNservicename and I know exactly when it'll start. Yes, one could figure out the dependency tree and put it in the right place in systemd. While that's probably not all that difficult, it's certainly more difficult than "ls -1 /etc/rc3.d" and looking at the sort order.

Re:It freakin' works fine

[thegarbz]

what pulsed solves is not very important problems, for me at least.

Of course, and that's kind of the problem. It's a "there's no benefit for me so why did they bother at all" type of discussion. It always has been. I find myself often adding / removing audio devices on the fly, typically headsets. On my Windows desktop I also have speakers, headphones, and a DAC off on the other side of the house constantly plugged in. It doesn't matter what I'm doing, if I'm making noise in one place I can hit a keyboard shortcut and redirect sound uninterrupted to headphones or to another set of speakers, and I've been doing so for a good 6 years now. On the flip side I remember breaking X one day when I plugged some headphones in. ALSA did something while X was playing sound and it was Ctrl+Alt+Backspace to get the system working again.

Re:It freakin' works fine

[thegarbz]

AKA the "I like PulseAudio because I coincidentally owned the hardware it actually supported well" comment.

As opposed to I had a driver bug so the entire system must be incredibly shit comment? Based on that it's a wonder people ever used Linux. Heck in the 90s and early 00s I don't think I ever witnessed a Linux system boot up and support every piece of hardware correctly.

I also have never had a problem with Pulseaudio. On the flip side I've had ALSA take down X quite hard one day so in my opinion Pulseaudio is better an ALSA simply isn't ready for the primetime yet. How dare they release imperfect software.

Re:It freakin' works fine

[thegarbz]

"works fine" is the minimum acceptable level for an init system.

And yet people claim it doesn't. By all accounts if I follow what the slashdot comments say by simply installing systemd I should give up any hopes of ever getting my system to boot without sacrificing my first born.

The "works fine" comment puts it well above what others seem to consider the status quo so it certainly is post worthy.

Re:It freakin' works fine

[Aighearach]

systemd setups in the wild still load the SysV init scripts. They didn't go away. Just delete the systemd symlinks, and install the old scripts. No problem. FUD cleaned.

But it requires knowing enough about the distro you to choose to set it up the way you think you want it. So it doesn't really help him.

Re:It freakin' works fine

[elgaard]

I totally understand why people bother making functionality, I do not need. And I like it, because it means that next time I need something it is probably already there.

What I do not like is that I am being forced (well, pressured, it *is* free software after all) to pay (with computer ressources) for something that I do not need.
 

Re:It freakin' works fine

[ewhac]

Think back to the epic holy wars of the past. Emacs vs. Vi. Big vs. Little Endian. Motorola vs. Intel. Amiga vs. Atari ST. ASCII vs. EDBIC.

vi*. Little-endian. Motorola. Amiga. ASCII**. Obviously.

(* with great respect to those who are able to use EMACS well.)

(** Seriously, who not using punched cards ever actually liked EBCDIC?)

Re:It freakin' works fine

[CaptQuark]

BCD is the only way to compute!!!

~~

Re: It freakin' works fine

[Cederic]

Because storage.

Next?

Re:It freakin' works fine

[Peter H.S.]

Newer versions of GNOME (3.8 and after?) rely on a DBus API of systemd's logind component, for reasons I've never seen adequately explained.

The talk of forcing all cgroup interactions to go through systemd would in effect make anything that interacts with cgroups or cpusets such as hwloc, TORQUE, and SLURM rely on systemd. I can't imagine that the developers of hwloc, TORQUE, and SLURM are especially happy about that.

That there can only be one cgroup manager at the time is caused by the cgroups developers decision to make a unified hierarchy tree with only one canonical manager instead of exposing cgroups fs directly to end users. systemd is just an example of such a manager. If you don't use systemd, you can just use another cgroups manager instead.

Regarding SLURM, they are of course starting to integrate systemd in their project. I assume most other cgroups projects are doing the same.

Re:It freakin' works fine

[petteyg359]

The problem with systemd and its supporters like you is that you think change and progress are the same thing. This change is regress.

Re:It freakin' works fine

[kthreadd]

Then why are all major distros either in the process of switching to systemd, or have already done so? They must be complete morons switching to something that is just pain and suffering!

Re:It freakin' works fine

[AdamWill]

Um. What? Display DPI is nothing the system init daemon cares about and never *has* been.

It can be set at the X level or at the desktop environment level. Some desktops respect X's setting, some ignore it.

In GNOME you can set both text scaling and full display scaling (the new thing used for hi-dpi screens) in GNOME Tweak Tool. Text scaling is in Fonts, it's the 'Scaling Factor' - if you think about things in DPI terms, just consider the 'scaling factor' to be a multiple of 96, e.g. if you want to set 110 DPI, set it to 1.14.

If you mean GNOME's decided your display is hidpi and starting scaling *everything*, that's the 'Window scaling' setting on the Windows tab, set it to 1 (which is no scaling).

Again, none of this has the slightest thing to do with init.

Re:It freakin' works fine

[Lodragandraoidh]

It's like being told that if you use bash, you must use emacs.

I thought that was a given?

Re:It freakin' works fine

[Polo]

decimal math is orthogonal to ebcdic.

Re:It freakin' works fine

[ratboy666]

The init system launches the X server. I guess because /etc/inittab has instructions on setting "targets" for systemd.

Re:It freakin' works fine

[AdamWill]

well, ultimately the init system launches *everything* if you take a broad enough view of things, but that doesn't mean the init system is somehow responsible for your desktop environment's display configuration.

I mean, if you're really determined to, you can 'configure' things by modifying their init scripts, sure, but it's usually not the right way to do it. X has a perfectly good configuration system already. So does GNOME. If you want to change the DPI at one or other of those levels, go configure it through their configuration systems. That's how it's supposed to work.

Re:It freakin' works fine

[thegarbz]

What I do not like is that I am being forced (well, pressured, it *is* free software after all) to pay (with computer ressources) for something that I do not need.

How so? There are still distributions that don't have systemd. There are also some distributions talking about forking so you have two choices.
It sounds like you're more angry at open source politics than systemd or Pulseaudio.

And rightfully so too. Linux never was a democracy, it's tyranny of the capable coders.

Re:It freakin' works fine

[Aighearach]

I didn't advocate against understanding your computer, I advocated against complaining about not understanding it if you're not competent to understand it. Don't ask that the capabilities be minimized so it is easier to understand. Nerds should succeed at understanding, others probably shouldn't bother. And if they really want something easier to understand, something that intentionally is less capable, they should seek that from a niche hobby OS and not the world's main server OS.

Re:It freakin' works fine

[elgaard]

I am not angry. Just slightly annoyed sometimes.
Not alle software projects and distribution packages are created equal. Some are more impressive than others.

It is overkill to switch to another distribution because of something that can be handled with an apt-get remove.

Re:It freakin' works fine

[thegarbz]

As I pointed out to someone else, the closer you get to the core of your system the harder it is to maintain complicated packages in the distribution. This is especially true for kernels, init systems, logging systems, hardware interfaces etc. For every additional package you maintain you have an additional 2 things you need to do. I.e. for the Init system you need to maintain sysvinit. If you make systemd optional you need to maintain sysvinit, systemd, write all your init scripts twice (much easier for systemd than sysvinit) AND maintain an installer option which can intelligently switch between and resolve required dependencies (i.e. make jounald the primary logging system and rsyslogd optional).

At some point you get too complicated for an apt-get remove command and the distribution needs to make a decision on which path to go down. Debian politics pushed them down a path many disagree with. The options are switch distros or fork. It looks like the fork option is being strongly considered, and that is not necessarily a bad thing. I still think Mint is now a better distribution than Ubuntu. It's not like starting from nothing.

Re:It freakin' works fine

[petteyg359]

The major distro I'm using, which is included in "all of them", has absolutely no requirement for me to use systemd, nor is it the default init system. So, why is it that you think "all of them" are switching? Sounds like more blind promotion of change for the sake of change.

Re:It freakin' works fine

[binarylarry]

You may take our life, but you'll never take our init scripts!

Re:It freakin' works fine

[binarylarry]

I do it all the time, most modern apps use threads in a variety of ways.

Learn to code, grandpa.

Re:It freakin' works fine

[DrXym]

ASCII digits aren't much harder to use for BCD than EBCDIC. In ASCII the digits would be 0011NNNN and in EBCDIC they're 1111NNNN as binary. Assuming you masked off the top 4 bits it would be the same code to do BCD with either.

Aside from digits, EBCDIC is infamous for it's bizarro alphabet layout which wasn't contiguous so code patterns like "if 'a' I suspect the EBCDIC only existed because IBM being IBM couldn't countenance interoperability with other systems and therefore tried to ringfence and enforce its own format.

Re:It freakin' works fine

[DrXym]

Gah second para was supposed to say - if 'a' is_less_than c AND c is_less_than 'z' then ischar = 1' as an example of where EBCDIC would break horribly and it only gets worse with stuff like rot13, crypto etc.. Slashdot gobbled up the less thans and truncated that sentence.

Re:It freakin' works fine

[samwichse]

Make sure all users are members of the 'pulse-access' group, and enable system mode in /etc/default/pulseaudio and reboot

Re: It freakin' works fine

[LWATCDR]

The Amiga had the same CPU, better audio and graphics than the ST. The ST was a much better machine than the PC at the time and honestly the Mac.
The issue that both the Amiga and ST had was IMHO they where not designed well for business.
The Amiga 1000 should have had a slot for an HD controller and 512mb on the motherboard with sockets for another 512mb of ram.
The ST was built as a "home" computer and also lacked a lot of the expansion that was needed to make it a real business machine. Businesses wanted a machine that you put on your desk not one with a bunch of external boxes of stuff like hard drives.
The Amiga was also badly hurt by Borland when they failed to deliver TurboPascal for it like they promised at launch.
Two great machines that failed because of marketing.
Commodore and Atari should have really pushed for Lotus,Borland, Aston-Tate, and other PC software makers to port to the Amiga and ST.

Re:It freakin' works fine

[mrex]

Nice try, Lennart.

Re: It freakin' works fine

[macinnisrr]

If you loved sysv init scripts, writing a script to unmount all NFS mounts should be pretty easy.

Re:It freakin' works fine

[macinnisrr]

For pro audio we use JACK, so you wouldn't need pulseaudio there either. I do find it handy when switching between hdmi and onboard on my laptop, however.

Betteridge's law of headlines

[Anonymous Coward]

Betteridge's law of headlines is an adage that states: "Any headline which ends in a question mark can be answered by the word no.

Is this the right headline to apply it on?

Re:Betteridge's law of headlines

[marcello_dl]

Except that "Can you say something nice about X?" is a defensive question.

Re:Betteridge's law of headlines

[Aighearach]

Well, slashdot is a blog about news, not news, so the Law doesn't apply.

And in the news, headlines do ask real questions, and the reason the answer is always no is that if the answer is yes and it is news, there is no need for the question. Example: "Did City Council Pass New Law?" "City Council Passes New Law" When the answer is yes, the gimmick reduces the import of the story, while at the same time encouraging the reader to question if the reporter even knows the answer.

When the answer is no, that almost always means there is no story. It is the nature of news; it is about what did happen much more than what didn't happen. So if nothing happened, you can get some percent of people who are interested in the topic to read the story by phrasing it as a question. Many of those people would not read it if it said, "Nothing new to report; details follow." In this world of online advertising and click-metrics, the question-as-headline has increased in prominence, but the semantics haven't changed at all.

The Ask Slashdot I'd like to see is, "Can you say something bad about systemd that is both objective and true?" And then the answer would be no, and you'd have to read a bunch of subjective nonsense and lies to find that out. ;)

No.

[stooo]

No, we can't.

Re:no.

[beh]

Question: How much of that complexity can you hide from the normal user? Or - how much of that complexity is even visible to the normal user?

Complexity often comes into two parts - the complexity for the developer or admin; and the complexity for the end-user.

If I use a Mac Desktop, you can bet I don't give much of a toss over how much extra work that might mean for a developer - as long as my user experience is better.

Do you drive a car? ...despite over how much more complex it is than, say, a horse-drawn carriage?

Re:no.

[thegarbz]

Yeah I never liked X or the kernel either.
Both are massively complex.

  But neither are anywhere near as complex as grep/sed/awk. Man I'll happily install systemd on any machine just not to have to trawl through logfiles using some bastardised recollection of how to write regex.

Re:no.

[thaylin]

And how many linux users are not power users who will have to see the complexity no matter what? I would say the vast majority.

Re:no.

[sjames]

Have you ever tried to overhaul a horse? They disassemble just fine but you can never get them put back together right.

Out-of-the-box babysitting of processes

[olau]

I like that in the future when the integration is more complete, I'll be able to install a database or a webserver and then once in a full moon when a cosmic ray hits the process and kills it, systemd will just restart it.

Yes, you can do that with other tools too once you've learnt your lesson (many years ago I had 1.5 year uptime with Apache and then it suddenly crashed) and I am using one of those at the moment. What I like is that this will just work out of the box for newbies and veterans alike with no clunky configuration/interfacing.

Re:Out-of-the-box babysitting of processes

[Deagol]

Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.

Firstly, if I'm properly monitoring the process, then I'll be alerted and can investigate.

Secondly, there may a *reason* the process goes down, and having it down may be a good thing. If someone's trying to fuzz our httpd process for exploitation, then it happily restarting will open up a wider attack window.

Autopilots on production servers seem like a bad idea to me.

Re:Out-of-the-box babysitting of processes

[morgauxo]

A long time ago I used to do that with inittab. And then suddenly that was wrong, we weren't supposed to use inittab anymore, everything was supposed to bin in an init script.

Whatever

Re:Out-of-the-box babysitting of processes

[Anonymous Coward]

No.

Availability is King my son.

Business does not care about your nonsensical need to manually intervene with a crashed process.

Re:Out-of-the-box babysitting of processes

[thegarbz]

Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.

I have the opposite view. If something goes down:
1) I want to know about it. I want some monitoring system to send me an alert of some description.
2) I want it set up in a way that it won't clobber it's own log files. Preservation of the reason something failed is key.
3) I want it to automatically restart if possible. I say if possible because I want to avoid a re-start loop but if something goes down and comes back up then the end user is happy as uptime is maximised and providing criteria 1 and 2 are met I'm no worse off as an admin. Believe it or not random crashes may sometimes happen and may have nothing to do with the config or the system itself. I may be caused by some edge case that was hit by a user, and in those cases I am unlikely to find the problem quickly and in the interest of not limiting user access would be inclined to get the system up and running as quickly as possible and then sort through the log history into what the actual problem was afterwards anyway.

Re:Out-of-the-box babysitting of processes

[nine-times]

Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.

I'd want to have the option, but for the default behavior to be that it stays down. I feel like unfortunately, unless you've lived a charmed life where you only have to work with software that's high quality, you will probably run across some server running some piece of crap software that can be a bit crashy. Yes, I've run across software like that on Linux servers too. And personally, ideally, I like to have the easy ability to control what happens when something crashes. Should the server ignore the whole thing and keep chugging along? Should it attempt a restart? Should it wait 10 minutes, and then attempt a restart? If the attempted restart fails, should it make a second attempt? At what point should it notify me?

I like when I can have control over that kind of thing, if possible, and I'd like to have that control be easy and reliable.

Re:Out-of-the-box babysitting of processes

[Procyon_the_Dragon]

Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.

Firstly, if I'm properly monitoring the process, then I'll be alerted and can investigate.

Secondly, there may a *reason* the process goes down, and having it down may be a good thing. If someone's trying to fuzz our httpd process for exploitation, then it happily restarting will open up a wider attack window.

Autopilots on production servers seem like a bad idea to me.

Right now there is no remote monitoring of services within systemd, but this can, for sure, be changed. One could write a daemon for systemd that monitors all the services that are started or should be started and send some notification to the admin's desktop system, possibly including the latest log output and other stuff. This could extend current monitoring systems. If a process locks but does not exit, systemd would not notice, but a "pinging" monitoring system would, because it checks availability of a service every one minute, for example.

Re:Out-of-the-box babysitting of processes

[RabidReindeer]

Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.

The problem here is that in complex production environments, servers are not atomic units. Obviously, if the network is down, apache cannot run, but just because the LDAP server is out of commission, that doesn't mean that webapps that don't use LDAP cannot continue to run.

That's the potential of systemd. To ensure that a process that cannot operate except when other processes that is depends on are OK.
'

Firstly, if I'm properly monitoring the process, then I'll be alerted and can investigate.

Secondly, there may a *reason* the process goes down, and having it down may be a good thing. If someone's trying to fuzz our httpd process for exploitation, then it happily restarting will open up a wider attack window.

Autopilots on production servers seem like a bad idea to me.

In larger shops, uptime, even with warts is preferable to downtime. If a service goes offline, they want it online ASAP and you can do the post-mortem at your leisure (just don't expect to be allowed any leisure - those executive bonuses got to come from somewhere). Furthermore, as I mentioned, systems are often a network of processes, not just a single process, so having one process go down may require taking dependent processes offline. Conversely, when a subsystem comes back up, it's better that the dependents automatically follow it back up rather than requiring you to chase around and restart them all manually. That's where sooner or later, one of the restarts gets missed. Until someone important misses it.

OK. I've said something in favor of "systemd". The problem is, systemd isn't really one conceptual product, it's systemctl and journalctl. Systemctl I'm OK with. Journalctl can die in fire. Any votes in favor of "systemd" on behalf of systemctl should NOT be considered as endorsement for journalctl.

Re:Out-of-the-box babysitting of processes

[olau]

Autopilots on production servers seem like a bad idea to me.

I once thought the same. But investigating with a "OMGF!!! THE SERVER IS DOWN!!!!" over my head just doesn't work well in practice - so I tend to end up restarting the service anyway, in which case the difference between a program doing it and me is just loss of availability (and worse working conditions for me).

Have you ever found any practical advantage of doing this manually?

Re:Out-of-the-box babysitting of processes

[Deagol]

Quickly respawning processes that die is not HA. Clustering and fail-over at the application and hardware layers is HA.

A flapping service can cause more customer-facing downtime or irritation than a permanently-down service that's failed over gracefully at the appropriate layer.

Re:Out-of-the-box babysitting of processes

[walterbyrd]

> and then once in a full moon when a cosmic ray hits the process and kills it, systemd will just restart it.

What if it happens more than once in a blue moon? What if there is a serious problem, and it happens all the time?

I think most sysadmins would rather be notified, so they can fix the underlying problem, rather than have a broken process constantly restarted.

Re:Out-of-the-box babysitting of processes

[walterbyrd]

If a service is all that critical, shouldn't you have parallel servers? And would that mean that there is not good reason to auto-restart a broken service?

Re:Out-of-the-box babysitting of processes

[psmears]

If a process locks but does not exit, systemd would not notice,

Apparently systemd has support for a watchdog function for services, so it could potentially notice this (though the service needs to have support for it).

Re:Out-of-the-box babysitting of processes

[Aighearach]

Often true, but there is always some bottleneck. If I have a database cluster, it is probably a bottleneck, and if a database node appears to have some sort of OS screwup, I mostly don't care; if it repeats I want to fix it. But getting the node back up quickly is a bigger deal unless the same problem repeated itself. The database can already handle keeping its data from being corrupted, getting the node back up quickly only affects the cluster load. And in that sort of case, I really might not care to "fix" whatever part of the OS that crashed. It may be that an OS update will fix the problem, and the best solution is to set up a new cluster node master image.

For me that is the most often transient error situation; secondary software rarely hits a known bug, and updating the right package will make it go away; nothing was ever wrong with the actual server software that I care about. Where there are multiple front/back ends and high availability techniques, this stuff can usually be dealt with however often you change your distro. Maybe every couple years! On a small setup or single server, then you can just fix it right away, no problem.

On large systems if you're ready to chase any transient error down a rabbit hole, you'll be buried in them and blaming your boss for not hiring 1000 sysadmins. ;)

Re:Out-of-the-box babysitting of processes

[SharpFang]

Of course _most_ sysadmins would rather have the best of both worlds: be notified of the problem, and have the process restarted ASAP if that was one-off, but not over and over, if the problem persists.

Of course systemd can't do either of these.

Re:Out-of-the-box babysitting of processes

[Evan Langlois]

This is possible without systemd. The difference is that without systemd you get a choice.

Re:Out-of-the-box babysitting of processes

[strikethree]

I like that in the future when the integration is more complete, I'll be able to install a database or a webserver and then once in a full moon when a cosmic ray hits the process and kills it, systemd will just restart it.

I wonder when that future will be. It certainly does not keep nessusd running. That is what kills me about all of this: The shit just isn't reliable and some people still want to jump on it as some sort of standard immediately. Just insane.

Re:Out-of-the-box babysitting of processes

[mvdwege]

You don't have to write a very complex daemon to do that. Just write a dbus listener that subscribes to service start events on the system bus. I could do something like that in about 2 hours with a few lines of Perl.

In fact, on a discussion list for 'Linux Experts' I provided one such script in 30 minutes when someone asked for a way to react to new devices being added to the system.

Nice Thing: systemctl status shows you log entries

[db48x]

If you have a service called 'foo', then 'systemctl status foo' not only shows you whether the service is running, it also shows you the last 10 log entries created by that service. This is great when the service failed; usually the error message will be right there.

How does it do this? Well, because all processes created by the service are in the same cgroup, all of the log messages (and even anything they print to stdout, which would have been lost otherwise) can easily be tagged with the service name (and a bunch of other metadata). You can use journalctl to query the journal for the logs from a specific service, and systemctl status does this for you.

Sure.

[Anonymous Coward]

Okay, I'll play along: Systemd was the final straw that made me switch my Linux servers to FreeBSD.

See, was that so difficult?

Re:Sure.

[stooo]

Or even better : The nice thing is systemD is not portable. It will infect only linux.

Re:Sure.

[jbolden]

Nope: https://uglyman.kremlin.cc/git...

Re:Sure.

[TheRaven64]

I came here to post something similar. We've seen a load of switchers over in FreeBSD land as a result of systemd, including one company that's currently a moderately large RedHat customer and plans to migrate before their current support contract expires.

Re:Sure.

[ChrisMaple]

The nicest thing about systemd is that not all distros have it yet. I can't afford the risk of a failed install on my current Fedora, but my next computer will probably be Slackware.

Excellent Tower of Hanoi solver

[Anonymous Coward]

Using the information gleaned from this year old bug I was able to create a Tower of Hanoi solver using the dependency resolver's attempts to determine whether a NFS filesystem should be mounted after the network comes up or not. Every attempt to start Apache (which depended on the filesystem) represents moving a disc to the middle tower.

Re: Excellent Tower of Hanoi solver

[Anonymous Coward]

So would I.

Re: As long as it works

[Anonymous Coward]

Most Linux users care what they run. Users who don't care run Windows.

It's thought-provoking!

[Anonymous Coward]

Great conversation piece. Really gets people talking.

Re: Where do you think you are?

[Anonymous Coward]

just ignore the rules. Why are you even bother by it?

Re:Nice Thing: systemctl status shows you log entr

[ledow]

My problem with things like systemd is not that they have nice features - lots of things have nice features. Windows' Shadow Copies is a lovely feature that's a lot easier to configure that some alternative equivalents, etc.

It's that they put those nice features into some new paradigm of configuration when you could have just added them to the existing system.

Reliable servers don't just crash

[Anonymous Coward]

Reliable servers don't just crash. This is the Windoze (C)(TM) method of reliability by restarting. Defensive nanny processes are a hack and hardly unique to systemd. They invariably result in trying to restart a broken configuration 1000 times in a row. Death to systemd.

Re:Reliable servers don't just crash

[olau]

Reliable servers don't just crash.

Obviously you haven't learned your lesson yet. Hardware failures happen.

Re:Reliable servers don't just crash

[OzPeter]

Reliable servers don't just crash.

Thanks for reminding me .. I always forget to add this to my source code:

#define RELIABLE

Re:Reliable servers don't just crash

[nine-times]

Well no, he's right. It's just a tautology-- reliable servers don't crash. It's kind of like, "No daughter of mine is going to get pregnant out of wedlock!" I can say that as long as I'm willing to disown any that get pregnant out of wedlock. If she gets pregnant, then she's no longer my daughter.

So reliable servers don't just crash, but unfortunately a large percentage of the servers out there that, for one reason or another, aren't 100% reliable. I sure wish I had software that would work well on those.

Re:Reliable servers don't just crash

[LWATCDR]

Actually that statement is 100% correct since the definition of a reliable server is one that does not crash.

Re:Reliable servers don't just crash

[Barsteward]

and if your text file logs get corrupted or deleted?? shit happens, any files can get corrupted. At least with journald you can have logging done just binary, just text or both types simultaneously, configure it for both if the possibility of corruption worries you. What do you do if your text logs get completely deleted or corrupted due to some failure or bug?

Re:Reliable servers don't just crash

[AqD]

You're NOT getting it.

The whole point of systemd is NOT to improve what you're already running NOW, but to pave the way for FUTURE possibilities - what you couldn't have done yet due to the lack of it.

There are a number of things that architecture like systemd's could be found very useful, more on complicated application servers and their developers (tomcat, mono and a number of FastCGI-like providers and their dependencies like memcached) and ordinary users (applications as services; IME and desktop widgets). If they do it well, people would definitely find more uses of it. If it's bad, at worst it ends up like svchost.exe.

You're like a guy who complains learning to pilot ships is overcomplicated and pointless because you never need any vehicle other than bikes to go where you want.

Re:Reliable servers don't just crash

[Karzz1]

At least with journald you can have logging done just binary, just text or both types simultaneousl

False. You cannot log only to text with systemd. And who wants twice the I/O (binary and text) to appease the systemd folks when text logs have been not only the defacto standard, but a rudimentary part of the UNIX philosophy. There are several other reasons I don't like systemd ( try to chroot to a broken system and tell me how much fun that is if the system is a systemd system ) but binary logging with no text only option is arrogant and a show stopper for me as well.

Re:Reliable servers don't just crash

[MerlynEmrys67]

No - this only happens in Windoze(C)(TM) boxes - never in a highly engineered server. Oh wait - with memory densities as high as they are in the large systems, maybe it does. These are once in a decade kind of problems. I remember hearing about Sun's early research on this problem... Defect started with Sunfire 25K servers crashing frequently in Denver (frequently was defined as more than once a month).

Re:Reliable servers don't just crash

[kthreadd]

It's not like the journal format is some state secret. It's documented and there are already several journal parsers to choose from.

Re:Reliable servers don't just crash

[Karzz1]

It's not like the journal format is some state secret. It's documented and there are already several journal parsers to choose from.

Which does absolutely nothing to remedy the issues I have with systemd logging. But thanks for playing.

Re:Reliable servers don't just crash

[Karzz1]

And your solution 1). offers absolutely no benefit to me 2). does not exist yet

There are hundreds or thousands of tools in the UNIX userland that have been written to interact with text files. Why re-invent the wheel?

I do not want binary logging and with systemd I have no option. I have many other issues with systemd. I, like many many other people, do not want systemd.

Re:Reliable servers don't just crash

[Aighearach]

I have a reliable computer. It has been dead for 15 years with no signs of becoming bootable. Any software designed for this system can work perfectly, with 100% reliability, forever.

Re:Reliable servers don't just crash

[Aighearach]

Yeah, make sure to write tests for every possible seemingly-random bit flip that could happen on any supported system configuration.

Re:Reliable servers don't just crash

[sjames]

And if it goes down on a hardware failure, restarting the process isn't likely to fix it.

Re:Reliable servers don't just crash

[rahvin112]

Your option is the exact same option you have now which is to start syslog and let it capture text logs just like it does now. I fail to see how it is a demonstrable bad thing that you have a binary log being created as well.

Re:Reliable servers don't just crash

[dnavid]

Actually that statement is 100% correct since the definition of a reliable server is one that does not crash.

Its trivially easy to make server software that doesn't crash. Just send all exceptions into an infinite loop. I think not crashing is a common prrequisite, but far from sufficient requirement for a reliable server. In fact, for some software like filesystems and databases crashing is almost not relevant to reliability: crashing to prevent data corruption is what reliable systems do in some contexts.

"Reliability" is when the software does what it is designed to do. That can include protective crash dumping. "Availability" is when the software is always running. Well designed and implemented software is both reliable and available, which is another way of saying its always running, and always running correctly.

Re:Reliable servers don't just crash

[Karzz1]

Just how useful these features are depends on the user. The usefulness of these features does not outweigh the fact that *I DON'T WANT BINARY LOGS*.

I wish you pro-systemd people would please quit telling me what I do and do not want. Systemd offers me almost no benefit but does disrupt many aspects of my systems *FOR NO BENEFIT TO ME*.

If this is good for you, please, by all means, use systemd. But leave me the option to not use it. You do not know what is best for me and I didn't ask for your opinion. I especially did not request that my options be limited by a group that is as controversial as the systemd folks.

Re:Reliable servers don't just crash

[Peter H.S.]

At least with journald you can have logging done just binary, just text or both types simultaneousl

False. You cannot log only to text with systemd. And who wants twice the I/O (binary and text) to appease the systemd folks when text logs have been not only the defacto standard, but a rudimentary part of the UNIX philosophy. There are several other reasons I don't like systemd ( try to chroot to a broken system and tell me how much fun that is if the system is a systemd system ) but binary logging with no text only option is arrogant and a show stopper for me as well.

Of course you can have text only log files. Just tell journald not to make any journal files, and forward log messages to rsyslog. It is trivial to do.

Btw, did you know that rsyslog was started because of the inherent limitations of flat text files. These limitations is why all Unix/Linux Enteprise central logging solutions involve some kind of database (Splunk, rsyslog with db-driver modules etc).

Really, systemd's logging solution is seriously cool. It is worth a serious try out.

Re:Reliable servers don't just crash

[Karzz1]

In high-load servers logging can be quite disk intensive. Effectively doubling that I/O can be extremely detrimental to the performance of the machine.

Re:Reliable servers don't just crash

[knorthern knight]

> It's not like the journal format is some state secret. It's documented
> and there are already several journal parsers to choose from.

Please explain http://lwn.net/Articles/468049...

> From the FAQ:

> Will the journal file format be standardized? Where can I find an explanation
> of the on-disk data structures?

> At this point we have no intention to standardize the format and we take the
> liberty to alter it as we see fit. We might document the on-disk format
> eventually, but at this point we donÂ't want any other software to read, write
> or manipulate our journal files directly. The access is granted by a shared
> library and a command line tool. (But then again, itÂ's Free Software, so
> you can always read the source code!)

Re:Reliable servers don't just crash

[Peter H.S.]

> It's not like the journal format is some state secret. It's documented
> and there are already several journal parsers to choose from.

Please explain http://lwn.net/Articles/468049...

> From the FAQ:

That LWN article is 3 years old and very outdated. The systemd developers was still developing the journald in those days, so they didn't want to freeze the API etc. it until they thought it was ready.

The journald log file format have been stable for a very long time now. Here is the developer info and documentation:
http://www.freedesktop.org/wik...

There are already independent journald readers and several log watch programs that query the journald directly.
Most tellingly; rsyslog can now read systemd journals directly. No need to forward syslog messages to it anymore if you use it as a log sink. It can read and write journald log files directly.

Here is a list over stable API's in systemd:
http://www.freedesktop.org/wik...

positive comment about the name

[Anonymous Coward]

Starts with "system", ends with "d".

How about "I couldn't care less."?

[Qbertino]

Seriously, I've been a Linux Guy since the 90ies and I honestly couldn't care less.
Anything I know about init is about runlevels - and those are a really neat thing. I mean really cool. You can fiddle with those using mc (Midnight Commander) and debian has a stack of 4-6 of those preconfigged and set up by default - last time I checked, some 7 years ago or something anyway.
Point is, my grandma can set up a runlevel that ex- or includes the LAMP stack in it's 'launch', 'init' or whatever-it's-called sequence and I can set my box to it by typing "init [simple Int here]" for my box to go there.

Again, that is pretty neat and cool and the best working solution I've run into so far.
Way better than anything in the Windos world, that's for sure.

If this "systemd" thing - whatever that is - doesn't break this or offers a neater improvement on that runlevel stuff or a way better concept that's worthwhile moving into, perhaps like the SVN vs. Git thing in which Git comes out on top IMHO - without requiring some bullshit GUI tool to be usable, that's all very fine and dandy with me.

If, on the other hand, you're going to push this new fad and hurt me wile doing so, I'm coming for you some time in the future. With a baseball club and my mafia friends. Other than fucking around with one of the best filemanagers ever - Konqueror - and replacing it with an inferior dolphin - this isn't some GUI toy you should fiddle with. This is Linux at a level where it's actually *the* industry standard. As in 'no other even comes close to this level of reliability and quality". Fucking that up would be a really stupid idea.

Otherwise I really positively couldn't care less - and that's how it should be, no? Except for, maybe, if I were a System Developer or Distro Release Manager or something.

My 2 cents.

Re:How about "I couldn't care less."?

[ichthus]

In regard to your sig, it's "baseball bat", not "baseball club". Have a nice day.

Re:How about "I couldn't care less."?

[grcumb]

In regard to your sig, it's "baseball bat", not "baseball club". Have a nice day.

No, he means 'club'. The Mets frickin' hate systemd.

Re:How about "I couldn't care less."?

[prsephton]

That's the sort of apathy which could smile at you gently until it turns around and kicks you in the teeth.

Systemd changes a lot of things you take for granted. If it kept everything the same, no-one would be complaining, but then again there would be no reason for it to exist then either.

systemd needs to stay optional

[wierd_w]

'systemd' needs to stay optional, and I mean that explicitly. optional. Not "default", and not "optional, in the sense that you then have to do the maintainer's job for them because they are too lazy to consider people not using systemd, because systemd is the default, and the maintainer does not want to consider the people that dont want systemd, regardless of the reasons or circumstances." kind of way.

Systemd is potentially useful for only a subset of the linux ecosystem, and forcing this kind of change is a bad thing.

Please allow me to explain why:

Systemd seeks to be a "Be all, end all solution to system initialization", which ultimately means that it will itself try to cover every possible thing that its maintainers believe needs to or should happen during system init. That in and of itself means that it will be large and cumbersome; exactly the things that embedded linux should avoid, where ultra-minimalism is king. (We are talking systems that have just a few dozen megabytes of memory, and just a few hundred megahertz of processor power at the most. Having all that gobbled up by the init system as soon as power is applied is not going to win you any trophies, and boldly asserting that embedded devices need to obey a desktop paradigm is throwing the baby out with the bathwater.)

This is especially true with "reference distributions", like debian. Debian "console only" deployments with tools like debootstrap are reasonably common with embedded devices, as are deployments that make use of chroots for specific sandboxed services. A chroot does not need a full blown init like systemd. It is best served with a simple init script. Building a distro with the intention of killing simple init, and replacing it with a monolithic solution like systemd will make service daemons much more difficult to control in this way, and will actually rob core functionality away from the distro that goes that route--- exclusively in favor of desktop flavored deployments.

Linux is more than desktops.

Linux is routers.
Linux is home automation systems.
Linux is servers performing specialized functions.
Linux is so much more.

Please be more considerate about trying to force systemd into debian. Optional is OK. Optional like "gnome vs kde vs xfce vs $ManagerHere". Not "optional" like "unity on ubuntu". Debian is a reference distro, upon which many other distros are based. It has already found its niche in the linux ecosystem. Please dont try to reinvent it.

Re:systemd needs to stay optional

[beh]

I may agree with your point, that systemd is only useful for a subset of linux ecosystems - but from this, deriving that it shouldn't be default seems bizarre.

The "try to cover every possible thing" aspect that you so seem to hate for servers could be a boon for people installing it on laptops; or even their normal home PC; anyone starting out with linux.
In short - this could be a boon for a lot of people coming to Linux anew and don't know init.

So, why not leave systemd in "user centric" distros like standard ubuntu ; but keep init as default in server-distros - at least for the time being - since those are usually aimed at more experienced Unix users - who already know init.

If we can keep distros with and without a graphical desktop separate - why not do the systemd / init split along the same lines - as the desktop distros need to cater to being more user-friendly and more at home on very disparate hardware setups.

As for the optional step - if systemd may be more newbie friendly, how easy will it be to switch from init to systemd? And one of those two needs to be default - but if switching around between the two is tricky, then by all means take the more user-friendly one as standard - if the user-friendly option is difficult to install, you don't need to package it at all - as the newbie at whom you might aim it is probably the last person with the technical knowledge of what the switch means or how it could be done.

Re:systemd needs to stay optional

[wierd_w]

Oh, I know this.

That is precisely why a chroot on external memory can be useful in certain circumstances (You mean that particular FS utility wasn't compiled into the busybox binary in your current system image? Well, better get creative then!), and also why something that is easy to deploy, like a debootstrap'ed minimalist core deploy, in a chroot can be handy for specialist daemons that demand real versions of tools and libraries. The core kernel lives in the tiny image that boots in the embedded system, which does all of the core init gruntwork.

A chroot is also easy to completely purge when done with it as well. A chroot can run off a network share, or any other mounted location in the filesystem.

The special daemon runs in the chroot, which is fired off as if it were a normal daemon using a simple shell script. This keeps the core image clean, and gives a sandbox in which to run something that is more demanding. Again, that other "something" does not need a full init-- the system is already up and running. A simple init script that starts things and monitors to keep them running is a perfect fit, and consumes very little extra memory or processor resources.

Re:systemd needs to stay optional

[Anonymous Coward]

Linux is routers.
Linux is home automation systems.
Linux is servers performing specialized functions.
Linux is so much more.

Absolutely, which is why I vehemently disagree with your entire argument - Systemd on embedded systems such as routers and other "Cute Embedded Nonsense Hacks" is a huge boon.

Standardising on a single init system (and getting everyone on board) would be a wonderful thing to happen for the Linux community - and no, letting those kooky server guys stick with their abomin^W init hac^W scripts isn't an answer. If you don't want systemd, don't upgrade but don't force hobble the rest of our efforts.

Re:systemd needs to stay optional

[aethelrick]

I'm running Arch Linux ARM on a Wandboard Quad single board computer. The system runs apache, dovecot, postfix and samba for a small network. Systemd is in use as it was the default when I installed the OS. The machine only uses 224M of RAM, it has 1.6G free. systemd-journald is the biggest RAM-muncher with 64M is use, but I don't mind this because it's configured to not batter the flash by keeping current logs in RAM only.

Re:systemd needs to stay optional

[thegarbz]

Linux is more than desktops.

Linux is routers.
Linux is home automation systems.
Linux is servers performing specialized functions.
Linux is so much more.

Linux is also much more than Debian. Systemd is still very much as optional as any other package on Linux. As far as I know the kernel so far has no dependency on systemd. Your fundamental complaint appears to be that Debian made a design decision to migrate to systemd.

Now what I find absolutely astonishing is that the proponents of open source are many and always talk about having choice and the ability to do what you want with a system. Now the opponents of systemd also appear to be many. If everyone really cared so much there really is nothing stopping a fork of a version of Debian to go down a different route.

Now on that as well a linux distro for embedded applications does not require most of the package management and things that distros like Debian are known for. I would have picked Debian for many things but I wouldn't have thought of it as a distro for an embedded system. And if Debian really can be lean enough to run on a tiny embedded platform then it should be utterly trivial to write your own init system or simply use SysVinit instead. And above all, if the world is really dependent on lean Linux and systemd is incompatible with the idea of a lean system then you should see all manner of distributions popping up without systemd.

After-all, that's the benefit of an open source world right?

Re:systemd needs to stay optional

[wierd_w]

debootstrap. All you need is a disk that is mounted, and access to a repository.

https://wiki.debian.org/Deboot...

The packages it installs are just the core debian console-only base system. Nothing super fancy. It can consume upwards of 300mb of disk however-- but when you absolutely NEED to get $FOO running, because busybox does not have it compiled in, or you need some special service to start, the repository access is very handy.

Again, because it installs into a user-specified directory, it is a ready made chroot ready to be jumped into. I have a debian chroot on my consumer grade wifi router, which I use for all kinds of fun things. It sits alongside openwrt without issue, and keeps the flash clean from extraneous stuff. It sits on the small USB stick I have stuck in it.

The real point I was making though, was that debian was a REFERENCE DISTRO.

It does NOT fall into the "Desktop" or "Server" category. It is "Reference". Debian is neither a really good desktop (older, more mature packages, which means spottier driver support), nor a really good server. What it is, is a good reference platform from which to BUILD a specialized distro.

Many systems are based on debian. Decisions which impact debian will impact those other downstream distros. Not all of which will be too pleased with including systemd.

Debian has its niche. Much like the argument about vi and emacs, the init vs systemd argument will not go away. That's why reference distros like debian should support both without favoritism. Any downstream distros that use them as the reference can pick as their userbase deems appropriate.

The "Remove the fragmentation!" rally cry fails to capture that "homogeneity is not always good" and is in fact, the antithesis of "choice."

Re:systemd needs to stay optional

[wierd_w]

Or, you could just mount /var with ramfs, and still not batter the flash, and not use systemd at all.

(and if you do it that way, to get the ram back, just prune the log files.)

Re:systemd needs to stay optional

[Anrego]

Standardising on a single init system

This is the thorn in everyone's side. Standardizing on anything is kinda anti-linux. We accept it as a reality for some things, but it's not something we should specifically aim for.

Re:systemd needs to stay optional

[jbolden]

I think systemd is excellent for servers, I think the wide adoption by PaaS vendors proves this. I also happen to think process management is good for most embedded systems. Because they often have less support, both human and other infrastructure being able to do internal process management is a plus. So I disagree strongly that systemd is about desktop, that's a myth.

That being said though I agree that systemd is a bad choice for low memory embedded systems. But frankly I think Debian is mostly a bad choice for low memory embedded systems. Those really do need specialized distributions and those specialized distributions exist. Certainly Debian can feed those as a parent distribution and there is no reason that for those packages which are appropriate for embedded I'd expect people to supply patches to make the package work with cheaper (in terms of memory / CPU) init systems.

Re:systemd needs to stay optional

[jbolden]

So, why not leave systemd in "user centric" distros like standard ubuntu ; but keep init as default in server-distros

Because process management is really important for servers as well. The idea that it is only useful for desktop is a myth. The direction of the Linux server ecosystem is towards PaaS and containerization. The idea is to divorce hardware from specific workloads entirely where individual boxes just becomes a node with compute and storage resources as part of a larger superserver. Essentially a shift back towards a mainframe like paradigm. Init doesn't work well there either.

There are some obvious niche cases where init is superior but they are niche and few. This isn't about ease of use. It is about the fact that Linux in the server space is now becoming something other than a cheap Unix for use in niche cases for stuff that isn't running on industrial Unixes or mainframes. Instead Linux is finally really genuinely replacing those systems and now needs to offer the functional depth they provided.

Re:systemd needs to stay optional

[aethelrick]

Yes I could do as you say, but that is besides the point. The point is that the system works and does so within the resources limitations of a single board ARM computer despite the fact it is running systemd.

Don't get me wrong, I'm not a systemd advocate, I don't have it on any of my work servers yet, but equally where I have used it, it has been stable and simple enough and I have not noticed any particular "RAM bloatyness".

I remain open minded about the whole debate, I'll use whatever comes along next as long as it is stable, simple and it gets the job done. Systemd is different to sysvinit and it takes a bit of getting used to but it hasn't done anything evil to my system (yet).

I take a pragmatic approach to this sort of thing, If you don't like, don't use it. The guys building the main distros seem to like it however so you may end up having to use it if you are a Linux admin.

Re:systemd needs to stay optional

[geminidomino]

Because process management is really important for servers as well.

So are reliable logging, minimizing attack surface, and avoiding SPOFs. The systemd developers'[0] own attitude towards these things is what's convinced me that their stuff can't be trusted. If it was *just* a new init system, that would be great -- I'd still give it some shakedown time, but I'd at least be willing to look at it -- but they decided to kitchen sink instead.

That's why I'm so anxiously waiting for the result of Ian's GR: transitioning to Debian would be less disruptive than to FreeBSD, but I have to be reasonably confident that I'm not going to wake up one day and find out that a critical apache update is going to require me to reconfigure every system from PID1 on up.

[0] Screw the users' attitudes. They're just as bad as the mundanes about making the stupidest shit into politics and some kind of personal slight on their very identities.

Re:systemd needs to stay optional

[Eunuchswear]

Does my phone count as "embedded linux"?

It runs systemd.

Re:systemd needs to stay optional

[Eunuchswear]

Linux is also much more than Debian.

Blasphemer!

Re: systemd needs to stay optional

[kthreadd]

CoreOS is not designed to be used on just one or two machines. It's designed for huge clusters where one machine rebooting it not a problem. It allows them to implement more reliable updates. You either get it or you don't, and can quickly and easily roll back to the exact same bits you used before.

Re:systemd needs to stay optional

[jbolden]

reliable logging, minimizing attack surface, and avoiding SPOFs

systemd's logging is more reliable not less.
As far as SPOFs the move to PaaS makes systems far more redundant not less. Each node is unimportant.
As for minimizing attack surface containerization and virtualization are how that's accomplished. Fundamentally that idea is being rejected in favor of dedicated security systems.

That's why I'm so anxiously waiting for the result of Ian's GR

It doesn't really matter. Ian doesn't have a solution for the problem.

Application programmer B creates a systemd dependency in application C.
Debian package maintainer D considers this a bug in the package.
B tells D to go pound sand.

Now what? Obviously if there is interest in init.d package maintainers can create scripts and add them to the package if it is no big deal, that is if the developer isn't using systemd features. Maintainers can't force upstream to do stuff they don't want to do. The example that changed people's mind was brasero. Once brasero decided to use a chain of dependencies to detect when someone inserted a CD (i.e. no user interaction) what is Debian going to do about it?

If large numbers of people from upstream are committed to systemd (and increasingly they are) Debian can't do anything about it. The opposition from systemd (in so far as it actually exists) is coming from old school admins not developers. Distributions are about wrapping software as it exists or making minor changes.

Re: systemd needs to stay optional

[Anrego]

That's because we never really "standardized" on it. Sure a distro can pick their preferred init system, but there was nothing stopping you from using another, because they were _just_ init systems and not the whole system platform clusterfuck that systemd is aiming to be.

Case and point, I use gentoo, and like most gentoo user, open-rc. Up until now this hasn't been a problem. Then systemd came along and started fucking everything up.

Re:systemd needs to stay optional

[RavenLrD20k]

This is exactly the problem though. The prime distributions have been going to systemd and outright dumping support for all other init systems wherein if say I want the package system of Debian but I want to go with a more classical init system, I have to download a system with systemd and then work to retrofit my init of choice to replace it. I was about to say that even the current book of LinuxFromScratch has gone in favor of setting up systemd based on when I looked at 7.6 a few weeks ago, but that's no longer true. Apparently it's been changed back to sysvinit since then and the systemd version has been given a separate link on the page.

I have no problem with distros offering systemd as an option as much as they offer Gnome, KDE, LXDE, etc as options. But don't force me on an upgrade path where I have to use systemd as an init if I've already got my servers set up for using init scripts and don't really have the time to go through configuring a new init system on a *hobby* network. This is what I'm looking at for several home servers when CentOs 6.5 LTS loses support. My options are going to be migrate to CentOs 7 and deal with systemd configuration headaches, or migrate to another distro and learn that ecosystem of doing things. Either way, I'm going to have to learn something new, not in itself a bad thing, which is why I've been looking at LFS more closely and actually weighing that route against going to a *BSD variant. If I'm going to be forced into changing some aspect of the way I'm doing things, I'm going to chose the path that looks close enough to familiar with the path I've been on or will give me plenty of practice with its new to me method (changing from yum to apt-get is an easily adaptable change, going from yum to portage, not quite so easy; going from yum to self-compiling... LFS will definitely give me plenty of practice by the time it's installed...what does *BSD use and how does it compare?), and looks like there won't be much of any further operational changes in the distant future (distant being relative to computer terms: 5-10 years).

Re:systemd needs to stay optional

[rahvin112]

Debian is neither a really good desktop (older, more mature packages, which means spottier driver support), nor a really good server.

Bollocks. Debian is an EXCELLENT server. It's stable, bug reports are fixed quickly and the software is well tested. If you want a reliable server Debian is where it's at. Based on the number of Debian Servers out there in the wild I'm not alone in my feelings about Debian.

Re:systemd needs to stay optional

[tiagosousa]

Not to mention seamless upgrades between versions, and even mixing/matching packages from different archs for advanced setups. Freely up/downgrading stuff with DEB-based distros is a bliss. When I learned that RHEL historically didn't even support upgrades between major stable versions I was awestruck (they seem to have made improvements for this in 7, good for them...)

Re:systemd needs to stay optional

[thegarbz]

The real point I was making though, was that debian was a REFERENCE DISTRO.

Yes. And now Debian is a reference distro which uses systemd for inner workings.

Will the world implode? Will routers suddenly switch to Windows CE? No. If it had a purpose that is now somehow damaged by the inclusion of systemd then another distro will fill its place. That is assuming that all those benefits of open source its proponents have been shouting about are in fact real.

From what I can tell there's a heck of a lot of developers upset about systemd too, but apparently the right course of action is to bitch and moan on internet forums, and not ... develop alternatives.

Re:systemd needs to stay optional

[geminidomino]

[1]. systemd's logging is more reliable not less.
[2]. As far as SPOFs the move to PaaS makes systems far more redundant not less. Each node is unimportant.
[3]. As for minimizing attack surface containerization and virtualization are how that's accomplished. Fundamentally that idea is being rejected in favor of dedicated security systems.

(1) There's nothing about binary logging that's more reliable, more secure, or more usable.
(2) Not every use case is appropriate for PaaS/cloud. Systemd might be good for that setup, doesn't make it a universally good fit.
(3). People who are doing that "rejecting" are people I don't trust making security decisions that will affect my systems.

 

It doesn't really matter. Ian doesn't have a solution for the problem.

Application programmer B creates a systemd dependency in application C.
Debian package maintainer D considers this a bug in the package.
B tells D to go pound sand.

If the GR passes, the omitted step is important:
B's package doesn't end up in the repo. Therefore, I don't have to worry about it.

Re:systemd needs to stay optional

[SharpFang]

Binary logging is actually a bane.
If the system crashes hard, so hard it won't boot up to recovery, I take out the drive, mount it on my PC and read the logs.
Now if I have binary logs, I need tools to read them. Which means likely the same system as the one just crashed. And if the crash was due to some worm infection, ouch, I have two dead systems and nothing to read the logs with...

Re:systemd needs to stay optional

[SharpFang]

Does it have less than 64MB RAM and less than 200MHz CPU?
If not, shut up.

Re:systemd needs to stay optional

[SharpFang]

Thanks. I'm running TS-Linux on TS-7260 single board computer. It has 64MB RAM, 16MB Flash and 200MHz CPU. Roughly 20MB is occupied by the dedicated application the board is running, another 16MB goes to all of the OS plus server processes.

It looks like Systemd wouldn't even be able to start up on this system.

Re:systemd needs to stay optional

[Eunuchswear]

Well, fuck you too very much.

Thanks for defining what you consider is embedded. By your definition my phone isn't.

Re:systemd needs to stay optional

[jbolden]

Now if I have binary logs, I need tools to read them. Which means likely the same system as the one just crashed.

Why? Lots of people have implemented readers for systemd's journal format. Nothing about your process is going to change. Just like you don't read current log files with a hex editor by track and sector you won't read these binary files with a text editor.

As far as a worm, you don't execute any code on the crashed system.

Re:systemd needs to stay optional

[Anonymous Coward]

Frankly it is the systemd proponents that should fork and prove that their system works.

Look at the Linux kernel. Every major change or addition is developed in a separate tree, and only considered for inclusion in the main tree when it has bugs, kinks, and regressions hammered out of it.

Re:systemd needs to stay optional

[SharpFang]

Try to guide over the phone a 3rd party serviceman who can barely type, sitting in a drizzle by a backroad 600km away, to download a systemd log reader for Windows XP to his 10-years-old laptop with slowly dying battery, over nearly-nonexistent GPRS link, when you need to debug a problem with a roadside weather station. If I fail, it's a 600km service trip for me.

Every computer comes with plain text editor, even Notepad.exe can read plaintext logs.

Re:systemd needs to stay optional

[SharpFang]

No. Embedded is a wide range of devices. Your phone is one data point in a huge cloud. The fact it can do something means fucking nothing.
I just provided another data point to disprove your fallacy that "if it works for me, it's fine, since apparently it works for everyone".

Re:systemd needs to stay optional

[Eunuchswear]

I just provided another data point to disprove your fallacy that "if it works for me, it's fine, since apparently it works for everyone".

That's not what I said.

The AC was saying that embedded wouldn't run systemd.

I asked, in good faith: Does my phone count as "embedded linux"?

You told me to shut up unless my phone had less than 64MB ram (it has 1GB) and 200MHz (it's 1GHz).

I, despite being somewhat displeased by your impolite reply, accepted that by your definition that my phone didn't count as "embedded".

Now you start accusing me of falacies. What fucking falacy you stupid gobshite.

Re:systemd needs to stay optional

[jbolden]

Saying that systemd is the right direction for mainstream Linux is a much weaker statement than saying it is the right solution for every use case of a computer on the planet. It might be that weather stations should use something else possibly not even Linux.

That being said...

a) Systemd exports plaintext logs. If you want that you can have it. Better though would be to have systemd just export to you regularly. Your system should be queuing the weatherstation directly.

b) If roadside weather stations are that complex to fix, having redundant equipment sounds like a good idea. There should be more than one system onsite including potentially a diagnostics box.

c) Certainly having a standard repair kit distributed to your service agency would be paid for by even one of those 600km trips. Give them a USB or DVD loaded with the appropriate software that boots their systems. Smarthand job is to get stuff connected. He shouldn't be doing anything in terms of looking IMHO.

Re:systemd needs to stay optional

[SharpFang]

That's all very optimistic approach.

a) Data transfer is the primary cost of keeping them working. The station connects once per 10 minutes to send in its measurements and very little more. Adding system logs etc would triple the transfer.

b) That would double or more the unit costs. They are a simple SBC, with GPRS modem and several sensors. Keeping them simple keeps them robust - they fail extremely rarely. They often operate in very limited power conditions (solar battery + accumulators). So any extra hardware on-site is likely to be liability more than a boon. Especially that theft and vandalism is more common than normal failures.

c) Usually the entity maintaining them is different than the entity installing them, which is different than the entity purchasing them. And 4 years later you can expect the entity maintaining them has changed twice, and any service equipment/data we have provided is long lost. When working with the 3rd party we must depend on generic software and whatever we loaded the station's SBC with. We absolutely can't count on them having a specific kind of hardware.

Parallel booting of services

[msobkow]

The idea of booting services in parallel is nice, but the problem is that apparently it doesn't have a way to specify that you need to wait for a dependant service to hold off until the initialization of the dependancy is complete. Systemd considers it "booted" as soon as it launches, which causes people problems with unreliable network initializations and such that have been resolved for Sys-V style init scripts for years (if not decades.)

Re:Parallel booting of services

[mvdwege]

Wait, what? It's the other way around. If the dependencies are systemd managed, systemd will wait until they report back to be up and running before starting dependants. This is opposed to the SysV rc way, which just blithely ignores all output and continues booting unless the rc script actually hangs.

In fact, one of the most common complaints is that systemd keeps hanging on filesystems in fstab that are not mandatory to mount on boot, instead of ignoring the mount error and leaving them to be mounted manually later.

Re:Parallel booting of services

[Barsteward]

I think you need to go and read the documentation and not rely on slashdot anti-systemd posters as they are misinformed most of the time becuase they haven't done any research

Re:Parallel booting of services

[msobkow]

That is absolute bollocks. You have to go out of your way to put the init programs in the background with SysV init scripts -- they don't return until initialization is actually complete.

Re:Parallel booting of services

[msobkow]

You damned straight I trust the issues admins are reporting experiencing with their systems over documentation that describes what should be happening. Especially when I've read dozens of people reporting that they can't put a systemd based system into production because the network initialization is unreliable, leaving them without a way to even ssh into the problematic system to fix it.

Re:Parallel booting of services

[walterbyrd]

As I understand it:

1) Systemd has a much slower shutdown, which means a reboot takes much longer.

2) Debian can be rebooted in 30 seconds. So even if boot was speeded up, it is a negligible advantage, and hardly justifies such a radical change.

3) Linux servers are not rebooted very often, making supposed advantage even more negligible.

4) If a service is critical, there should be a parallel server running it. Which make boot time even less meaningful.

5) According to this article at Distro Watch: http://distrowatch.com/weekly.php?issue=20141027#qa : boot times are not improved. That has been my experience as well.

Re:Parallel booting of services

[Uecker]

Yes, the daemon process forking a child and exits only after initialization is complete. This is a nice and clean solution.
Systemd adds an interface so that "new-style" daemons can notify about completion. I hate this stupid complexity.

ttp://www.freedesktop.org/software/systemd/man/daemon.html

Re:Parallel booting of services

[Rich0]

1) Systemd has a much slower shutdown, which means a reboot takes much longer.

Actually, when I first started messing with systemd 1.5 years ago the first thing I noticed was how fast the shutdowns went. That was a far more dramatic improvement than startup was in my experience. I find shutdowns are still quite quick - the biggest slowdown I have on my main box is that I run a large multi-volume btrfs filesystem and that can take 10s of seconds to unmount. The rest takes very little time to shutdown, and this is a host that runs a bunch of containers that are all themselves running systemd, and those have to shut down before the host can shut down (each container is a service).

Re:Parallel booting of services

[Rich0]

Systemd considers it "booted" as soon as it launches, which causes people problems with unreliable network initializations and such that have been resolved for Sys-V style init scripts for years (if not decades.)

man systemd.service:
Type=...One of simple, forking, oneshot, notify or idle.

If set to simple...systemd will immediately proceed starting follow-up units.
If set to forking...systemd will proceed with starting follow-up units as soon as the parent process exits.
Behavior of oneshot...it is expected that the process has to exit before systemd starts follow-up units.
Behavior of dbus...systemd will proceed with starting follow-up units after the D-Bus bus name has been acquired.
Behavior of notify...systemd will proceed with starting follow-up units after this notification message has been sent.
(Idle is just simple but delayed and run sequentially so that the console log isn't interleaved - not really recommended for general use.)

The behavior you describe is only the case for simple units. Forking is preferred if a daemon forks when it is ready. dbus/notify are obviously ideal ways to handle things as the daemon can explicitly communicate readiness. Other options include simple daemons with an execstartpost that polls for readiness (unit isn't considered started until this finishes), or having a separate unit that polls for readiness and that is made the dependency of other units.

If what you said was true systemd would almost never work. One thing you quickly discover using systemd is that failure to specify dependencies often causes problems, because systemd launches services VERY QUICKLY in parallel. I used to openrc in parallel and there is a big difference between having a bash script launching a bunch of bash scripts which launch daemons in parallel, vs having a program written in C launch a bunch of daemons in parallel. If you didn't have any dependencies you could have your daemons all firing off in the span of a few milliseconds.

Re:Parallel booting of services

[sjames]

Only if they have been added to the systemd dependency hairball. If they are normal daemons, they will report nothing back to systemd.

rc scripts offer the opportunity to either make the script wait until the service is responsive OR to have the dependent script wait.

In many cases, daemons only detach once they are up and running exactly so the init process won't screw up dependencies. Unless the init system tries to get clever...

Re:Parallel booting of services

[Cyberax]

1) Systemd has a much slower shutdown, which means a reboot takes much longer. 2) Debian can be rebooted in 30 seconds. So even if boot was speeded up, it is a negligible advantage, and hardly justifies such a radical change.

Incorrect. Debian shutdown/reboot can take any amount of time, up to +inf. For example, this beautiful initscript: http://anonscm.debian.org/cgit... can hang indefinitely (see line 92) and stop the reboot process forever. It's not theoretical either, I happened to go at 4am to our datacenter to power-cycle a server because of this bug.

Meanwhile, systemd can actually reliably kill services using cgroups to track all of the services' processes.

Re:Parallel booting of services

[mvdwege]

rc scripts offer the opportunity to either make the script wait until the service is responsive

How?

As someone who has written his own rc scripts, I can tell you: there are no trustworthy mechanisms to do what you say rc scripts do as a matter of course.

And yeah, systemd running a standard rc script can't test for these conditions either. Somehow playing this as a systemd weakness seems a bit ... irrational to me.

Re:Parallel booting of services

[mvdwege]

I have the exact same setup, and I experienced the reverse: using sysv init rpcbind would deadlock with networking, because networking tried to start nfs. Switching to systemd solved that problem.

So we have two competing anecdotes. Now what?

Re:Parallel booting of services

[sjames]

As someone who has written entire init systems, I'll tell you how it's done:

Create a program (any language you like) that connects to the service and requests status. Make it keep trying until the status is good. Call it in the start stanza of the dependent service's init script.

For example, you can use wget to see if apache has come up. It can even see if apache on another machine has come up. Now, how would you go about having systemd do that for you?

Re:Parallel booting of services

[mvdwege]

Someone else posted the full list of systemd verification mechanisms in this subthread. I'm going to refer you to that.

And in cases where there is no mechanism in place, for example when systemd is executing an rc script, I have the exact same mechanisms you describe: roll them myself by scripting.

I fail to see the problem here, the systemd way is a superset of the rc way. If you think that is worse, then I stand by my 'irrational' comment.

Re:Parallel booting of services

[sjames]

Actually no. It was a list of ways it knows/guesses that the service being started has actually finished starting. Presumably, it knows a service stopped when it's assigned cgroup is empty but has no idea if the daemon gets wedged without crashing.

There is nothing irrational about rejecting complexity for complexity's sake nor with rejecting kitchen sink style dependencies in software.

But speaking of irrational, every time I try to pin a systemd supporter down on why the architecture is at all acceptable or what benefits it actually offers over less intrusive changes, they never seem to come up with an answer.

Re:Parallel booting of services

[mvdwege]

Perhaps that is because you are so wedded to your biases that you are not reading the answers provided. As I said, irrational.

Re:Parallel booting of services

[sjames]

You say that every time I ask a question you don't like the answer to.

It's quite a tell.

Re:Parallel booting of services

[mvdwege]

Dude, someone posted a list of possible verification mechanisms straight from the systemd documentation, and you called them guesses. Go get some treatment for your projection issues, ok?

Re:Parallel booting of services

[sjames]

Only because none of them actually address the issue I pointed out or offer a way to do so. So sorry I gored your sacred cow. This is a technical matter, not politics. Answering at a question doesn't do it.

Now, look at that list and tell me where I am wrong or apologize (or slink away if you prefer).

It stands out clearly that...

[carlhaagen]

...for better or worse, quite special conditions have to be met in the engineering department of a user's brain in order to like systemd.

Read of the better systemd commentaries around

[Anonymous Coward]

http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

This comes from an "anti-systemd" source, but tries to cut through a lot of the controversy and hostility shown on both sides. Bear in mind, you only see the anti-systemd view on Slashdot, but you get just as much idiocy on the other side as well. For example, the Poettering "death threats" were actually a joke made by a bunch of people in an IRC channel. Here, read the log (ctrl-F "hitman"):
http://logs.nslu2-linux.org/livelogs/maemo/maemo.20130215.txt

Re:Read of the better systemd commentaries around

[Nemyst]

http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

This comes from an "anti-systemd" source, but tries to cut through a lot of the controversy and hostility shown on both sides. Bear in mind, you only see the anti-systemd view on Slashdot, but you get just as much idiocy on the other side as well. For example, the Poettering "death threats" were actually a "joke" made by a bunch of people in an IRC channel. Here, read the log (ctrl-F "hitman"): http://logs.nslu2-linux.org/li...

FTFY. Sorry, there are some things which just are not funny, and if we're gonna condemn idiots like Sam Biddle who tweet "bring back bullying" and other such nonsense (hint: the backlash was rather large), we should also condemn people "jokingly" saying they're gonna put a hitman on anyone.

Re:Read of the better systemd commentaries around

[serviscope_minor]

http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

Mod parent UP. This is a really good article. This is the sort of thing I think the poster would like to read.

Re:Read of the better systemd commentaries around

[walterbyrd]

> only see the anti-systemd view on Slashdot,

Bullshit. Slashdot has nearly as many systemd shills as microsoft shills.

Usually the shills use dismissive arguments, and ad hominem attacks, i.e. anybody who does not like systemd is a hater, a grey beard, stuck in the past, etc.

Re:Read of the better systemd commentaries around

[walterbyrd]

> Bear in mind, you only see the anti-systemd view on Slashdot

I call total bullshit.

Five seconds of googling and you will find moutains anti-systemd views.

How about this for a start:

http://boycottsystemd.org/

Re:Read of the better systemd commentaries around

[walterbyrd]

> we should also condemn people "jokingly" saying they're gonna put a hitman on anyone.

I agree. But we need a sense of perspective as well. I have received death threats. Lots of people have.

There is a guy named Pat Condell who posts videos on youtube that are critical of Islam, he get hundreds of death threats.

I agree that death threats are not cool. But they are really not all that shocking either.

Re:Read of the better systemd commentaries around

[nctritech]

Jokes are never funny after they're examined out of context anyway.

The sound of

[pedestrian crossing]

*crickets*

If you can't say something nice...

Re:Where do you think you are?

[Anonymous Coward]

Even requests for interview questions tend to have a lot of posts that aren't interview questions.

And yet plenty of posts responding to those stories are for interview questions and do follow the rules as such.

You, and a few other posters, remind me of the type that will rant about rights being violated if they are asked to not make a scene some place public or to keep noise down. Even if you are legally/physically allowed to do something, doesn't mean someone can't politely ask you to not do it. It doesn't infringe on one's rights, etc.

Depending on the reason they asked, and the reason you have for wanting to disregard the request though, it could just mean you end up looking like an selfish asshole for complaining about someone even asking you to do something differently. So what is your great reason for disregarding the suggested format as opposed to finding one of the dozens of other normal stories, or going somewhere else to bitch and moan about systemd?

Re:Where do you think you are?

[serviscope_minor]

What the fuck, you think you can set rules for discussion on Slashdot?

Sadly he can't force the rules on anyone, no matter how useful those rules would be for such a debate. So, instead of actually doing what the poster wants, we instead get comments like yours which add absolutely nothing to whether or not systemd is any good.

And yes, it's a question I was considering posting on too. It would be nice to see some useful information.

So thanks for clogging the top level posts up with useless, pointless crap. You have done your fellow slashdotters a great service showing you can be angry on the internet.

I likey

[Anonymous Coward]

I like systemD -- without diving very deeply, mind--

1. It harkens back to the Windows Registry, mind --
2. It keeps no logs, that just works! , mind --
3. Arch users love it because too cool for the room, mind --
4. It forces me to use a function like programming syntax, mind --
5. It just works, mind --

Personal experinece: I like long walks on the beach, systemD makes long walks off of short piers many better, mind --

Plays nicely inside a container

[Rich0]

I've been starting to migrate many of my services at home to containers to make them a bit easier to maintain (a bit of a tangent - having 5 containers instead of one host with 5 services means that you have to do 5x as many updates, but each update can at most break one thing at a time). This was trivial to do with systemd-nspawn.

With a command line that barely fills a terminal line I can launch a container, have it boot systemd inside the container, have a few bind mounts, and have it get its own IP like a lightweight VM. Within the container systemd just does whatever it is told to do, like launch ssh so that I can get in, configure the network, and launch whatever services the container was intended to provide. The container journal logs are symlinked back to the host log directory, so they're really easy to look at from the host.

Sure, you can do similar things with docker, but doing it with systemd involves less tooling in general.

Also, for simpler situations systemd-nspawn makes a VERY good substitute for chroot. In addition to doing everything chroot does, it starts a separate process namespace so you don't see outside processes from inside the container. It also automatically sets up /dev for you, sets up resolv.conf, etc - it can do all this while just spawning one program inside just like chroot does (so no need to run systemd inside). It can also set up bind mounts if you ask it to. When you exit it cleans up - no lingering bind mounts, or tmpfs, or /proc and such inside. Also, any mounts inside the container aren't visible outside, so you can run a backup on your chroot and not have it follow bind mounts, or try to save /proc/kcore or whatever. In fact, you could spawn 5 containers inside the same directory and they can have private /tmp and /dev and /proc while seeing changes each other make in the files in the actual chroot.

Re:Plays nicely inside a container

[houindcon]

Do you think it's possible that your experience is unique? Does anyone else have input regarding the parent comment? It seems too good to be true, however VERY interesting if it is... I'm asking genuinely here, no sarcasm. Can anyone discuss this further? Gracias in advance.

Re:Plays nicely inside a container

[phantomfive]

Nice post

Re:Plays nicely inside a container

[Rich0]

I have heard that systemd doesn't always play as nicely with lxc as it does with systemd+systemd-nspawn. I don't have enough experience with lxc to validate this one way or the other.

Re:Plays nicely inside a container

[TechyImmigrant]

> it can do all this while just spawning one program inside just like chroot does (so no need to run systemd inside).

Kind of how Plan9 handles every process. Plan9 does it with less fussing though.

Re:Plays nicely inside a container

[whoever57]

Systemd's cgroup functionality promises to be more secure in the long run

Care to explain why that is? cgroups is a Linux kernel feature, note a systemd feature. So the question is: how does systemd use cgroups differently and why is this more secure or otherwise better; why cannot other init systems use cgroups functionality in the same way as systemd?

maybe try reddit?

[nimbius]

about as informative as an old Bud Light commercial

If the technical discussion inevitably inherent in most historic articles regarding the controversy and operational functionality of systemd is indistinguishable from spuds McKenzie or three gurgling anthropomorphic frogs, you may not be a good fit here.
Why not try Wired? they have a bunch of real neat articles on halloween costumes and even a picture hunt challenge! If you find yourself worn out after a few paragraphs its okay. Cookie clicker should help to clear the frustration.

Opps wrong thread.

[Anonymous Coward]

The whole CVS and CurrentC has me irked lol.

On a related matter:

[robbak]

With more people jumping to FreeBSD, we might get better hardware support over here.

Re:On a related matter:

[Anonymous Coward]

Ever notice FreeBSD doesn't have these silly issues. It just keeps chugging on along all by itself, doing the right thing day in and day out... before OpenBSD, before OSX, before NetBSD and with "Unix" concept overall, before even Linux. There is no resource draining prideforking distro of the month as there is with Linux. In fact, it's only been forked twice 1) stolen by commercial OSX, 2) concept continued by DragonflyBSD, and rather pointlessly wrappered up for clueless users by PC-BSD and one other marginal effort, and even given fantastic kudos by use as the kernel in Debian-GNU/K-FreeBSD. It doesn't have as many security or stability issues. And the design is holistic and agreed upon. There's no constant ripping in and out of the same technologies with different labels, only steady progression in the BSD way. BSD is clean, simple stable, tried and true. BSD comes from ONE development house, not kernel here glibc there, FS over yonder and the base userland from wherever.

If you're pissed about systemd, or just tired of all the games and jabberjaw, fanboyism, and now commercial Ubuntuism that comes with Linux... you owe it to yourself to actually install and try FreeBSD. If you give it an honest three to six months that any operating system deserves... I promise you won't be disappointed.

Stop means STOP

[Rich0]

One thing I really like about systemd is that when you stop a service, it actually stops.

I used to run monit with openrc and when you wanted to restart a service you had to play games to ensure that it was really killed, and that the service state was cleaned up, and so on. Just telling openrc to stop the service just wasn't reliable at all - it worked well when nothing was wrong, but if nothing was wrong chances are monit wouldn't be doing anything.

Systemd is very effective at containing processes and their children and when you stop them, they are all gone for good. If you want to restart a service, systemctl restart service will get the job done 100% of the time, assuming the configuration/etc lets it restart. It does support graceful shutdown of individual services, followed by process genocide.

This also applies to things like cron jobs you launch through it. When the parent process ends, anything left gets cleaned up.

Re:Stop means STOP

[Anonymous Coward]

I know exactly what you mean, and the sad thing is, in most cases, it's the package maintainers fault. They've written an overly simplistic script to manage the service and are incapable of even determining if it's even running at all (let alone stopping it) in 99% of the edge cases. You end up with a zombie process hanging around or a PID file pointing to nothing and now you have to clean up after it. What's even worse is when the script is so poorly written that the stop function returns successfully when it has stopped nothing at all. Debug/Error/Warning output also tends to be abysmal, if it exists at all. If you can't maintain a package, please, don't become a maintainer.

That said, init system developers aren't entirely without blame. Part of the reason for systemd's success is the amount of maintainer ass wiping it does. Quite a few things like process and resource management are either automatic or easy as makes no difference in systemd so they can integrate irresponsibly and systemd will try to keep your ass out of the fire. If any of the other init systems want to survive, it might be time for drastic measures, because right now, laziness is prevailing.

Re:Stop means STOP

[Rich0]

Part of the reason for systemd's success is the amount of maintainer ass wiping it does.

True to an extent, but you could also say that it refactors this stuff so that instead of every single init script being 50 lines long so that it can clean up after itself, you now have 5-line unit descriptors with a service launcher that can clean up after anything.

The apache unit contains "ExecStop=/usr/sbin/apache2 $APACHE2_OPTS -k graceful-stop" but if for whatever corner case it doesn't stop (maybe a broken config file prevents apache2 from running), then systemd WILL kill it.

Re:Stop means STOP

[Rich0]

I guess that is why systems still hang on shutdown... sometimes.

Yup. Another systemd feature is that if you pair it with dracut then when your system shuts down systemd pivots back to the initramfs, which can unmount your root filesystem and so on. Granted, remounting read-only works reasonably well, but it just seems cleaner to me to fully unmount everything, and this behavior might be desirable in unusual cases.

When I first started using systemd I was expecting boot times to improve, but the thing I really noticed was that shutdown speeds were MUCH faster. I'd run shutdown on a VM and the thing would die faster than the terminal window could keep up.

Re:Stop means STOP

[Rich0]

So what does it do if a service does not respond to a request to shutdown properly? Does it just pull the plug with a kill -9, because that seems like a terrible idea to me.

man systemd.kill

KillMode=
                      Specifies how processes of this unit shall be killed. One of control-group, process, mixed, none.

                      If set to control-group, all remaining processes in the control group of this unit will be killed on
                      unit stop (for services: after the stop command is executed, as configured with ExecStop=). If set to
                      process, only the main process itself is killed. If set to mixed, the SIGTERM signal (see below) is
                      sent to the main process while the subsequent SIGKILL signal (see below) is sent to all remaining
                      processes of the unit's control group. If set to none, no process is killed. In this case, only the
                      stop command will be executed on unit stop, but no process be killed otherwise. Processes remaining
                      alive after stop are left in their control group and the control group continues to exist after stop
                      unless it is empty.

                      Processes will first be terminated via SIGTERM (unless the signal to send is changed via KillSignal=).
                      Optionally, this is immediately followed by a SIGHUP (if enabled with SendSIGHUP=). If then, after a
                      delay (configured via the TimeoutStopSec= option), processes still remain, the termination request is
                      repeated with the SIGKILL signal (unless this is disabled via the SendSIGKILL= option). See kill(2) for
                      more information.

                      Defaults to control-group.

So, you can have it your way... :)

Re:Stop means STOP

[Rich0]

Err, no, it doesn't. If it supports socket activation, you need to stop that as well with a separate command, otherwise it will be restarted behind your back if anything wants to talk to it.

Nasty, and it currently breaks Debian upgrades...

Sure. And if it starts with a timer unit then you need to stop that or the service will restart when the timer next triggers.

Sockets, services, and timers can all be related. That doesn't mean that the stop command doesn't work.

This is no different from having to stop xinetd if you have services that are launched from it, lest the next connection just restart the service.

There is nothing nasty about this - sockets and services are related but not identical. Maybe somebody in Debian didn't think of this, but that hardly makes it a systemd bug.

Re:Stop means STOP

[topologicalanomaly47]

Except when it doesn't

e.g. I issued
systemctl httpd restart on a stock centos 7 (with latest updates). The command hanged (didn't return to terminal prompt). Nagios promptly informed me that sites on that server are no longer responding.

CTRL+C and issued systemctl httpd stop it returned me to the command prompt with no message of success or failure. I assumed succes and issued systemctl httpd start Nope sites still offline.

Again systemctl httpd stop and did ps aux | grep httpd - yep it was still running. I did a killall -9 httpd and systemctl httpd start Phew, everything is running again.

Where would you start diagnozing what the hell happened there. And to stress again, stock system, no third party repos not even a db server (it's on a separate machine) only apache, php, ssh and the usual base services.

Re:Stop means STOP

[Rich0]

Did you ask anybody for support, such as your distro? Sounds like it might be a bug. Or it could be a configuration issue. You can tell systemd to not care about exit codes, or even about killing processes.

You ask where would I start diagnosing what happened. I'd start by looking at the configuration and confirming that systemd isn't doing what you told it to do. After that I'd probably capture what I could (strace, etc), and post on the distro bug tracker.

Re:Stop means STOP

[topologicalanomaly47]

If I'm ever to reproduce on test system, sure I might do all that. Or if it gets worse, otherwise I'm not really inclined to spend my time hunting systemd bugs.

Hardening

[icemaze]

Systemd was forced down my throat by Arch Linux. I didn't know anything about the controversy back then, so I just thought: "There's probably a good reason for this, let's get to work".

I read some docs and I liked the security features a lot! You can tighten services easily with a declarative syntax.

Here's a snippet from my ntpdate.service file. You don't need much systemd knowledge to guess at what each line does:

PrivateTmp=true
ReadOnlyDirectories=/
InaccessibleDirectories=/boot
InaccessibleDirectories=/root
InaccessibleDirectories=/etc/ssh
LimitNPROC=1
DeviceAllow=/dev/null rw
DeviceAllow=/dev/urandom r
User=nobody
Group=nobody
CapabilityBoundingSet=CAP_SYS_TIME
NoNewPrivileges=true

I ended up enjoying that work and tightened things so much that I hit a bug, which was resolved in just a few days: https://bugs.freedesktop.org/s...

But I still don't know how to configure the network properly T_T

Re:Hardening

[morgauxo]

Wait, so now we aren't setting read/write status in fstab anymore?

Re:Hardening

[Phs2501]

Wait, so now we aren't setting read/write status in fstab anymore?

How do you set filesystem read/write status for just the ntpdate process in fstab?

Re:Hardening

[ledow]

Those facilities are not given by systemd. They are given by cgroups and other security features. Systemd just has a way for you to specify them for services, it's not doing all of the heavy lifting.

Similarly, imagine that config file, interpreted by SysVInit scripts, and applied the same. Would that be better or worse than systemd?

And, to be honest, in terms of the userbase, that's quite a niche preference. I can count on my fingers the number of times that I've personally had to lock down a service to the bare essentials. That's what package managers and SELinux policies are for.

Again, it's a lovely feature. But does that justify ripping out the init code from the entire distro for? And could it be done any other way (I'm guessing yes).

Re:Hardening

[Rich0]

Similarly, imagine that config file, interpreted by SysVInit scripts, and applied the same. Would that be better or worse than systemd?

Imagine a copy of zlib bundled with every application Google distributes. Is that better or worse than using the system library? Any distro maintainer could answer that one.

Sure, you can do all this stuff with a clever traditional init.d script. However, do you want the same function tweaked 75 ways in your scripts, or a standard way of doing it in your service manager? If the private-tmp feature in systemd has a bug it can be fixed for all services at once.

But yes, those are largely all linux kernel features that systemd is merely exposing. In practice it means that people will actually use them now.

And, to be honest, in terms of the userbase, that's quite a niche preference. I can count on my fingers the number of times that I've personally had to lock down a service to the bare essentials.

Sure, but a variation on his config would work with any distro, so this lets upstream lock down a service file and benefit everybody who uses systemd on any distro. It does overlap a bit with SELinux, but not everybody uses SELinux and this is a much more lightweight way of hardening a service.

Re:Hardening

[Peter H.S.]

Those facilities are not given by systemd. They are given by cgroups and other security features. Systemd just has a way for you to specify them for services, it's not doing all of the heavy lifting.

systemd makes it easy for both end users, upstream developers and distro makers to take advantage of those advanced kernel features; no low level hacking needed, no home made bash scripts, no endless hacking needed to make three dissimilar sub-systems talk together by fragile scripts.

With systemd strong hardening features comes ready to use out of the box. Just add a simple "keyword=value" in a text config files, and everything works.

The reason why kernel features like "capabilities" and "cgroups" have existed with very little or no use on general purpose distros, is exactly because they are very hard to use on systems that aren't designed like systemd.
It is the same with the new Kernel IPC system "kdbus". Systemd will make it easy for upstream projects to use kernel IPC, while SysVinit and similar won't.

Re:Hardening

[Peter H.S.]

Wait, so now we aren't setting read/write status in fstab anymore?

Yes, for file systems. Notice this is for a single running daemon. Think of it like a kind of sand boxing that prevents the service and all processes it spawns to e.g. read/write /boot /home /root etc.

Since it is build on "capabilities", those directories will be inaccessible even if the process is exploited. It is seriously cool stuff that systemd makes it easy to use.

Re:Hardening

[thegarbz]

Similarly, imagine that config file, interpreted by SysVInit scripts, and applied the same. Would that be better or worse than systemd?

Worse. That was a very easy answer. Let me explain.

In terms of managing the system I really don't care how features work or what does the heavy lifting. What I care about is the complexity required for me to do what I want. I have seen comments here saying that if you want a systemd style startup all you had to do was install and configure several helper services that run alongside sysvinit and help manage daemons, and rewrite the scripts, and now your comment add a config file that includes even more interpretation required by each individual script. My sshd startup script is already 200 lines long. Why do I need to be a bash programmer to get my system to boot?

All benefits, features, and other bickering aside the single biggest feature of systemd that I like is that a startup script isn't complex. But hey I was a fan of upstart too.

Speed

[Carewolf]

Just installing systemd over sysv speed booting up from a minute to 10 seconds, and shutting down from half a minute to under one second. I always hated Linux couldn't handle shutting the fuck down efficiently, now it does.

Re:Speed

[bill_mcgonigle]

I've killed systemd shutdowns hard after 15 minutes of timing out waiting for an nfs share that went offline.

The old system didn't do that. Not to detract from the lovely startup times, but it's not "all baked" yet.

Re:Speed

[Theovon]

This sounds like a bug. Systemd is new, so it will have bugs. This is not, however, a design flaw. It is merely something that needs to be fixed. It's only a major problem if the devs refuse to fix it on the grounds that they don't think it's a bug. However, I've mostly only encountered that attitude when reporting Chrome bugs to Google.

Re:Speed

[thegarbz]

I did the same thing on my RaspberryPi recently and that doesn't run systemd.

I highly doubt that really is the problem for an application attempting to cleanly shut down the system. Maybe the nfs developers should be questioned as to why their system isn't able to handle sudden loss of a shared resource.

Re:Speed

[Carewolf]

I've killed systemd shutdowns hard after 15 minutes of timing out waiting for an nfs share that went offline.

The old system didn't do that. Not to detract from the lovely startup times, but it's not "all baked" yet.

I am pretty sure that would happen under sysv as well, though the old script might have had a workaround for the issue. NFS lockup issues is kernel "bug", the kernel refuses to shutdown or stop any requests that could lead to data loss, but if the NFS server is unreachable, that is impossible to avoid, so they just hang. This leaves to processes that can't even be killed with -9.

Sometimes risk aversity in a kernel developer is worth beating them with a bat over.

Re:Speed

[Carewolf]

And that matters to a server how? I reboot my linux servers as little as absolutely necessary (security updates, kernel patches, etc). The added overhead and complexity of debugging why there was a problem with systemd (and its infuriating lack of text logs I can work with in any number of tools) is not worth 2 minutes of saved time every 3-6 months.

The binary logs are optional. I haven't used them, why would I?

Re:Speed

[Rich0]

I've killed systemd shutdowns hard after 15 minutes of timing out waiting for an nfs share that went offline.

The old system didn't do that. Not to detract from the lovely startup times, but it's not "all baked" yet.

Agree that nfs isn't always as well-tested in systemd. I had an NFS-root box running systemd and there were some growing pains. However, I found the systemd/dracut/networkd devs very responsive to bugs around this.

I think that saying that systemd is not "all baked" is a fair statement. If you have fairly generic needs it works great, but if your needs are more exotic you might have to deal with the odd bug. I haven't found any to be terribly difficult to fix.

Re:Speed

[sjames]

There are several cases where the systemd team refuses to accept that a bug is a bug. For example, their persistent refusal to accept that debug on the kernel command line is meant to apply to the kernel ONLY. They could easily go with systemd.debug but they refuse even when all but ordered to do it.

It remains a big fat WONTFIX, NOTABUG.

Re:Speed

[Zeromous]

That's just it. No one here is AGAINST NEW TECH. They are against defaulting new tech on reference and enterprise software.

Systemd is half baked. Wake me when its cooled and ready to eat.

Re:Speed

[bill_mcgonigle]

they want systemd to become the kernel.

I thought that, but no - they want everything *but* the kernel, and maybe steal away a few features from the kernel (*cough* VC's *cough*) and glibc at some point.

Because if you run a systemd system, you can swap out linux for bsd or mach or qnx and not really notice, if the hardware is well-supported.

Re:Speed

[bill_mcgonigle]

It remains a big fat WONTFIX, NOTABUG.

Every distro should carry a tiny patch to fix that. My kids would say, "you can't just give a mouse an option, 'cause...".

Re:Speed

[sjames]

Uselessd has fixed it in their fork.

Re:Speed

[mvdwege]

Liar

Really, if you are going to post your ideology-blinkered screeds, do your research first. This makes you look ridiculous.

Re:Speed

[sjames]

There is a liar but it isn't me. Look at the bottom of the page:

Lennart Poettering 2014-05-24 08:38:07 UTC

systemd in git since a while will turn its debug output on if the kernel command line cotnains "debug", this will stay that way. However, it has been changed to not dump things to kmsg as soon as the journal is up. Up to that point we will still dump things to kmsg howerver, since there's no other nice place to put this.

Closing.

In other words, he claims resolved fixed but the action (not) taken was actually wontfix notabug

I will accept your sincere apology now...

Re:Speed

[mvdwege]

Yes I see, you're cherrypicking again.

Fuck off.

Re:Speed

[sjames]

WOW, REALLY?!? Completely refuting your claim (an inflammatory claim that I am a liar, which would get your face punched in some places) and you claim cherrypicking? Do you always spew such partially liquefied bull crap from your mouth?

You're also apparently too stupoid to read your own damned link to the end to make sure it doesn't make an ass of you.

You're full of shit and raised by wolves. You likely attract flies. Begone! Quit stinking the place up!

Re:Speed

[mvdwege]

No, you did not refute my claim. You ignored the entire bug, focusing just on Lennart's final conclusion. That's cherry picking.

Seeing as that the bug report, the LKML and systemd mailing lists came up with a full solution of the bug, you are a liar if you say that the systemd devs don't fix bugs.

Here's the full solution: using the generic 'debug' parameter of the kernel command line to turn on systemd debugging is the correct way to use that parameter, as stated by Linus himself. What is incorrect is generating too much logging for the kernel message buffer; this problem is fixed by fixing the original assert bug in systemd, and by Lennart's design decision to defer as much logging as possible until userspace is up.

It's all there in the bug and related discussion. You refuted nothing. You are a liar. And an Internet blowhard, a keyboard warrior.

Re:Speed

[sjames]

Let's see what linus said about it, it's easy to do when a quote from hin is one post up from the end one:/p>

Linus Torvalds wrote:

+Paul Morgan I think what you (and others) seem to miss is that the systemd people made the "debug" option that we introduced not just do something - but do something useless that actively broke other peoples use of that option.

It doesn't matter who "owns" it, the fact is, they broke it.

Ok, fine. Bugs happen, and that's not what makes people upset.

What makes me (and others) upset is that when the bug is reported, with explanations and a suggestion for how to fix it, Kay just closed the bug-report, claiming it wasn't a bug.

Seriously? You want to debug kernel stuff, using the kernel command line command "debug" that makes the kernel more verbose, and now the systemd people say "sorry, we stole your thing and made it useless, and it's not a bug because you didn't call shot-gun".

Now, if this was an isolated incident, I personally would let it go. There are bad engineers out there, it's not worth worrying about. Ignore them and move on.

But this is not an isolated incident. This is how Kay has treated other bugs in the past. Literally months of stalling, closing bug-reports, and blaming other people and projects for problems that he caused, telling others how they should change their projects because he broke something, and obviously it can't be his fault.

And that is a problem.

You REALLY should read things before you claim they support your position. Now you leave the impression you were dropped on your head.

Re:Speed

[mvdwege]

No. The discussion of Kay Siever's undiplomatic initial handling of the bug split off from the main thread. Kay has been put under supervision of Greg KH, and that was it.

After that, the kernel devs and the systemd devs produced a solution.

Again, you're cherry-picking posts to support your worldview, disregarding all else, and projecting your dishonesty on others. As I said: Liar.

Re:Speed

[sjames]

It was YOUR reference. If there is one that shows YOUR point rather than mine, feel free to present it.

Re:Speed

[mvdwege]

Once again you just disregard already given information. I summarized the bug and the related posts, but since you are going to whine regardless, I'll have Jonathan Corbet of LWN do the honours.

His article has all the links, to the bug and the related discussion. Of course you are going to cherry pick single posts again, but at least the peanut gallery will get to see who is being disingenuous here.

And this is my last word in this entire discussion. I have nothing to prove; you just have to show that you can do more than cherry pick to justify your irrational hatreds.

Re:Speed

[sjames]

Given that you felt driven to reply with an insult that amounts to fighting words a week after the conversation was over, it seems you do feel you have something to prove. What that may be, I don't know.

Your latest link is a bit weak even from an apologist standpoint. But I'll just leave it at that.

Exit codes matter

[Rich0]

A small thing I've come to appreciate with systemd is that it actually cares about exit codes. This applies to any unit, including timer units (the equivalent of cron jobs). I ported most of my cron scripts over to systemd and suddenly started noticing scripts which had been having non-zero exits for ages, but fcron just didn't care about exit codes.

You can tell systemd to ignore exit codes for a process, or specific exit codes. However, I've found that in general using systemd I have a lot more awareness of abnormalities in my services.

Sure, you can often get away with ignoring exit codes, just as you can often get away with ignoring compiler warnings. However, in getting rid of them I fixed a few problems ranging from trivial to important, and my system is more robust for it.

Re:Exit codes matter

[Wheely]

cron does care about exit codes. Any cron job returning a non zero exit code will have "rc=X" in the cron log and it can even mail you the stderr.

Admittedly it will also have "rc=1" if it couldnt run the job at all e.g. if the user account is locked but mostly the cron log doesnt lie.

Re:Exit codes matter

[Rich0]

Thanks. I wasn't aware of that.

Actually, in either case a decent log parser would be useful. I am not aware of any of these really tailored to systemd yet. The binary log format potentially offers a lot of potential here since all the data can be readily obtained broken down into fields, so you don't have to parse lines in an output designed to be terse. Without some kind of monitor systemd will capture that something failed, but it doesn't actually do anything about it besides auto-restart if you tell it to, and log it. Systemctl --failed does show failed services, which is more useful than grepping a log.

Re:Exit codes matter

[Wheely]

I can see your point but in the cases where I have had to parse binary logs that come to mind i.e utmp files and BSM audit logs, it was significantly more annoying than parsing something like syslog with grep/awk/sed/cut/expr etc etc.

It occurs to me that the problem you are trying to address is only a problem because maybe you havent found the right tools and maybe havent split your logs up into logical files rather than just using syslog.

The tool you want to parse your logs is so good it seems like magic. It is an unbelievable tool. It indexes log files, extracts reports, draws graphs, alerts and keeps your coffee warm. It is http://www.splunk.com/ you can use it for free if you dont index too much information.

Like so many enterprise tools, including all monitoring software, it cant read binary logs.

Re:Exit codes matter

[Rich0]

I can see your point but in the cases where I have had to parse binary logs that come to mind i.e utmp files and BSM audit logs, it was significantly more annoying than parsing something like syslog with grep/awk/sed/cut/expr etc etc.

Well, without using anything fancy you can get journalctl to output in a number of formats, including json (ether compact or pretty). Here is an example "line:"

{
                "__CURSOR" : "s=0fb0e8333d264abba3b59c6a8e875767;i=16c9c5;b=56b2f17d2294428fbbb58579ae947505;m=57bad70;t=506abd490de30;
                "__REALTIME_TIMESTAMP" : "1414709958991408",
                "__MONOTONIC_TIMESTAMP" : "91991408",
                "_BOOT_ID" : "56b2f17d2294428fbbb58579ae947505",
                "_UID" : "0",
                "_GID" : "0",
                "_SYSTEMD_SLICE" : "system.slice",
                "_MACHINE_ID" : "7fd75bd599233e3ce0ce5e5f00000029",
                "_HOSTNAME" : "rich64",
                "_TRANSPORT" : "stdout",
                "PRIORITY" : "6",
                "SYSLOG_FACILITY" : "3",
                "_CAP_EFFECTIVE" : "0",
                "SYSLOG_IDENTIFIER" : "mythbackend",
                "_COMM" : "mythbackend",
                "_EXE" : "/usr/bin/mythbackend",
                "_CMDLINE" : "/usr/bin/mythbackend --loglevel notice --nologserver",
                "_SYSTEMD_CGROUP" : "/system.slice/mythbackend.service",
                "_SYSTEMD_UNIT" : "mythbackend.service",
                "MESSAGE" : "2014-10-30 22:59:18.990471 C mythbackend version: tag: v0.27.4 [e4f65c8] www.mythtv.org",
                "_PID" : "2361"
}

Re:Exit codes matter

[Wheely]

This is an improvement and makes it possible to use standard monitoring tools. If one of those is a unique identifier, thats even handy.

What makes this even better is that it allows me to easily create a script to re-format the logs into something everything and everybody can easily read just as they used to.

Re:Exit codes matter

[Rich0]

This is an improvement and makes it possible to use standard monitoring tools. If one of those is a unique identifier, thats even handy.

The cursor is a unique ID for the entry I believe (and you can use it to request updated logs starting where you left off).

The boot ID changes on each boot, so you can associate log entries from the same boot cycle. The machine ID identifies the unique machine, and if you start 47 clones of the same container they will get different ones (I think that if you only run one instance of a container it will keep the same one). Systemd actually has a bunch of logic around hostnames that I haven't looked too closely at but it is aimed at things like clusters, containers, pxe-boots, and the like. It usually just does the "right thing" and it is trivial to just tell it to stick with one name.

What makes this even better is that it allows me to easily create a script to re-format the logs into something everything and everybody can easily read just as they used to.

Well, journalctl does that already. The default output for that one line is:
Oct 30 18:59:18 rich64 mythbackend[2361]: 2014-10-30 22:59:18.990471 C mythbackend version: tag: v0.27.4 [e4f65c8] www.mythtv.org

http://www.freedesktop.org/sof...

Wrong.

[Qbertino]

You are NO Linux guy! A Linux guy cares about all things Linux, however slightly.

Wrong. A Linux guy cares more about Linux than any other OS and is one who's judgement perhaps has a little weight.
Like, if he's been programming since '85 or something like that and has been using *nix during the times when the only usable editor on it was Emacs or Vi.

You may not believe it, but I, and quite a few others who do computing for a living, actually have a life outside of computers and fiddling with init-scripts and xconfig. Partly because I've done that to death already back in the day when there was nothing else to do and making Gnome 1.x , Nautilus and GKrellm look like Star Trek was a cool way to spend your time.

*the old rooster ruffles his feathers*

Something nice about Systemd

[morgauxo]

Something nice about Systemd... well.. uh...

Systemd is PROBABLY not quite as bad as Dick Cheney.

There, how was that?

Re:Nice Thing: systemctl status shows you log entr

[db48x]

If you think you can add this nice thing to syslog, then please do. Quite a lot of people will sing your praises, in fact.

Service files are easy

[TheCycoONE]

Writing service files for my own daemons or modifying existing ones is pretty close to trivial. The files are short, easy to understand, and there isn't any risk of runaway child processes like there is with a sysvinit init script making them close to trivial to write and maintain. If anything I would say that's why so many distros are jumping on board.

I had to write service files as an early adopter, but it would also be useful for anyone rolling out their own daemons or that needed to tweak the behaviour of an existing service for their own needs. I imagine it would also lead to fewer packaging bugs.

Re:Thanks for making my point

[swillden]

In which case a nanny process restart is useless. Thanks for making my point, idiot.

Many hardware failures are transient, and a process restart is a very effective fix, at least in the short term. In the longer term, you'd better have monitoring in place so you know that the restarts are happening and can decide when to fix the hardware.

In addition, many process crashes are caused not by hardware failures, but by obscure software defects, and a process restart is not only effective at getting the production system back online, but arguably is a complete solution to the problem if the defect is sufficiently obscure that it's very rarely triggered, and hence not worth the large amount of effort required to identify and fix it.

VERY POSITIVE: Systemd is well-modularized

[Theovon]

Systemd is modular:
    - It's broken up into multiple independent processes, each of which handles one major thing well.
    - It's broken up into libraries so that commonly used code (such as parsing config files) is implemented once and shared among the services, saving memory (because you know how shared object libraries work, right?) and ensuring that there's only one implementation of any one thing that needs to be tested and debugged.
    - Interdependence among services is minimized, although as with any real, complex system, there are chains of dependencies.
    - Dependencies on and among services are handled on-demand so that only the services you need are running (often started well after boot). As a side effect, boot time is shortened.
    - Process 1 (init) is very small, with minimal functionality, in order to minimize the chances that it will crash.

The above are all true, or at least they are consistent with claims made by the developers. Sure, I have negative things to say, which are also true, but I don't want to add to the noise of all the false negative claims floating around.

Re:Rules for posting?

[wed128]

Why do we have to mention Bennett in the non-Bennett posts? can we just have a break please?

I'll explain it this way...

[dAzED1]

(stay with me here...) Once upon a time there was a community. In the community were lots of different opinions - Slackware, Redhat, Debian, the weird *BSD folk - we all worked together, despite being of different religions. We'd yell at each other, and to an outsider we'd look as though we hated each other, but we were yelling at each other at the same bar while buying each other drinks. We yelled at each other because that's just what we liked to do. We had a certain set of rules that we all followed - and those rules were our real religion. We contributed code upstream. We filed bug reports. We did code review. We contributed. We Kept It Simple, Stupid. RMS was one of our major prophets - maybe even a god (though, we often started rolling our eyes and heading home for the night if he showed up at the bar to drink with us). We laughed at people who would declare, year after year, that this would be the Year of The Linux Desktop.

Then, along came two things - Ubuntu, and modern capitalism/culture/media/whatever - a mindset where there should be no plan, just go go go new feature new feature new feature go go go (I'm looking at you Agile, facebook, google...). Suddenly, the highest and best praise your project can get became whether it was "disruptive."

The *NIX/FOSS community would not have been a place for this to take hold, were it not for Ubuntu. Ubuntu decided they would break all our paradigms - they'd refuse to contribute patches upstream, they'd take simple processes that worked well and left tremendous power in the user's hands, and replace them with very broken messes of stuff. (In contrast to what we had...) they'd make an experience that mostly worked for complete novices - to be distinguished from most other distros that rarely worried much if even their initial installer failed because meh, you should know enough to know how to fix it yourself. They'd ignore religious ideals like only using OSS. And last but most certainly not least, they replaced init.d.

Problem is, when a lot of new people started in on the scene via Ubuntu (and the like), the established distros decided that they had always wanted their distro to be the desktop featured in The Year of the Linux Desktop, and realized they were losing overall "market" share (@#$%@ for those nitwits thinking of people as a "market," when we had been a "community" for ages), even though the number of users of each of the major distros was still increasing. So they looked around at what Ubuntu was doing to become popular, and tried to decide what to adopt from it. Unfortunately, this new crop of people included the likes of Lennart Poettering, who would have ideas such as this one, regarding systemd. Instead of seeing diversity and differences as good things, those of his ilk decided to destroy (yes, a harsh word...but it's pretty much accurate) the FOSS community. An entire set of ideals just...disappeared. No longer are simple things kept simple, no longer is "Do one thing and do it well" followed, no longer do we try to let open inter-connectivity organically solve problems of integration (instead, we just birth a giant Rock Biter to mow our laws).

Systemd came from a new set of ideals where solving problems that don't exist is great, so long as the big bad Establishment is taken out. I actually saw it as a bit of agism - where youth expected to be peers to those who had been around for ages, and when they weren't immediately accepted as experts they just co-opted the entire environment and left us old farts without any toys anymore. Oh wait...you wanted something good about systemd. Um, well, my laptop now boots 0.5 seconds faster than it otherwise would have, even if I no longer know why and can no longer really do anything about it. That's good, right?

Re:I'll explain it this way...

[jbolden]

Your history is a bit off here. Linux's earliest intent was as a workstation OS. An operating system that Unix users could administrate and on their x86 box. A $2k alternative to buying a $7k Solaris workstation. RedHat itself came from this desktop mold, before the LAMP stack made the real action cheap server alternatives. Mandrake, Caldera Desktop, Corel Desktop were all doing easy desktop before Ubuntu. What was unique about Ubuntu was: it was free and gave away the CDs. Everyone else was trying to make money selling the operating system.

What you are right about is that Ubuntu created a generation of Linux users with no experience with other Unixes or often other Linuxes. In so far as Linux was ever successful on the desktop Ubuntu was the form of that success. Your paranoia about "disruption" and "the establishment"... is simply that. Exactly what do you think in the 1980-90s you were doing to the mini computer culture of the generation before you when you made client server cheap and ubiquitous?

For example, RedHat in 1994-6 was selling a commercial X-Server as an option because XFree86 was too hard and too crappy. That wouldn't have been the case if no one cared about ease of use or just doing bug reports.
____

As for the "no plan" that was part of Linux culture from the beginning. It was one of the things that distinguished the GNU community from the 386BSD guys (and the children that spun off to be the today's BSDs).

Re:I'll explain it this way...

[dAzED1]

Your history is a bit off here. Linux's earliest intent was as a workstation OS.

1) where in what I wrote did I say linux started as a server OS? Neverminding my first use of it as being just that, but "year of the linux desktop" doesn't - and never - meant that it would be the year someone would finally use it as a a desktop. I used it as one for many years.

2) Linux's first usage (and especially intent) most certainly was not as a workstation. "Workstation" has that word "Work" at the front of it because you accomplished "work" on the workstation, versus the work being the workstation. When I started using it in 94, no sane person would use it as a "workstation" because they'd be futzing with their machine too much. The mother's day release of redhat, which I still have on an old infomagic cd pack sitting on the shelf above my desk (for giggles), was not a "replacement" for a pizzabox in any far remote sense of the word.

Linux's earliest intent was to be a hobby plaything. It was for people who wanted to tinker around and play their hand at writing a device driver, or otherwise really know what it was their PC was doing. As for Linux being disruptive to UNIX - no, it wasn't. It was just cheap/free UNIX clone ala MINIX and other "learn-what-is-really-happening" educational tools of the time, but it still held the same "do one thing, do it well" principle, it came from/was birthed from the community/culture of UNIX users of the time, thus had more or less that same community and their ideals. Linux also never coopted anything - it eventually matured enough to be a competitor to the giants that came before it. Poettering's stunt was pure agism, as was that which allowed it to succeed. Change for the sake of change is and has always been stupid - don't try to paint it as a cycle, that Linux started the same way. Linux was an educational tool, and 100% of the rebellion of it was communistic; Ubuntu quite literally was anti-community from the start, as a core principle - as is and was systemd.

Re:I'll explain it this way...

[i.r.id10t]

Funny, every copy of Red Hat and Slackware I bought in the late '90s ('97 thru '99) came with a nice book/manual. Often times, worth the price of just the book/manual, install and source CDs were just gravy.

Re:I'll explain it this way...

[Wheely]

Hes right.

I was there too.

Re:I'll explain it this way...

[dAzED1]

PS -

" Exactly what do you think in the 1980-90s you were doing to the mini computer culture of the generation before you when you made client server cheap and ubiquitous?"

Wasn't nobody doin nothin with Linux in the 80s, and the PC world (Doom, etc) was already out and in full swing before the earliest (Slackware, for instance) distros were even started.

Re:I'll explain it this way...

[jbolden]

There was a Unix culture in the 1980s from which Linux came. As for the PC world that was similarly disruptive but Linux as a replacement for Windows was an ideology that came a few years after Linux as a cheap alternative to workstations.

Re:I'll explain it this way...

[jbolden]

Of course Linux came out of the hobbyist / Minix community. But that was before any of the distributions you mentioned more during the days of LSI. Most certainly people by 94 were using it for real work, that's when the entire cheap webserver movement was started. 1994 people were running NCSA HTTPd (what would become Apache) on Linux in production. 1994 people who used Linux most certainly did use it for productive work. Heck I was using it as a cheap replacement for a pizza box starting in '95.

As for Linux being disruptive to Unix, it most certainly was. The big Unixes are dead. But that's not what I said. What I said was Unixes, especially Linux and Windows server disrupted the early mini computing platforms.

Re:I'll explain it this way...

[Peter H.S.]

What a rose tinted look at the past. I was there too, but I don't remember the way you do at all.
The main reason why Linux took of was that it solved real world problems in an efficient way.
So many OS's have been made in order to follow some dogmatic doctrine about microkernels/"everything is a file" etc., instead of focusing on how to solve problems for its users, but not Linux.

So Linux made things possible for admins, developers and ISP's that was otherwise difficult or expensive. In short, Linux made money and increased productivity. That is also why its users fueled developer hours and money back into the Linux community. The LAMP stack wasn't made by a lone hero hacker, but a collective of business' and developers that saw an opportunity for making money or increase efficiency and getting a competitive edge.

The LAMP stack was never designed by the cartoonish Unix design interpretation of "only do one thing", in fact almost no program of any complexity is, yet this was what was driving Linux forward.

systemd is just yet another change in Linux that follows the old Linux philosophy on focusing on solving real world problems for its users instead of riding a "Unix/Posix" hobby horse.

If you are beginning to have problems with how Linux have always evolved, then it is you who are beginning to act old, not Linux.

Keeping Linux in an eternal 1990's time freeze where nothing must be changed will simply kill of Linux just like all the other OS's that forgot both their users and how to adapt to the times.

Re:I'll explain it this way...

[sjames]

I didtinctly remember not trying to piss in their well. They had their ecosystem and we had ours. We made no efforts at all to co-opt anything they had such that they no longer had it. Nothing that worked on vax quit working because someone was trying to cram a new system paradigm down their throats on their own OS.

They didn't suddenly find that when they attempted to install VMS, they got Linux instead.

If systemd's proponents are so sure their way is right, they should create a nice systemd fork of something and play with it all they want.

Or offer systemd as a true option and make sure it doesn't become "would you like systemd or do you want everything to fail?"

Re:I'll explain it this way...

[jbolden]

I still have RedHat's printed "Linux Man : The Essential Man Pages for Linux" manpages on my bookshelf. Way way out of date, but it is nice to browse. I miss printed manuals but I have to admit pdf and the web are better.

Re:I'll explain it this way...

[jbolden]

Nothing that worked on vax quit working because someone was trying to cram a new system paradigm down their throats on their own OS.

You mean like replacing DECNet with Unix style TCP/IP networking for example nothing like that happened? :) Or replacing VWS/UIS with X-Windows?

If systemd's proponents are so sure their way is right, they should create a nice systemd fork of something and play with it all they want.

That's what they did. Distributions are willing adopting it. People are switching over to their side.

Re:I'll explain it this way...

[sjames]

TCP/IP DID end up replacing DECnet, but not through political tricks. It was simply preferred. The DECnat fans were in no way prevented from running DECnet.

Likewise, X was made available but it wasn't crammed into VMS with no option to skip it.

That's what they did. Distributions are willing adopting it. People are switching over to their side.

If by willingly, you mean bent over a barrel, a tie vote in one committee, a pending general resolution to ban dependencies on systemd and a threat to fork the distro, then I suppose so.

Re:I'll explain it this way...

[jbolden]

TCP/IP DID end up replacing DECnet, but not through political tricks. It was simply preferred.

There are no political tricks in systemd. It was simply preferred.

The DECnat fans were in no way prevented from running DECnet.

Init fans aren't prevented from from init. What they are worried about though is that more and more stuff will have hard dependencies on systemd. In exactly the same way more and more stuff had hard dependencies on TCP/IP.

If by willingly, you mean bent over a barrel, a tie vote in one committee, a pending general resolution to ban dependencies on systemd and a threat to fork the distro, then I suppose so.

Nothing like that happened. It was introduced in the form of launchd a decade ago by Apple. Some people from the Linux community started to port it over. RedHat supported it. Ubuntu disagreed and Gentoo disagreed both creating alternatives. Their alternatives ran into problems and systemd pulled ahead quickly. It got adopted by a standard and then distributions started picking it up. Debian being one of the last.

Re:I'll explain it this way...

[i.r.id10t]

Yup - ya can't grep a dead tree.

But in the mid-late 90s, everyone was pretty much on dialup, unless they were at a college in a dorm, etc. I had a high speed connection thru work/school but then CD burners were several hundred dollars each. For me at the time, the best way to get a new distribution for install was to buy the book that came wtih the CD. The various Unleashed books, etc.

Re:I'll explain it this way...

[sjames]

The thing is, the dependencies don't actually make any sense. They only exist because of coding for political purposes. It's like requiring a degree in zebra training before you can get your drivers license.

Actually, launchd is quite different and nowhere near as objectionable from an architecture standpoint.

You should know that the debate continues in Debian.

Re:I'll explain it this way...

[jbolden]

The thing is, the dependencies don't actually make any sense. They only exist because of coding for political purposes.

I haven't seen any evidence for that. Generally the dependencies have been added to serve broader interests usually Free Desktop's or PaaS. I'm sure if you gave a particular dependency I could hunt down the why in under a minute.

You should know that the debate continues in Debian.

I see a small group of people unhappy in Debian. I'm not sure I see a debate. There are two sides. One side is saying "go with the flow" . The other hasn't presented a realistic proposal of what to do about upstream developers creating dependencies other than whine about them. They don't have anywhere near a majority and given they have a much worse argument I don't think they can get one.

Re:I'll explain it this way...

[jbolden]

There were duplications serviced by 1995 I believe. I tended to buy the commercial releases (RedHat, Mandrake) as the best alternative since they included extra commercial software.

Re:I'll explain it this way...

[sjames]

Why did logind depend on systemd?

It apparently wasn't necessary since it was possible to rip that dependency out (by a third party).

Why isn't journald API compatible with syslog-ng? That would eliminate a lot of objections.

Why isn't it OK to just call systemd from sysvinit's /sbin/init?

Why is udevd being sucked into the repo with systemd?

Meanwhile, the uselessd project has managed to carve dependencies out left and right. It is not currently a large project.

Why in the world would PaaS need any of them?

Re:I'll explain it this way...

[jbolden]

logind depend on systemd?

logind is part of process management. Users initiate process and the system needs to know what to do with them when they for example logoff, hit a powerkey...

It apparently wasn't necessary since it was possible to rip that dependency out (by a third party).

I can rip lots of functionality out of large systems that doesn't mean the functionality was added for political purposes. Those aren't the same thing.

Why isn't journald API compatible with syslog-ng? That would eliminate a lot of objections.

Because systemd knows more the state of the system than the syslogger so the functionality was brought in. Also they were adding functionality (example binary log messages) so to make it compatible they would have had to have written a new version of syslog anyway. Again not political.

Why is udevd being sucked into the repo with systemd?

Because the purpose of udevd is to have the kernel send messages so as to get process responses, that's process management which is a core systemd functionality. That's not scope creep, that's core scope.

Why in the world would PaaS need any of them?

PaaS needs complex process management in each node. So for example if node 56 is having problems keeping process T running which it is supposed to that:

a) It knows
b) It can do something useful about it.

Meanwhile, the uselessd project has managed to carve dependencies out left and right. It is not currently a large project.

Well yes. It is stripping functionality away so that systemd / uselessd just boots. Again I'm not arguing that systemd doesn't do more than just replace initd, I'm disagreeing that they added functionality because it was political.

Re:I'll explain it this way...

[aithiopis]

Capitalism?... OMG I was with you until you brandish capitalism as a bad thing. UNIX worked!, and does! Still! Simpler versions of it like Linux still do well. I'm an old fart too, and I despise systemd. But you know what? I'm not averse to trying new things. Yes Ubuntu led a lot of people into the UNIX world, that maybe shouldn't have come. It's still on my resume: "UNIX Systems Developer". I'm on the fence on systemd... I haven't played with it enough to care. The most recent Kali release has it because it's now in Debian. All I can say to the new farts is twofold: 1) Do one thing and do it well! and 2) Those who don't understand UNIX, will be DOOMED to re-invent it! POORLY! (see any windows product from the last 20 years.... I have a scheduler and I just reinvented cron but it doesn't work as well and I have to reboot my system every day)

Re:I'll explain it this way...

[Giant Electronic Bra]

It wasn't Linux that killed DEC, I was there and saw it. By 1994 DEC was toast and that was purely because you could spend $5k on an x86 box that could do as much as your $50k DEC Alpha 4000 series. It was mostly stuff like Tandem and commercial unix running on x86 boxes that ate into their business, not Linux, which was NOTHING at the time. Recall the products DEC rolled out to try to fight it, there was Alpha itself, then there was the Multia, and there were several other workstation products, none of which could compete with NT on a Compaq.

Linux was a little sprout hiding in a bush watching the giants kill each other back then. It sure had nothing to do with the workstation market, though around 94 it started to become modestly popular as a quick cheap 'put it on some old 386s' server for mail/bind/etc and some casual web server stuff. FreeBSD was actually both a better choice and more popular in all those roles at the time. The only reason Linux thrived was the community was open and easy to play with, so it grew large quickly. The BSDs were a lot more elitist, you weren't WORTHY to commit code there. Anyway, I don't think systemd is going to sit well with the community, ever.

Re:I'll explain it this way...

[sjames]

Lame excuses at BEST. The dependency in logind was hacked out by a third party. I gotta wonder, power management worked when sysvinit was on the job and there wasn't a logind at all. What happened? The actual existence of another less dependency laden way to do it suggests that such a way exists, yes?

That's how all of it has gone so far. Functionality isn't going away, just the hairball.

The logger isn't supposed to know or care about the status of the system, it's clients know and they send messages about it which the logger logs.

The purpose of udev is to add and remove device nodes and links in /dev in response to kernel messages about hardware being plugged in and out and in accordance with rules. It has been doing that since before systemd was an idea and should continue as it was. It doesn't care about processes at all and it shouldn't.

Note that systemd does not have any node management. It only knows what it is doing on that one machine. There is no cluster management in systemd. So if node 56 can't keep T running, all systemd can do is keep kicking T and have it fail again. Unlike systlog-ng, journald doesn't do remote logging, so it can't tell anyone about the failures.

But again, uselessd isn't losing functionality, it is moving it to where it belongs (that is, NOT in init). The architecture of systemd is piss poor and needs major revision. The first step is to cut things down to essentials.

A final point with the political nature, even knowing fully well that external dependencies are a sore point, rather than playing them down, the systemd supporters are talking them up to give the impression there will be an unacceptable amount of breakage if you don't switch to systemd now (switch now or kittend gets it!). That's disgusting.

Re:I'll explain it this way...

[jbolden]

It was mostly stuff like Tandem and commercial unix running on x86 boxes

SCO was never that big. The Unix running on x86 boxes was Linux. Of course Solaris on Sparc was cheaper as was AIX, NeXT, IRIX... And of course NT as your mention.

. It sure had nothing to do with the workstation market

By 1994-6 absolutely it did. It was the low end Unix option.

FreeBSD was actually both a better choice and more popular in all those roles at the time.

I don't think there was ever a time FreeBSD was more popular. 386BSD was more popular than Linux even earlier than you are talking about.

Re:I'll explain it this way...

[jbolden]

I gotta wonder, power management worked when sysvinit was on the job

No it didn't. Power management has been a consistent problem with Linux for 2 decades. Even when shutdown and restart work reliably, which is not guaranteed, the best distributions on the best hardware still run for less time due to making poor power choices. Power management is the kind of legacy of failure that is driving people to abandon the initd approach.

The logger isn't supposed to know or care about the status of the system, it's clients know and they send messages about it which the logger logs.

I'm not sure where this "isn't supposed to know" is coming from. You are assuming what you are trying to prove. You are assuming that minimalist logging is the right way to to do things. That's part of what systemd is disagreeing with. In systems with better logging (mainframes, minis, commercial unixes) the logger quite often does know and care about the status of the system. I'd like the option of a more knowledgeable logger.

Note that systemd does not have any node management. It only knows what it is doing on that one machine. There is no cluster management in systemd.

The PaaS takes care of cluster management systemd's job is to manage the low level details of the node. There most certainly is node management. Things like systemd-nspawn are used by GearD, Heat, Atomic (which used GearD)... The newer PaaS which depend on systemd can operate at a higher level of abstraction since systemd takes care of all the single node details. So systemd can create a security context and report status of a container to the PaaS.

BTW the query indexed log of systemd is a another huge advantage for PaaS. It can just ask the node a question and get an intelligent answer back about a specific process it doesn't have to try and parse its way through the entire system log.

But again, uselessd isn't losing functionality, it is moving it to where it belongs (that is, NOT in init).

If uselessd offers the same range of services as systemd then you have a genuine competitor for systemd. If they get there, then there is something to talk about. The pro-systemd argument isn't about architecture it is about functionality. The anti-systemd argument generally pretends this functionality doesn't exist and then based on not understanding why people want the functionality argue against the architecture. The same functionality with a different architecture is a fine compromise. If the uselessd peopel get there, good.

But I don't see the bodies on uselessd. By 4Q2015 you could have a half dozen PaaS with hard systemd dependencies. There is more functionality rolling in all the time. Right now they are trying to make containers even cheaper so that a wider range of applications can experience a custom OS, which means systemd is going to wrap 3rd party libraries and handle runtime dependency resolution for processes. Uselessd guys are going to have to keep up and catch up for lost ground. But if they do, great!

A final point with the political nature, even knowing fully well that external dependencies are a sore point, rather than playing them down, the systemd supporters are talking them up to give the impression there will be an unacceptable amount of breakage if you don't switch to systemd now (switch now or kittend gets it!). That's disgusting.

How is that different than anything else in open source? That's what Linux did to the commercial Unixes. That's what Gnome and KDE both tried to do. Open Source is open source. No one is taking away the ability to run init. What developers are are saying is they are going to do the work to support init. They aren't going to allow init to hold Linux back. There will be distributions that don't use systemd. There will be packages for a long time that don't d

Re:I'll explain it this way...

[Giant Electronic Bra]

I don't know what 'SCO' has to do with it. Tandem wasn't SCO, they were supplying their own NonStop solution into the financial industry, which drove DEC's VAX cluster solutions clean out of that space. They were acquired by HP in 1997. I know because I was and still am friends with a number of the DEC engineers who worked in their clustering group in the late 80's and early 90's.

Linux had nothing in the way of traction in the workstation market in the 90's, it was not a player at all in any commercial sense. There was a very limited use of Linux on Multias by DEC as a way to make a cheap XTerm out of a failed workstation product, that was about it. Workstations at that time were heavily dominated by SGI with IBM, DEC, SUN, and some smaller 3rd party Alpha and MIPS system resellers. Many of those were NT 4.0 based boxes. I know people who used these things, sometimes 1000's of them, none of them ran Linux on them, it was unheard of. They were almost entirely used to run specific commercial applications (CAD, 3D software like Lightwave 3D, etc) which were rarely, if ever, ported to Linux (for instance there were some custom ports of Adobe products, which certainly shops had access to around this time, but they were never made widely available even to Adobe's bigger clients).

BSDs were indeed quite popular in the hosting space in the early-mid 90's. Linux eventually eclipsed BSD in most shops by around '97, but particularly in the 93-94 time frame there were significant issues with using Linux in Line-of-business server applications. I should know, I was a significant supplier to and engineer of commercial web solutions, local ISPs, etc during this time. I set up a LOT of these people's IP networks, server rooms, built a lot of their first web applications, etc. This goes all the way back to things like the first discussion boards. In fact I may well have created THE first http based discussion board, hard coded handlers compiled directly into the CERN httpd that used BDB index files to implement multi-level threaded boards. It was all run under IRIX on big quad-core SGI servers. We had 128 megs of RAM in or main server that handled the NGA and some other organizations. I did buy a pile of Multias and got early RedHat working on them, mainly because BSD wasn't available for the Alpha processor they had in them. In any case, the point is BSD was at least as much used in the early server rooms as Linux was.

One of the real issues with Linux on a workstation in those days was A) there were no good graphics cards for PCs that could compete with the stuff on the workstations (and no drivers so you could run Linux on the DEC/SGI hardware) and CDE wasn't available on Linux. CDE was no prize but TWM was far more limited back then and it was mostly the only alternative. These days you can make a realistic Linux Workstation, but back then all the high performance hardware was proprietary and even the fastest 486s weren't in the same league with workstation processors, so I am not even really sure what you would have called a "Linux Workstation" back then. Believe me, had it been possible for there to be one I'd have been running it. My company had VERY good access to advanced hardware and software at that time and we played around with and used Linux a lot, but for real workstations it was SGIs or some of the Alpha based boxes, at least until around '98 when some of the Pentium II Xeon's started to show up with enough oomph to do the job.

Re:I'll explain it this way...

[sjames]

No it didn't. Power management has been a consistent problem with Linux for 2 decades. Even when shutdown and restart work reliably, which is not guaranteed, the best distributions on the best hardware still run for less time due to making poor power choices. Power management is the kind of legacy of failure that is driving people to abandon the initd approach.

I don't see systemd doing any power management at that level. None at all, in fact. That would be a 'forward looking statement'. Perhaps they'd care to give a call when it actually does something. But more to the point, power management is orthogonal to init.

If you want the logger to know more, then tell it more. But a logger is supposed to LOG messages, not generate them. If you want to know node status, you don't dig through logs, you run something like ganglia that tells you the current state of the node. I use that on a number of clusters and get quite detailed information without making anything dependent on it. BTW, if the logger can't log to something outside of the node, it is worthless for diagnosing a failure of the node.

I can see some value to a database of logs in some cases. I even wrote a log server that accepts events from syslog-ng and puts them in a database in addition to the text file form. Naturally, it is completely init system agnostic, as a logger should be.

If you want to dispatch jobs, use SLURM or similar. The HPC world has been doing that for a long time. Cluster schedulers can even power nodes off when not needed and on when there is work to be done.

How is that different than anything else in open source? That's what Linux did to the commercial Unixes.

How so? I can't think of a single instance where any part of GNU/Linux threatened to break something working fine in (for example) Solaris. All it did is say, we're here, check it out if you want, and then waited. Nobody tried to cram Linux down anyone's throat.

That's what Gnome and KDE both tried to do.

GNOME certainly has tried such crap (what a surprise, it's also associated with systemd!). That's why there are now two forks. You might have noticed that there isn't a lot of love for gnome 3. As far as I know, KDE hasn't drunk that particular cool aid.

As hor the rest, to paraphrase, it will be crammed down your throat and fuck you if you don't beg for more.

That's why there's a group ready to say fork you!

I want a well designed management system for my servers, workstations and embedded devices. That's why I will not be using systemd in it's current form. You may just want feature, feature, feature even if it is crappy in implementation and brittle, but that won't cut it for me. Fingers out of my pie.

Re:I'll explain it this way...

[jbolden]

I don't see systemd doing any power management at that level. That would be a 'forward looking statement'.

I agree it is. Right now it is doing the basics: /etc/systemd/logind.conf:
HandlePowerKey: specifies which action is invoked when the power key is pressed.
HandleSuspendKey: specifies which action is invoked when the suspend key is pressed.
HandleHibernateKey: specifies which action is invoked when the hibernate key is pressed.
HandleLidSwitch: specifies which action is invoked when the lid is closed.

But more to the point, power management is orthogonal to init.

Sort of. Process need to start and stop around power, that's process management. You really should see systemd as a process manager. Where one of the states it manages is initialization. Thinking of it as init plus some stuff is part of what's hanging you up.

BTW, if the logger can't log to something outside of the node, it is worthless for diagnosing a failure of the node.

Well first off the log is queried if things are going reasonably well. Also it can forward via. a systemd daemon.

I can see some value to a database of logs in some cases. I even wrote a log server that accepts events from syslog-ng and puts them in a database in addition to the text file form. Naturally, it is completely init system agnostic, as a logger should be.

But it shouldn't be process manager independent. Again init is just a small subset of what systemd does.

How so? I can't think of a single instance where any part of GNU/Linux threatened to break something working fine in (for example) Solaris.

It broke their whole ecosystem. It undermined their customer base. For example Linux's GCC pushed out Solaris CC's and more and more software wouldn't compile with CC.

Nobody tried to cram Linux down anyone's throat.

Of course they did. The commercial Unixes are dead. The people who switched away from IRIX, Solaris, Digital Unix... were most certainly forced by having their ecosystem undermined. Only AIX remains and that is fundamentally legacy (excluding NeXTStep which was workstation and became OSX).

GNOME certainly has tried such crap (what a surprise, it's also associated with systemd!). That's why there are now two forks. You might have noticed that there isn't a lot of love for gnome 3.

I'm talking in the GNOME1 days. To pick Ian's own Linux: Progeny Linux Systems which was his distribution was designed to allow for Linux to exist in components based on Gnome. KDE was not an option, Gnome was mandatory. UserLinux was similar.

Fingers out of my pie.

Get a grip. This is open source. There will be distributions that don't support systemd. If there is demand they will exist. There is no force here.

Re:I'll explain it this way...

[sjames]

So logind has managed to do what sysvinit does? That doesn't sound like a reason to screw up the whole system. Why do you claim that power management on sysvinit sucks but suddenly you think it's great when systemd does the same thing no better?

It seems to me that all of the great things systemd 'does' are forward looking statements and can be done better and less intrusively.

Sort of. Process need to start and stop around power, that's process management.

So change runlevels? If only sysv could change runlevels...

Well first off the log is queried if things are going reasonably well. Also it can forward via. a systemd daemon.

Too bad people typically need to diagnose failure when the system has failed. Seems like a good reason to just use syslogd. Now ask yourself, they clearly know how to speak syslogd's language, and clearly journald can't actually replace syslogd in the scenarios they claim excellence in, so why not speak syslogd all around and make journald a separate and optional component?

The commercial Unixes failed because the sellers demanded too much money for them and failed to innovate. Linux didn't piss in the well by coercing distros into switching. Linux didn't come up with a dirty deal to make gcc depend on the Linux kernel and make X depend on gcc in order to make it too much work to maintain solaris without the linux kernel. Linux (along with *BSD) won on merit. Perhaps systemd needs more merit and less pissing.

As for Gnome1, it didn't do any such thing. Gnome 1 was reasonably interoperable. Gnome apps worked fine in other desktop environments. Non gnome apps worked (and still work) in Gnome. Nothing broke if you installed it. For all the faults in Gnome 3, KDE/Qt apps still run and Gnome/GTK apps still run in KDE.

Systemd could clearly go that route but has deliberately chosen the obnoxious route. It is either incompetence or political in nature. Take your pick. I suspect political.

Re:I'll explain it this way...

[jbolden]

. Why do you claim that power management on sysvinit sucks but suddenly you think it's great when systemd does the same thing no better?

I didn't claim that. What I claimed was that power management properly belongs with process management because of the advantages it could offer. You then claimed that systemd didn't implement power management and I was showing that it most certainly did. Now on top of all that, it is already better in terms of success it already works better than it did with init.

So change runlevels?

No. Changing runlevels is shutting process down and breaking potential dependencies. That isn't suspending or hibernating them. Telling a process to shutdown is different than telling a process to wrap up immediate problems possibly save data and sleep. Or being able to know the state of the process to evaluate when it is safe to swap it out.

Too bad people typically need to diagnose failure when the system has failed.

No they don't. If a node has failed to the point it won't boot the node gets pulled and possibly diagnosed offline. Once a system fails, diagnosing is about whether the OS needs to be fixed or hardware needs to fixed. In terms of the PaaS it doesn't really matter much as to why.

Now ask yourself, they clearly know how to speak syslogd's language, and clearly journald can't actually replace syslogd in the scenarios they claim excellence in, so why not speak syslogd all around and make journald a separate and optional component?

I don't agree it can't replace syslogd. Nor do I believe that's where they claim excellence. Where they claim excellence is where a process has failed not where a system has failed. They don't make journald a separate component is they don't want their journal held back by using a 30 year old text based logger. syslogd is a bad way to do logs. It is not remotely sophisticated enough for process management. If there were a good reason to send journal to a remote system they would (and to some extent do) do that.

Part of systemd is they want you to move off the old paradigm for critical servers where jobs are tied to individual nodes. It is a paradigm change. You like to talk about force all the time. Initd was forcing people to process management the single box (Unix / NT) way. Lots of people (in particular developers) think that way sucks and instead are advocating for the way mainframes have done it. So they are introducing the capability to do it mainframe style. They are introducing an option that's all.

You keep asking "if all they are trying to do is replace initd why are they replacing all this other stuff" and the answer is always the same. The goal is not just to replace initd but rather to introduce process management, initd being just one part of that.

The commercial Unixes failed because the sellers demanded too much money for them and failed to innovate.

Too much money is too much money relative to Linux and Windows NT. They were cheap relative to minis and mainframes. That's Linux (and NT) forcing the kind of disruption you are complaining about with systemd.

As for failing to innovate you can't see the irony here in your defense of initd?

Linux didn't come up with a dirty deal to make gcc depend on the Linux kernel and make X depend on gcc in order to make it too much work to maintain solaris without the linux kernel.

I said CC. Linux pushed tremendous resources into GCC which then became good enough that it displaced CC even on Solaris.

As for Gnome1, it didn't do any such thing. Gnome 1 was reasonably interoperable. Gnome apps worked fine in other desktop environments.

I didn't say it didn't work on other desktop environments. What I said was it tried to create an e

Re:I'll explain it this way...

[sjames]

Initd was forcing people to process management the single box (Unix / NT) way.

WOW, no. Init was/is happy to get out of the way if you want to do process management. It even got out of my way when I built bproc clusters (global pid space, signals work across nodes, executables reside on the master and actually fork onto their assigned node. I do know a bit about this.

The rc scripts for those nodes actually ran on the master starting system daemons on the slave nodes.

Init wouldn't even get upset if systemd wanted to actually be a process manager and have init start it.

No. Changing runlevels is shutting process down and breaking potential dependencies. That isn't suspending or hibernating them.

So systemd is entirely inadequate? Because that's all it currently offers.

I don't agree it can't replace syslogd.

One day, it might, but for today syslogd can log remotely and journald can't.

If forward looking statements are good enugh, I claim that space goilg faeries will soon enhance inity so that it actually reads your mind and writes and runs programs to do exactly what you want, when you want it :-)

But in the real world, things systemd is "going to do one day" don't count today.

As for failing to innovate you can't see the irony here in your defense of initd?

You keep missing that I do advocate for a better system, and only claim that init does well enough today that we're better off sticking with it until it's all sorted out. Mostly, I just want an init that won't actively hinder development of a superior solution by insisting that only it can be in control at all times.

Ultimately I would like a well designed management system and that is not systemd.

The problem is, most of those 'features' are actually missing from systemd. They might be planned but they are conspicuously absent today.

I have seen that some of the dependencies are also not really there. My bad for believing the systemd project's claims.

Re:I'll explain it this way...

[jbolden]

WOW, no. Init was/is happy to get out of the way if you want to do process management.

It can't "get out of the way" part of process management is starting processes. It either does it or it doesn't do it. I get that process management can be done with init as a lower level. systemd takes a different approach where process initiation just becomes another aspect of process management.

So systemd is entirely inadequate? Because [runlevels ] is all it currently offers.

Not at all. The Requires and After keywords in the systemd system replace runlevels. There really is no need for runlevels with systemd at all. The whole concept is legacy. Distributions probably still make use of it mostly for compatibility.

One day, it might, but for today syslogd can log remotely and journald can't.

Hold on. journalctl --output=export sends remote log. It isn't a full featured remote logging system but most certainly it does do what syslogd does.

Moreover, you are contradicting yourself a bit. You basically arguing that system X is inadequate if there exists any feature what-so-ever it doesn't do. At the same time you are arguing that systems should have minimal feature sets. Systemd already offers way more features than init and the entire family. Systemd has different priorities and focuses. It is a paradigm shift. When it introduces full featured remote logging it is going to be tied to something much more sophisticated than syslogd, and that is future. Today though it is perfectly capable to spewing a stream on events over the network for a listener to pickup.

But in the real world, things systemd is "going to do one day" don't count today.

What is your entire charge about forcing people to do stuff other than forward looking statements? Again you are trying to have this both ways. If you want to make likely estimates about the future that's fine. If the only thing that counts is what currently has happened on November 3, 2014 then none of the forward looking statements about possible future problems apply.

You keep missing that I do advocate for a better system,

What does advocating for a better system mean in practice? Who is writing it? Where is this work being done? What is the project plan? When is it going to be completed? Who is paying? If 5 years from now a better system that systemd shows up then everyone can switch over to that. Systemd doesn't block the Unix community from moving to a better process management system or abandoning the idea of process management. If anyone wants to keep working on OpenRC no one is stopping them. But as of today, they are way behind and falling further behind. Unless you (or Ian) have some plausible plan then advocating doesn't mean anything.

I get that the anti-systemd people in some vague sense would tolerate better like your example of how xinitd allowed lots of servers without memory management. But mostly they are hostile to the paradigm shift. They object to better functionality on desktop. They object to better functionality for PaaS. That's the two uses cases they are objecting to.

and only claim that init does well enough today

Except that it doesn't do well enough today. I gave you a pretty simple chain and init couldn't come close to handling it. Init does nothing well. It is absolutely minimal process starting system. A whole range of hacks and problems exist because init sucks at its job. Going back decades, cron only exists because of deficiencies in init. The reason programs are switching to systemd is because they unhappy with the feature set of init. That's a problem today.

And even what it claims to be good at, it sucks at. On most systems falling back to lower runlevels doesn't actually work. I've tried taking a system

Re:I'll explain it this way...

[sjames]

You are clearly uneducable. I for one welcome our all singing all dancing date time display that edits photos, does my taxes, booots the system, makes ice cream, and starts world war three but can;'t actually display the date or the time because it's far too busy for that.

You are desperately twisting logic and semantics until they break to try to claim systemd is the ned God while showing that you don't actuially know enough to make the call. I have no idea why.

Re:I'll explain it this way...

[prsephton]

Nothing like that happened. It was introduced in the form of launchd a decade ago by Apple. Some people from the Linux community started to port it over. RedHat supported it. Ubuntu disagreed and Gentoo disagreed both creating alternatives. Their alternatives ran into problems and systemd pulled ahead quickly. It got adopted by a standard and then distributions started picking it up. Debian being one of the last.

Sorry, but this "just ain't so". On April 10 2010, in his article entitled "Rethinking PID 1", Poetering wrote:

Who's behind this? Well, the current code-base is mostly my work, Lennart Poettering (Red Hat). However the design in all its details is result of close cooperation between Kay Sievers (Novell) and me. Other people involved are Harald Hoyer (Red Hat), Dhaval Giani (Formerly IBM), and a few others from various companies such as Intel, SUSE and Nokia. Is this a Red Hat project? No, this is my personal side project. Also, let me emphasize this: the opinions reflected here are my own. They are not the views of my employer, or Ronald McDonald, or anyone else.

Facts are facts, and we can't bend them to suit our purpose, or make up history as we go along.

Re:I'll explain it this way...

[jbolden]

Employees in companies all the time have ideas. RedHat sponsored the project and put their institutional weight behind it. The fact that in 2010 Poetering thought of it as a personal project not withstanding.

Fight! Fight! Fight!

[redelm]

The nicest thing about systemd is that it is _NOT_ sysV and it is fighting/displacing sysV-style inits. Not that it is any better, mind you.

I like BSD-style inits (run Slackware) and I enjoy the controversy in a cautious "the enemy of my enemy is my friend" way.

I #*@%ing like it because...

[AddictedToCaffine]

I like it because it hasn't been proven to cause Tourette syndrome. The swearing it seems to cause is just a coincidence.

Re:What system d really is

[thegarbz]

I don't understand your train of thought. If anything there are several very VERY distinctly different ways distros are moving. RedHat is a big giant crawling in one direction, but so was Debian. I don't see the entire world dropping apt just because RedHat used rpm instead. Also wouldn't lack of resources imply they shouldn't focus on systemd? If a distro has enough resources to properly setup and implement systemd then I imagine they could do pretty much whatever they wanted.

Visability into the boot

[gQuigs]

Systemd during a normal boot is doing some detailed logging of the boot process that let's you do a simper version of bootchart. This allows you to find out how long each service took to boot and also do a graph of them.

It's concerned complimentary to the actual bootchart...

[1] http://0pointer.de/blog/projec...

Re:As long as it works

[thaylin]

Most users of Linux dont run it only on the PC. In fact the vast majority use it for servers. Linux desktop use is not going to grow any time soon, because the ma and pa of the world just dont want to change their ways. Changing our ways to fit Mas and Pas does not really need to happen.

Sophisticated Process Group Leader

[Anonymous Coward]

Back in 1993 I worked on a network process controller for Inmarsat-A. It had it's own custom init process group leader which erected unix domain IPCs between certain children, some shared memory segments, and performed a waitpid to relaunch any child process that died. I was new to the project and new to unix so when I suggested we use inittab to take over this task, the team lead just laughed. Init was not up to the task. The arrival of systemd finally addresses this use case: a process group leader that can care for of a hierarchy of tightly coupled processes. Systemd may be complicated, but so is the intended use case.

Re:Sophisticated Process Group Leader

[sjames]

Implicit in your statement is that the problem was already solved for the people who needed it solved without pestering the rest of us.

Re:Sophisticated Process Group Leader

[thegarbz]

Oh you feel pestered? Why because your favourite distribution thinks its a package worth having?

Maybe you should run a system that gives you choice where there are multiple vendors that do things differently and if you don't like what they do you may even be free to roll your own. I hear Linux is a good OS that meets that criteria.

Re:Sophisticated Process Group Leader

[sjames]

Perhaps you missed the article earlier in the week about a fork of Debian?

It is, however a bunch of work that shouldn't need doing since it is easier to drop systemd into a system that uses sysvinit (since sysv doesn't attract dependencies) than going the other way around.

So far, what I have seen is that 4 people in the Debian project voted to go with systemd. Four whole people and clearly others who weren't consulted are a bit ticked off about it.

Re:Sophisticated Process Group Leader

[thegarbz]

No I saw it. And in your reply you disagree with a choice Debian made which is entirely up to Debian and internal Debian politics, but you think it shouldn't be forked?

You can't have it both ways. Either you support systemd's inclusion, or you support the fork. Either way your comment has nothing to do with systemd and everything to do with your opinion on how Debian should do something. This is the very essence of politics, except that linux distributions are not a democracy.

Re:Sophisticated Process Group Leader

[sjames]

It shouldn't be necessary to fork it to avoid systemd, but if that's what it comes to, I do support a fork. I don't think that's very hard to understand.

It would be a lot easier to leave Debian as was and just have an add-in repo for those who want a systemd setup than it is to do it the other way.

Better still would be to make systemd a true option and make sure nothing depends on it specifically. Hopefully the GR to that effect will carry the day.

Re:Sophisticated Process Group Leader

[thegarbz]

It shouldn't be necessary to fork it to avoid systemd, but if that's what it comes to, I do support a fork. I don't think that's very hard to understand.

Actually that's a fundamental problem right there. The ability to avoid something creates a management nightmare. You want to give the user a choice? You now need to maintain sysvinit, systemd, and any interface required to switch them (setup, init scripts, the dependency tree etc). The problem increases exponentially. The closer to the system core you get, the more a distribution will hone in one and only one project as it becomes increasingly difficult to maintain multiple streams.

At some point forking becomes the only viable option for future development, and this is especially true in the open source world where you can't simply throw more developers at a problem and then charge more for your final complicated product.

Re:Sophisticated Process Group Leader

[sjames]

Now you're starting to see one of the reasons the hairball in systemd is so well despised. There are MANY choices available in Debian right now that cause no problem at all because the dependencies are well managed and kept to a minimum.

Done right, it should be possible to switch by changing the kernel boot command setting init=/sbin/sysvinit or init=/sbin/systemd. Note that switching an existing system from one to another might fairly be considered an experts only option due to the likely need for some fix-ups, but should be possible. Unless, that is, systemd demands or strongly encourages (one might say insists) that a bunch of system utils and software bow to it and become co-dependent such that hardly anything works if systemd isn't there.

Re:Sophisticated Process Group Leader

[thegarbz]

The hairball isn't in systemd but rather it's fundamental to that part of an OS. It's not that systemd is hard to integrate. It's not that you can't simply set it up to switch to it with a kernel option. You can do both of those things. It's not even that systemd mandates downstream dependencies, you can have anything downstream of systemd.

The problem is a few distributions have decided to change something quite complex. In the small developer world think of this as providing cross platform support for programs. Everything you do now needs to make sure it works on Windows and Linux. Your developer time has increased substantially as has the amount of coding you need to do to work around the nuisances of the different OSes.

We're not talking about Microsoft here with limitless resources to throw at developer problems. As it is many distributions have acknowledged they don't have the developer resources to product a 100% feature complete change every time, and they cop a lot of flack for it. Asking them to maintain and debug packages that are compatible with multiple init systems is a difficult feat.

At some point you need to cut losses and decide on which system you want to go with. Debian chose systemd. The right course of action is not to waste developer resources on appeasing everyone, but rather to fork the projects, just like the Ubuntu/Mint fork, and let one project go one direction and another go another direction.

Re:Sophisticated Process Group Leader

[sjames]

Which action burns more developer time? Staying the same or making changes to accommodate systemd?

I'm betting that one notice that packages relying on systemd would go to the if someone gets around to it dungeon, a lot would decide against dependency.

What they are doing now is paying the danegeld...

Re:Sophisticated Process Group Leader

[thegarbz]

I assume you've at some point noticed that no two init scripts are the same across any different distribution? I would wager that people would happily convert their software to something which requires about 10 lines of config to start a program vs the 200+ lines of bash that some init scripts use.

Suggesting that the status quo does not involve developer time is absurd. Heck Ubuntu developed their entire own init system because of the pains of dealing with the current init system. They shouted from the rooftops, look everyone, we can configure this service to start with 10 lines of code! Actually I think I recall OpenRC saying one of their features was also that it's easier to program for than sysvinit.

Re:Sophisticated Process Group Leader

[sjames]

But the scripts exist now, why so anxious to throw that work away?

However, when I write my own scripts, they generally do take about 10 lines and get the job done. However, compare a couple scripts from the same distro. You'll see that it is mostly boilerplate with names filled in, so not actually that much work. If it makes you feel better, write the ten lines and run it through a translator, perhaps even at runtime if you must.

Or, install OpenRC. As near as I can tell it is at worst unobjectionable (I have only glanced at it).

Re:Sophisticated Process Group Leader

[thegarbz]

But the scripts exist now, why so anxious to throw that work away?

Why? I work in the reliability field. There are many benefits to throwing away complex systems which require ongoing maintenance in favour of simple ones which are less likely to introduce random bugs. In many cases the change is worth the effort and usually resulting teething issues.

Right now we live in a world where Linux write-once run anywhere is basically not an option. For any service that starts at run time we are currently in the world of a) hope the distro has integrated the program and it's available as a specific package, b) hope the original creator included an init script for your specific distro, c) start the service in rc.local and pray. Every distro implements the exact same service, running on the exact same completely unstructured init system in a different way.

Now I'm not going to praise systemd here, but let me just say that at this point I'm open to any better solution which attempts to standardise the system startup in a more coherent way. If we had this conversation about a year ago I would be here saying the same thing about Upstart which I thought was fantastic when it came out.

To finish let me reiterate my point. I'm not talking about throwing away completed effort. I'm talking about replacing something that requires ongoing resources to maintain with something simpler.

Re:Sophisticated Process Group Leader

[sjames]

You should understand from a reliability standpoint why I would be reluctant to switch away from a system I have been using successfully for years for something that has had practically no time in production, particularly something where I have serious reservations about the design. I would much rather deal with the devil I knopw for as long as it takes for a new system with a decent design to come along.

For maximum safety, I would like that something to be able and willing to work alongside 'old reliable' so I can phase the change in and quickly revert if it screws up. Perhaps even define a runlevel to chain to the new system and another for normal operation under the old system.

But let's be realistic here. I can pound out a reliable init script in 5 minutes or so. It's not that I am some sort of scripting super genius, it just isn't that hard. From a reliability standpoint, why am I going to adopt an architecturally unsound init system to avoid that?

From watching uselessd, I can see that it took a one man team about a month to hack out a multitude of mistakes in systemd. Rookie mistakes honestly.

I am looking at a real answer to the problem that would be at the same time simpler and more powerful than systemd. Honestly, the biggest problem I'm having is hitting the moving target that is cgroup fs thanks to the munging about due to systemd sticking it's nose in. Imagine my joy that the systemd team broke their own "peace treaty" in less than a year. Now they want to claim total ownership of the API. You may wonder why I would go on about that. Simple answer, it shows the real focus of the project and it is not winning through technical superiority and reliability. The good news is that some of their bluster about cgroup seems to be FUD.

To be clear, I'm all for a better init, but systemd isn't it. Some of the ideas there could be part of it, but not without a better grasp of proper design and dependency management. The kitchen sink approach is not going to cut it.

Back to the scripts for a moment. One claim I keep seeing is of a translator that can take a systemd config and generate an equivalent script for init. Why not use that and skip the rest?

Re:Sophisticated Process Group Leader

[thegarbz]

You should understand from a reliability standpoint why I would be reluctant to switch away from a system I have been using successfully for years for something that has had practically no time in production, particularly something where I have serious reservations about the design. I would much rather deal with the devil I knopw for as long as it takes for a new system with a decent design to come along.

Oh I fully agree. I am a fan of the idea of systemd. I've played with it. I like the way it does things and the concept. But I am disappointed that Debian is making the move so early in systemd's infancy, and was happy that RedHat and Ubuntu were making the move. The idea is to iron out bugs early in more advanced distros and then put it into hard production on the typically stable distros. In many ways the only thing I fault about systemd right now is it's fanatically early adoption by distros which should be considered stable and slow moving.

I won't fault Systemd just as I won't fault Wayland for the same reason. They are both trying to accomplish a lot and people expect a lot of them despite effectively still being babies. It's disappointing to see people adopt it so quickly before it has time to mature, but I am not the least bit disappointed to see the old init system go.

I will get one thing off my chest at the risk of starting another debate, I don't like uselessd. The creators of uselessd seem to think systemd was supposed to be an init system replacement. It's not. Never was. Never going to be. Systemd was a fundamental one stop shop for complete system management. The uselessd project seems to have ripped out many of the features of systemd that I think were great, such as unified logging, login management, hardware management etc. But this is just my opinion and it is not a popular one so I won't argue it any further.

One claim I keep seeing is of a translator that can take a systemd config and generate an equivalent script for init. Why not use that and skip the rest?

Because I would imagine it is a load of crap that strips out all the useful functions of systemd? Process monitoring, logging support, event based startup sequences, none of that are possible on sysvinit so I wonder what value such a script would claim to have.
On the other hand I have played with an init script generator before. Ubuntu even included one at one stage, though I haven't played with linux dev in a while so I'm not sure if it still does. Suffice to say after spend half an hour getting it to work I copy/pasted another script and massaged my crappy little program into running. But that duplication of effort, and as I learnt duplication of bugs is not at all what anyone should consider good programming.

Re:Sophisticated Process Group Leader

[sjames]

A clarification of uselessd may be in order. It does not appear to be removing functionality, just changing it form excessively tight coupling to loose coupling. It still supports logging, it just logs through the well understood and time tested syslog. It still does process monitoring, login management, and hardware management. In fact, it allows systemd (uselessd) to do process management without being the system init.

Personally, I would prefer to further split up process management by assigning a monitor process to each process to be monitored with a common API. Thatwould make it much easier to, for instance, write a new monitor that actually polls the service it monitors using it's standard interface in order to detect a process that is still technically running but is in a wedged state (for example, accepts connections but doesn't actually respond to queries). It would be nice to be able to just drop that in with no way that a bug in the new monitor will affect other monitors.

Such separation confines failures and that is a cornerstone of reliability.

I find it interesting that Debian has supported runsv to monitor services for some time and NOBODY seems to use it EVER, yet suddenly there is a burning need for process monitoring (apparently not runsv).

Re:Sophisticated Process Group Leader

[thegarbz]

Uselessd is a return to the Unix philosophy of systemd, it is actually what I'm complaining about. The great thing (in my very minority opinion) about systemd was that it was bringing all these separate features under the one hat. Centralised system design an operation rather than a mess of separate programs each doing their own thing leads to endless complication. I prefer the other way but I won't reconcile this with you because I can't, it's a philosophical difference.

Debian has supported a lot of things over the years. Most of those things which weren't defaults were an absolute pain to set up, so I can easily understand why it was ignored. While I don't know much about Runit, it was also supported by Ubuntu, who then went on to create Upstart which did what looks like almost the same thing. So I'm sure some people thought it was worth while.

But really the people who are praising systemd for any of its features in isolation are ignorant of other software out there. If all you want is supervision then systemd is not for you. If all you want is simple startup scripts systemd is not for you. Those problems have been all individually solved. It's like one of my astronomy friends installed an entire linux distribution to get a simple command line plate solving program working. I showed him how to do it in cygwin and it blew his mind.

Re:Sophisticated Process Group Leader

[sjames]

Funny thing, runnit is in by default. It gets called by init. It just doesn't actually do anything by default but get called and see that there is nothing to do.

If you and others like systemd, I'm fine with that. My objection is to the way freedesktop tries to leverage dependency (and FUD about dependency) to cram it down my throat. Why is it such a problem for it to do its thing and leave the rest of us alone?

You are, naturally, welcome to your own philosophical view, but it seems odd then that you would be involved in an OS so fundamentally opposite to your philosophy.

Re:Sophisticated Process Group Leader

[thegarbz]

I'm not involved in an OS that is fundamentally opposite to my philosophy. Many of the programs I use a insanely large behemoths of interdependent design. Only the simplest of functions remain true to the "Unix way" Heck X11 implemented it's own print server for a while. That really is the classic example, but I can use others. One of the first things I do when I install any system is try and centralise it's management. Webmin as a central interface to manage services, modulo for monitoring resources and logs, and then there's a myriad of GUI applications that control everything. Once a system is up and running it's quite rare for me to have to use the console and especially the | key for anything. I don't read log files by grep |awk| seding, I don't check system health by running du, df, top, etc. and I do it all from the biggest one program does everything in the world solution out there, the X-windows system. I just see systemd as a next step in the way Linux has been going for a long time, and while it's not "Unix like" it certainly is only one of a large number of programs that isn't either. But really I think very few people use a system due to some philosophical view. I use it because it presents excellent value for money, it does far more than the alternatives.

You are right about the fud though. While I am a fan of Systemd (and also Pulseaudio) I am not a fan that it is being presented as a sole choice in most distributions, before it has a stable use case and is deemed fit for service, and under some dependency guise (I'm looking at Gnome here is the key offender). Down stream software should not now nor ever have a dependency on a system application). I hope it gets resolved if for no other reason than the dependency presenting a colossal distraction from what should developers working on making their respective programs better.

Re:Sophisticated Process Group Leader

[sjames]

You just named a bunch of stuff that builds upon small interchangeable components. For example, you have a display manager that runs an external X server and then displays itself. It uses pam to determine if you entered a valid password. If so, it changes user and runs a window manager and session manager on top of the X server. All of those components can be mixed and matched and none of them are part of the same project. You could also choose to log in on the console and then startx, skipping the display manager. You could run X by itself and then a GUI application on top of that and have no window manager. You can run just the X app redirected by ssh (or directly) to another X display (which may or may not be the same version as the one on your usual desktop. That's not counting adding in some combination of xpra, vnc, and RDP. Often you can switch window managers out in a desktop environment.

Meanwhile, once you get that loose collection of parts up and running, you start your browser and connect to webmin (through apache). Then webmin (unless it has changed a LOT) shells out to those system utilities you didn't realize you were using in order to gather information to display and to carry out your commands.

Agreed that adding a print server to X was a mistake, but because it's all done the Unix way, you can at least pretend it doesn't exist and avoid the worst of that dane brammage.

It seems unified to you because each part is designed to inter-operate the Unix way and the default stack of parts is well chosen to work cleanly. You may not even notice if you end up running components of 3 different desktops at the same time. But it sure can come in handy to be able to re-arrange those pieces nearly arbitrarily sometimes.

Re:Sophisticated Process Group Leader

[thegarbz]

And you just described systemd which includes 3 core components (systemd, udev, journald) and the rest of the 60 something other parts are optional libraries or command line utilities. Of those 3 core components systemd depends on the other two, but the other two can optionally be run without systemd. Interestingly enough for modularity while Ubuntu were transitioning upstart briefly depended on some components of systemd but not systemd itself which lead to some interesting forum discussions from people trying to figure out how to use systemd which didn't actually exist on their system but none the less flooded the console when "locate systemd" was typed.

I'm sorry but the interdependency of X is far worse than it ever has been for systemd. Claiming one is following the unix way and the other is not is absolutely mad, especially when X's own developers have spoken out against it and the unix way.

The problem is not the latter part of the statement "do it well". But I think the Linux world needs to stop being obsessed with the concept of "do one thing". There is actually a lot out there that does far more than "one thing" but it's rationalised under the view that those things form part of some whole. People are happy to justify that for displaying a graphical system (X windows has some 50+ required dependencies most of which are maintained by the X.org themselves), but for a system manager everyone loses their mind. People still think computers are as simple as they were 20 years ago and the end result is most of the threads in this comment section has devolved (or rather evolved since it's a more complex topic) to a discussion of philosophy, technical merits be dammed.

Re:Sophisticated Process Group Leader

[sjames]

You left out a gratuitous replacement for ntpd that depends on systemd, logind which depends on systemd (or did until it was hacked), the dhcpcd that depends on systemd, Gnome depending on logind that depends on systemd, etc. Need I go on? All that for a supposed process manager?

Of course, if X screws up, you don't get stuck with a system that can't boot. You get a console that works that you can use to fix the thing.

As for the modularity, where is it with systemd? Where is the replaceable zombie reaper? Deciding I want init to start the system but systemd to monitor processes? Don't fancy journald but want process management? X allows me to mix and match to that granularity easily.

I don't claim perfection for X but the fundamental idea is very much appropriate to Unix. It has had a problem with barnacles since then which may be what you were seeing complaints about.

Believe me, I know computers are more complex now. 20 years ago you didn't have to initialize the RAM chips before memory started working. But I see nothing there that suggests abandoning a successful design paradigm.

In fact, personally I am happy to see some elements of plan9 showing up.

Re:Sophisticated Process Group Leader

[thegarbz]

System manager. Stop calling it a process manager, you're just confounding your own misunderstanding as to what the thing is designed to do (hint: it's in the name "system"d). Every program depends on something, what's your point? Are you suggesting that I should be able to run gdm without libxrenderer on which it depends? The key point here is that none of the programs you mentioned (probably even if you did go on) actually are required to run systemd, saying they should not have systemd as a dependency when they are written specifically to expand its functionality is absolutely asinine.

Granularity is there except for 3 components. If you're upset that 3 core components depend on each other then you have bigger issues than systemd and I sincerely hope you never try to build linux from scratch, it may blow your mind. Your precious design paradigm is as much preserved with systemd as it is with apache, the modern version of which is basically useless without loading about 50 additional modules to make common internet functionality work.

Like it or not most Linux programs depend on something or other. In fact managing dependency hell is the very thing that consumes most of the time dedicated to distribution maintenance.

Continuing this discussion is pointless. We're going round in circles.

Re:Sophisticated Process Group Leader

[sjames]

Honestly, if you will contemplate why I would applaud the moves uselessd has taken and why I might consider it to be correct even while the project it forked is wrong, you may gain enlightenment. Your entire view of how a system works will change in ways that will leave you unable tyo imagine why you couldn't see it in it's simplicioty before.

Your choice.

Re:What system d really is

[olau]

The reality is that before systemd showed up, there wasn't really any project with an active upstream that tried to solve the plumbing problem (I'm not talking about init in isolation here). Each distro had to invent their own hacks, some of them good, some of them not.

The fact is that the community that is beginning to form around systemd is much more healthy than the scattered bits and not-quite-fitting pieces we had before. Maybe that's sad, I don't know. I think that in the end, the unification around systemd will allow competitors to form (just implement the interesting subset of the systemd interface and you can integrate with all distros!). So long term we'll end up with a much more vibrant plumbing for Linux.

Any relation to Systeme D -- the restaurant term?

[unfortunateson]

I wonder if systemd was named with any irony to match the "System D" mentioned in Orwell's "Down and Out in Paris and London" and referenced by Anthony Bourdain's "Kitchen Confidential?"

System D refers to the whatever-means-necessary, MacGyver-ing, theiving, gerry-rigging, etc. that chefs and other restaurant workers may do to ensure that the service works without management or patrons noticing a problem. The term comes from "dbroillard" (Down and Out p78):

"Dbroillard is what every plongeur [dish washer] wants to be called. A dbroillard is a man who, even when he is told to do the impossible, will se dbroiller--get it done somehow."

Re:Any relation to Systeme D -- the restaurant ter

[unfortunateson]

argh, should have read the preview more closely - it should be débroillard. I tried using unicode characters, which obviously didn't work, when I should have used the entity.

Is this some kind of a test?

[preflex]

Holden: You're in a desert, walking along in the sand, when all of a sudden you look down...

Leon: What one?

Holden: What?

Leon: What desert?

Holden: It doesn't make any difference what desert, it's completely hypothetical.

Leon: But, how come I'd be there?

Holden: Maybe you're fed up. Maybe you want to be by yourself. Who knows? You look down and see a server, Leon. It's serving web pages ...

Leon: Server? What's that?

Holden: You know what a computer is?

Leon: Of course!

Holden: Same thing.

Leon: I've never seen a computer... But I understand what you mean.

Holden: You reach down and install Microsoft Windows on it, Leon.

Leon: Do you make up these questions, Mr. Holden? Or do they write 'em down for you?

Holden: The server lays on its back, its case baking in the hot sun, thrashing its hard drive trying to boot up, but it can't. Not without your help. But you're not helping.

Leon: What do you mean, I'm not helping?

Holden: I mean: you're not helping! Why is that, Leon?

[Leon has become visibly shaken]

Holden: They're just questions, Leon. In answer to your query, they're written down for me. It's a test, designed to provoke an emotional response... Shall we continue?

[Leon nods]

Holden: Describe in single words only the good things that come into your mind about... Systemd.

Leon: Systemd?

Holden: Yeah.

Leon: Let me tell you about Systemd.

[Leon shoots Holden with a gun he had pulled out under the table]

Re:Is this some kind of a test?

[Bootsy Collins]

I'd mod you up if I could.

Re:Thanks for making my point

[olau]

In which case a nanny process restart is useless. Thanks for making my point, idiot.

Your logic is flawed. Random bit flips sometimes happen. They don't necessarily take down the whole machine.

I can say something nice

[DrXym]

I've not had any issues with it and my machine starts faster. It works. Most of the objections to it appear to boil down to personality and philosophical issues rather than whether it is technically sound, e.g. the way the devs interact with the kernel devs, or whether it's too close to the way services work in Windows.

Having read the myths page I largely believe it was the right thing to do. Linux is a living operating system and sometimes it has to be dragged kicking and screaming away from things that may have been acceptable in 1990 but not when going against other modern operating systems. Wayland is another ongoing example of that and I'm sure that once it becomes the default choice in some dists that we'll see people being extremely vocal about that too.

Re:I can say something nice

[armanox]

What do you mean we won't see vocal before people before then? Plenty of us are screaming now, because we will matter even less later. You know, because cross platform compatibility was never for any sort of unix based project....(systemd might work fine on Linux, but it doesn't work on anything else. And some software (GNOME) is becoming dependent on it. Not like GNOME has ever been used on other unix operating systems or anything....).

Sounds like features

[Anonymous Coward]

Looking through all the comments it sounds like most of the things people like about systemd are things that could have been done in existing init systems, or at least without absorbing a million features into systemd.
  * exit codes: normal init systems should be able to care about them
  * stdout messages: normal init systems should be able to redirect those, or better yet, the daemons should be written to output to a log or something themselves, instead of outputting important messages to stdout where no one will ever see them.
  * cgroups: old init systems should be able to use those. This seems like something that was just not integrated yet, because cgroups are relatively new I believe.
  * parallel starting: old init systems should be able to this if the dependencies are described somehow.

What I'm not seeing here are any compelling advantages of systemd having its own built in cron, network manager, session manager, udev, logger, etc, etc.
It sounds like all of those could still be run separately without getting rid of fast start-up times and whatever cgroups gives you.

The best thing about SystemD is.

[james_in_denver]

Poettering get to pretend that he's Linus. That, and it manages to start all of the services correctly on my system without hanging about 9 times out of 10. Aside from that? as previous posters have said, if a service stops/crashes for some reason? I want it to stay stopped until i can figure out what is wrong. MySQLD? out of disk space? I don't want that to keep on yo-yoing up and down until i have it fixed. I agree, SystemD should be optional, you want it on your phone/IOT device? fine. My server that I reboot about once every 2-3 months? I want init.

Re:The best thing about SystemD is.

[Barsteward]

I would hope your application would tell you that you are out of disk space and deal with it accordingly.

Re:The best thing about SystemD is.

[Peter H.S.]

You don't have any knowledge about how systemd restarts services. You haven't read the systemd documentation, but instead seem to rely on some random systemd haters wrong info about how systemd restarts services. Think about that.

systemd doesn't restart services unless told so. And it can be quite intelligent about restarts, distinguishing between several different ways the service was terminated and making conditionally restarts depending on the service's exit signal and combining it with rate limiters.

Try reading the "Restart=" section here to get a glimpse of the many options:
http://www.freedesktop.org/sof...

Re:The best thing about SystemD is.

[thegarbz]

as previous posters have said, if a service stops/crashes for some reason? I want it to stay stopped until i can figure out what is wrong.

So set that in a config file. Should be simple since the config file is typically a few lines, and not a 200 line long bash script.

Re:The best thing about SystemD is.

[Zontar The Mindless]

Poettering get to pretend that he's Linus.

As I've said before, I have come to believe that the whole systemd kerfuffle has its origins in narcissism. Poettering's. How else to explain his apparent complete lack of tolerance for dissent or divergence?

...SystemD should be optional, you want it on your phone/IOT device? fine. My server that I reboot about once every 2-3 months? I want init.

Like many people's servers, my *desktop* gets rebooted once every 2-3 months.

This is one of the 2 main reasons I run Linux on my desktop, the other being *cough* freedom *cough*... *sigh*

Why dislike something you know nothing about?

[backtick]

Background: I've professionally administered Unix and Linux machines for >25 years, including various BSDs, Linuxes, Irix, HP-UX, Solaris/SunOS, AIX, etc. I've been certified by several vendors or distributions, including, since 1999, Red Hat (which gives me quite a bit of background on their specific implementations over the years). I don't work for a company doing development of any OS or platform. heck, other than random 401K type aggregate ownership, I don't own stock in any company that cares about this issue at a deep level, to the best of my knowledge :)

Personal Bias about this thread: You pretty much lose all the credibility possible with me when you start of with "I ... dislike systemd because ... it looks ... like a poorly-described, gigantic mess I know nothing about ... ." (It's the "disliking something you know nothing about" that bugs me). Otherwise, I don't care much about this debate on a personal level. I currently admin boxes using systemd as well as everything else, and nothing about systemd has caused me anywhere near the heartache that it seems people who haven't used it much seem to feel about it.

Seriously, there're thousands of pages of documentation about what it is, how it works, and what most if not all of the design basis decisions are/were. I'll link you to a few of them because hey, you can get to slashdot and post, but you can't seem to use Google ;) (tongue in cheeck, of course). There're plenty of folks who DO have great detailed reasons on why they don't like bits and pieces of it, and you should be able to compare them to the various info I'm linking below.

Systemd has tons of upside and tons of downside. Most are pretty well detailed, although many of the gut reactions people seem to have to it are based on a lack of understanding about how it works and what it's compatible with, to wit "I can't use shell scripts for anything at startup anymore!" , "All of my old chkconfig or SysV scripts can't be included at all!", "It kills off syslog!", "The only reason it exists is to make laptops boot faster and in the server world we don't care", etc. Those are easily researched and the actual basis (or lack thereof) pretty easily found.

So, for why the systemd setup looks like it does, you can go back 4.5 years to where the announcement and rationale is described. Speed is part of it, as is device changability, as is double-forking, resource limits, and service state checking and recovery. Yes, it's a load of stuff. Definitely a system-wide approach VS a semi-random collection of various ways to do things all tacked together (which is, frankly, what most Unix and Unixlike systems are, through survival of the fittest).

http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

Since RedHat's obviously the largest major proponent and arguably the source of the most production users, here's their documentation:

https://access.redhat.com/docu...

Here's the project page with loads of links about the software and uses cases:

http://www.freedesktop.org/wik...

And of course so many questions have been raised the developers have posted their rebuttals to myths or misunderstandings.

http:/

Re:Why dislike something you know nothing about?

[DamonHD]

Thanks: that was the most level-headed primer that I've seen.

Rgds

Damon

Re:Why dislike something you know nothing about?

[gweihir]

Yes, that is just the point. The systemd proponents are all falling for "new" = "good" and miss that this is both untrue and that the idea of systemd is not new either. There is a reason SysVinit is still perfectly capable of doing the job after 22 years. And that reason is precisely that alternatives have far more problems that it has. Sure, it is not perfect, but why some upstarts that do not even understand basic things like the UNIX philosophy think they can do better is beyond me. And their modus (embrace and extend) is completely all by itself.

It is a mystery for me why they were not laughed out the room the first time they presented their "better" "solution". The only explanation I have is that far too many people either do not remember or never understood how difficult it was to arrive at things that work and do not have to be replaced every few years.

Re:Why dislike something you know nothing about?

[gweihir]

It is. The kernel is special for a number of reasons that decidedly do not apply to an init system. And then there is the little problem of how systemd is pushed, how it devours every other little service it can get its hands on, how it has some utterly moronic decisions in there that alone disqualify it (e.g. binary logs that can lose the least few messages before a crash), etc.

Seriously, if it look bad in several respects, it very likely is. It actually does not matter anymore what its advantages are, its disadvantages are prohibitive.

Re:Why dislike something you know nothing about?

[sjames]

All those pages written and still nothing coherent and useful to someone who hasn't already drunk the cool aid.

Perhaps that's the problem. I tend to stop reading when a document claims the new thing is a zillion times better than the old thing because it can (insert description of what the old thing already does).

The rebuttals read like Ronald Reagan at a press conference. Question asked, he answers a different question, nobody seems to notice he never answered the question.

Re:Why dislike something you know nothing about?

[AdamWill]

"Since RedHat's obviously the largest major proponent"

For the record, there's absolutely nothing 'obvious' about that. People tend to assume that since Lennart was @redhat.com when he wrote systemd it's 'obviously' a Red Hat project, but it really isn't, and never was. It's a Lennart project: he came up with the idea and he wrote it. Red Hat didn't ask for it, didn't actually have any idea it was coming.

The very first instance of all these battles that get fought every six weeks in some distro or on /. or on Phoronix happened in Fedora, when Lennart first proposed switching to systemd. Around the same time / a bit later, all the same battles happened within Red Hat. Just as with every other distro, systemd's proponents brought the idea and argued for it. systemd wasn't planned from the top down by 'Red Hat authorities' as 'our new init system', Lennart came up with it on his own, and convinced the plurality of significant folks/bodies within Fedora and RHEL that it was a good idea.

Re:Why dislike something you know nothing about?

[Gunstick]

how does systemd compare to solari's SMF?
I did not at all get along well with SMF. Too cumbersome for the little bonus it brings.

Re:Rules for posting?

[jeffmeden]

I hope Bennett doesn't see this and start including rules for how we're allowed to reply to his posts...

If his posts were a tenth as thought out as this one is (however odd it is that they decided to put this much thought into goddamn systemd) I would think it to be an improvement.

Process management in a consistent way

[jbolden]

OK I'll try this. Traditionally Init services were about starting processes. They didn't have capacities for keeping processes running. Which meant that for processes that need to be kept running and for which there was a real possibility of failure (most of them) the init had to start a process management system which then started the functional process. This has been the status for years. With systemd there is a process maintenance component standard in the init system. Which means that processes not only start but are capable of being kept in a stable state easily and automatically. Process management stops being something system admins work hard at and instead becomes something that happens out of the box.

Re:Process management in a consistent way

[The Technomancer]

My counter to that:

If I'm at a shop that has 5 9s SLAs, I don't want a superserver crash to take out my whole OS. If supervisord or inetd craters and does so in a fashion that doesn't allow it to come back up without intervention, I want the option of running in a degraded state by bringing up the supervised processes via init.d until I can either troubleshoot the superserver, or chalk it up to gremlins and bring up a replacement instance or spare box.

If there's one fatal flaw in systemd's design, it's that system designs based around systemd assumes that systemd will never crash. The best software out there crashes or locks up to the point of being a de facto crash, so as a systems architect, I need to have failsafes to keep me running in a degraded state so I don't fail my SLAs, and systemd tells me "Don't worry, I won't fail!".

Re:Process management in a consistent way

[jbolden]

I'm not sure in a 5 9s environment you would care about boot issues. Every machine is already redundant so the only time a new machine would be coming up is

a) When it is entering as another node
b) When it is introducing a new / replacement service

An individual system should never be running in a degraded state.

Certainly systemd itself will create a situation like the kernel where if it were to have a critical bug that prevented it from running the system might not in any useful / meaningful sense boot but it isn't going to get through even early testing in that situation. I just don't see how there is any impact on production from possible systemd bugs that are that catastrophic.
 

Re:Process management in a consistent way

[The Technomancer]

All it takes is one buggy release, or a junior admin making the sort of bonehead error that we all made while earning our stripes.

$DEITY forbid that you want to remount your NFS shares because you're cutting over to a snapmirror of your Netapp to perform maintenance (or have the vendor perform it). Pardon my language, but systemd absolutely shits the bed when that happens.

These are edge cases, to be fair, but they're edge cases that affect many common enterprise-grade setups, and I'd hope that it's common sense to expect that an application-level edge case won't crater my systems. Like another poster had said earlier, I really wish they'd split off systemctl from the rest of it. systemctl's a sweet piece of software that does handle services much, much better than previously. It's the rest of the bundle that turns systemd from a plus into a liability.

Re:Process management in a consistent way

[The Technomancer]

My LinkedIn's in the homepage link (hint: I write code for a living). Post yours, and quit whining because a sysadmin wouldn't push your broke-ass code to production.

Re:Process management in a consistent way

[jbolden]

$DEITY forbid that you want to remount your NFS shares because you're cutting over to a snapmirror of your Netapp to perform maintenance (or have the vendor perform it). Pardon my language, but systemd absolutely shits the bed when that happens.

I would think AutoFS would take care of that and systemd would be out of the picture. Or if you want to do it manually it would be just like what you would do with init except instead of directly unmounting you disable the service associated with the NFS mount. I don't think I'm following the objection here.

to be fair, but they're edge cases that affect many common enterprise-grade setup

Well absolutely being able to handle filesystem failures is mandatory. I'm still not quite understanding what you are saying doesn't work here.

Re:Process management in a consistent way

[sjames]

The work isn't hard though. What is hard about while true; do run service; echo "damnit"|mail -s 'crashed again'; sleep 30; done?

Monitoring and restart in one line!

Re:Process management in a consistent way

[jbolden]

What if the process has dependencies?

So assume
A and B depend on C, D and E.
D depends on E.
D and F are currently communicating but no dependency.

E crashes.

Re:Process management in a consistent way

[The Technomancer]

You need to use systemd.automount and/or have it managed by an /etc/nfstab entry to ensure that a remote filesystem is available to include it as a dependency for bringing up the service rather than just ensuring autofs is running as a dependency, which may or may not have actually mounted the filesystem in question.

Only despair lies down the path of trying to make those two coexist.

Re:Process management in a consistent way

[sjames]

E restarts due to the loop. The dependents either re-connect if well written or if not then they crash and get restarted. In such a case you'd want to insert a test for availability of dependencies in the loop.

In the most extreme case, you could even do something like make runlevel 2 the default and have /etc/rc2.d/S99gothree run telinit 3. In runlevel3 your services start in the dependent order like:

Start_servivce; telinit 2

So, server comes up in runlevel 2, then transitions to three starting the production services. Should one of the production services fail, the server tramnsitions to runlevel 2, shutting down all of the production services, then transitions back to runlevel 3 to bring them all back up in order.

More broadly, there are any number of solutions to the problem that are far less intrusive on the rest of the system.

Re:Process management in a consistent way

[jbolden]

Well actually the dependency could be loading the particular filesystem or it can run a check. But assuming not... then the loading daemon which depends on autofs could fail if the NFS load isn't there.

You can't simultaneously have all of:
a) A compute environment dependent on storage X
b) High reliability
c) Storage X being unreliable

Pick any 2. :) For high reliability I'd make the storage redundant. In your kind of environment use a SAN not a simple NFS against raw storage.

Re:Process management in a consistent way

[jbolden]

E restarts due to the loop. The dependents either re-connect if well written or if not then they crash and get restarted. In such a case you'd want to insert a test for availability of dependencies in the loop.

They may not automatically restart or reconnect. They don't get notified E has restarted.

In the most extreme case, you could even do something like make runlevel 2 the default and have /etc/rc2.d/S99gothree run telinit 3. Should one of the production services fail, the server tramnsitions to runlevel 2, shutting down all of the production services, then transitions back to runlevel 3 to bring them all back up in order.

That won't work either. Remember F and D are communicating in this scenario. I think if we go enough rounds you will come up with a working solution. But what you would be doing is building the requirement for process management in the init system. Once you accept that process management needs to be in the init then init is out.

More broadly, there are any number of solutions to the problem that are far less intrusive on the rest of the system.

In theory, of course, in practice there aren't. Had OpenRC or Upstart worked we would have the Linux normal situation of a bunch of options with people choosing their favorite. Part of what is making systemd controversial is that the other two realistic options failed as projects so there is really only one choice.

Re:Process management in a consistent way

[jbolden]

respawn handles a process going down intentionally. It doesn't handle process crashing, locking up....

Re:Process management in a consistent way

[sjames]

They may not automatically restart or reconnect. They don't get notified E has restarted.

If they can't tell the services are down, then they must not depend on them.

That won't work either. Remember F and D are communicating in this scenario. I think if we go enough rounds you will come up with a working solution. But what you would be doing is building the requirement for process management in the init system. Once you accept that process management needs to be in the init then init is out.

If that can't work, then the machine could never have booted in the first place.

Given the large number of people who support one of OpenRC, upstart, or just keep what we have, there are plenty to choose from. The only reason there is any question of choice is that systemd is designed to be a glueball th stick it in place. Note that OpenRC is certainly not dead. Upstart is effectively abandoned at this point, but it's not like it no longer exists.

Re:Process management in a consistent way

[jbolden]

If that can't work, then the machine could never have booted in the first place.

Booting it tied to process management in init based systems. Init boots a bunch of different often overlapping and gappy process management solutions like the one you recommended (but larger). systemd replaces them.

OpenRC is kinda dead. Pity I actually like it. But AFACT the authors don't think they can keep up. They weren't able to even port most init scripts into OpenRC and out of init and thus OpenRC was mainly just doing the same stuff.

Re:Process management in a consistent way

[sjames]

Systemd replaces them poorly and incompletely at a huge cost.

I would rather see a neater more standardized framework for process control and dependency management if it is that important (how important can it be, millions of systems boot fine every day). Those can work as long as systemd doesn't munge it up by getting in the way (for example, by deciding that /sys/fs/cgroup belongs to it exclusively the way they are trying to steer things). Imagine, if I want to mount cgroups with the new unified hierarchy, systemd won't even try to boot the system. It's a good thing sysvinit is there!

Re:Process management in a consistent way

[jbolden]

(how important can it be, millions of systems boot fine every day

Well sure. Right now we have external process management. It is being used. Remember Linux has decided to replace big iron Unixes. Which means it is taking over more complex and intricate workloads.

As far as boot fine everyday on desktop they don't boot fine everyday. There are still quite a few problems in getting Linux desktops to "boot right". Decades after doing things like automatically detecting a new CD has been inserted and responding appropriately(code, mp3 music, music CD) is still a messy hack without systemd.

I would rather see a neater more standardized framework for process control and dependency management

What other teams are willing to implement this framework? This gets back to the whole problem that the other init system projects died. If there were multiple init systems then a separate framework between them might make sense. But otherwise systemd's startup files create a framework for the next generation the same way that systemd has to work the basics of init scripts.

Imagine, if I want to mount cgroups with the new unified hierarchy, systemd won't even try to boot the system.

That's true, they are incompatible. Now that cgroups is being rewritten to offer a better framework I'd expect systemd to trail behind implementing those features as options. Systemd can give back some degree of functionality and layer on top of the more modern cgroups framework as it emerges. But right now, yes it is an either / or choice.

Re:Process management in a consistent way

[sjames]

Funny thing, my Linux desktops boot right every time. My laptop boots right every time. My embedded linux systems boot right every time (and they better, I can't exactly plug a crash cart in if they don't come up). My Linux servers come up fine every time. The only reason they don't do it every day is that I don't boot them every day. Where are these systems that won't boot?

The problem with systemd is that it refuses to be a framework, it wants to be all or nothing. Had they designed a framework and the system that uses that framework (think gtk and gimp), both could have been something. Do you thing gtk could ever have become the popular GUI toolkit that it is if it had a dependency on gimp?

I don't expect systemd to magically understand a new cgroups API, but I do expect it to get out of the way long enough to develop something that can handle the necessary API change. It's a good thing sysvinit exists because systemd won't even give you the opportunity to mount the new cgroup fs. Being able to at least boot a test system helps a great deal.

But as far as that goes, the systemd project wants to push cgroups to allowing only one process in the system to work with it. Imagine that, they nominate systemd for that role. They speak of it as if it is fait accompli. There are good reasons to re-do the API, but none to make systemd the only writer. Looking at the latest kernel, it looks like cgroup is instead moving to provide greater ability to independently manage subgroups (as it should be)

But just to be quite clear, I only support staying with sysvinit for now. It is currently adequate and won't get in the way of an appropriate framework.

Re:Process management in a consistent way

[jbolden]

My laptop boots right every time.

I used to be able to say that. My 2012 rMBP doesn't boot at all with most distributions and when I can get it to boot all sorts of software doesn't work. Mind you this one of the most popular x86 laptops around. But more importantly power management didn't work well ever.

The problem with systemd is that it refuses to be a framework, it wants to be all or nothing.

Yes. Systemd wants to be the plumbing for Linux userspace. Essentially a second kernel offering a large range of services to those distributions that adopt it. So I'd agree it is meant to be all or northing. Which is why there are going to be Linux distributions that likely reject it.

Do you thing gtk could ever have become the popular GUI toolkit that it is if it had a dependency on gimp?

Yes. GTK become popular as part of Gnome and then lots of secondary applications. If GIMP had been tightly integrated into GTK it would have been tightly integrated into Gnome and image manipulation would have been an easy out of the box functionality that all apps had. So for example: screen shot manipulation would have been built into Gnome, likely cut and paste images from video playback built in, word processors would have had sophisticated image controls... Those are the sorts of features that got my wife to use Mac. I'm not seeing the downside.

I don't expect systemd to magically understand a new cgroups API, but I do expect it to get out of the way long enough to develop something that can handle the necessary API change.

That something is going to be systemd. The assumption of systemd is you aren't going to use those features directly. Now obviously if you are going to use them directly you aren't using systemd. Like you said, all or nothing.

They speak of it as if it is fait accompli.

It sorta is. The major distributions have switched. The competitors can't keep up. Obviously things could change but today there is nothing on the horizon I see that's close. Which doesn't mean other things won't be an option but mainstream distributions are going to be systemd.

I only support staying with sysvinit for now. It is currently adequate and won't get in the way of an appropriate framework.

The closest thing to that is OpenRC. The question is whether enough people are going to throw resources at OpenRC to help it keep up. Right now the answer seems to be no. This isn't really an idealogical question it is fundamentally a financial / time one. Will the anti-systemd crowd to the hard work to create the sort of alternative they want? So far I don't see it.

Re:Process management in a consistent way

[sjames]

I used to be able to say that. My 2012 rMBP doesn't boot at all with most distributions and when I can get it to boot all sorts of software doesn't work. Mind you this one of the most popular x86 laptops around. But more importantly power management didn't work well ever.

An Apple product meant for OSX doesn't work perfectly with linux? What makes you think systemd will fix it?

If you think your laptop is challenged now, I can only imagine how fast it would crap out if GTK required gimp (note, GTK = Gimp Tool Kit, Gnome came later) I can just see it now, you wait for half an hour while a paintbrush renders the desktop by painting it with a brush. Cool demo, crappy GUI.

Systemd and free desktop need to just go off and finish their Windows 8 clone and leave the Linux community.

Re:Process management in a consistent way

[jbolden]

An Apple product meant for OSX doesn't work perfectly with linux?

Linux used to work well on OSX laptops. The one previous to this and the one before that ran just about any distribution fine. Before that there was Yellow Dog which was specifically designed for Apple products, RedHat's PPC distribution, Gentoo PPC (surprisingly good) ... Things have gotten worse. The point was you were claiming that power management wasn't a problem. That everything was fine I was saying that I happen to be using one of the most common x86 products possible and its very far from power management working.

As for how is systemd likely to fix this. It isn't. But if the other problems were to be fixed it is likely to fix power management.

If you think your laptop is challenged now, I can only imagine how fast it would crap out if GTK required gimp (note, GTK = Gimp Tool Kit, Gnome came later) I can just see it now, you wait for half an hour while a paintbrush renders the desktop by painting it with a brush.

That's just silly.

Re:Process management in a consistent way

[sjames]

So why were you so happy to have gtk depend on gimp? It is both silly and counterproductive.

But it seems you found sysvinit's power management (or should I say it's non-management, it just passes the events along to something that's good at it) to be acceptable at least. And it sounds like the older, simpler distros worlked better than the ones with dbus and gnome and such with consolekit and policykit. One like I am advocating, in fact (though I don't mind console and policy kit so much, they stay out of my way).

Consider, what will you do if systemd makes a bigger hash of it on your preferred hardware? Go back to the older stuff that worked, of course. But for some reason you can't get the GUI desktop to come up any more. I guess it depended on systemd which fails miserably on your laptop.

Re:Process management in a consistent way

[jbolden]

Consider, what will you do if systemd makes a bigger hash of it on your preferred hardware? Go back to the older stuff that worked, of course. But for some reason you can't get the GUI desktop to come up any more. I guess it depended on systemd which fails miserably on your laptop.

I don't see why systemd would make a hash of my hardware rather than be better. What I would do is use a distribution that didn't depend on systemd. Linux is a diverse ecosystem of software. Or if that didn't work, pick between Linux and the hardware. Like I said I currently have hardware Linux doesn't work on. I'm not blaming initd for that. But the power management problems I and everyone has had before well yeah that was initd's fault. Initd didn't offer enough services to do power management well easily. Windows did a great job because of the how deeply embedded powerstate was in Windows. Integration helped. OSX BTW lagged for similar reasons though with they have in the last few years pulled way ahead of Windows.

And it sounds like the older, simpler distros worlked better than the ones with dbus and gnome and such with consolekit and policykit.

No that's not the issue. I suspect if I were still using the older hardware the more complex distributions would boot. It is the more complex hardware (EFI, dual GPU, complex resolution and sizing, lots of inputs on trackpad...) that is throwing the the newer distributions. The Linux community used to work hard on getting all x86 hardware to work. There is a push away from desktop Linux and one of the falloffs is that Linux just isn't working as hard on hassle free installs.

So why were you so happy to have gtk depend on gimp? It is both silly and counterproductive.

Because that's not the form it would take. The form it would take would be is what I described gtk depending on gimp libraries. Which would mean that all gtk applications would get a rich collection of routines from gimp that could be easily integrated into gtk applications. Which is very similar to what does exist with Cocoa and the Quartz graphical libraries. Having the widget set have additional features is a good thing about Cocoa not a bad thing.

Re:Process management in a consistent way

[sjames]

You DO realizew that gtk is a set of gimp libraries, yes? You know Gimp is a photoshop like app, yes? Would you care to have photoshop load every time yuou use notepad?

Do you really need image editing capabilities in mtr?

Re:Process management in a consistent way

[jbolden]

You DO realizew that gtk is a set of gimp libraries, yes? You know Gimp is a photoshop like app, yes? Would you care to have photoshop load every time yuou use notepad?

No of course I wouldn't want the app to load. But I would want gtk to have features from Gimp so that other applications can use chunks of Gimp code to accomplish different tasks. This is the way Cocoa works. For example webkit is used by a 1/2 dozen applications on OSX and iOS to accomplish web features even if you aren't using Safari.

Re:Process management in a consistent way

[sjames]

I'm guessing you aren't a developer. If an individual app wants te capabilities, it can link against the library directly. It is rather ugly to link it in at a low level such as the widget toolkit.

Why, for example would it be a good idea for the date time display widget at the top of the screen to have a built-in spreadsheet, web browser, photo editor, mp3 player, and minesweeper?

Re:Rules for posting?

[CaptainDork]

Bennett provides a service.

Mosquitoes provide a service.

systemd provides a service.

Let it be.

As a recent Arch convert...

[Enahs]

As a recent Arch convert--or more to the point, someone who's trying it for a second time--my boot time is ridiculously fast. Since it's a desktop, if it's going to be powered down overnight, I go ahead and shut it down, so boot time matters. It takes longer to log in and wait for GNOME to start up than it does to get to GDM. Also, setup was (imho) much easier than it was when I tried out Arch a couple of years ago.

I get many of the reasons why people don't like it, but imho the pros outweigh the cons.

Mixed feelings

[Mostly a lurker]

Sometimes, availability really is critical. In that case I want to take the risk of an automatic restart before the cause is investigated. However, it is important to appreciate that the approach is risky . The restart can cause cascading errors that change a reasonably simple issue into a multi day recovery operation.

Re:Mixed feelings

[Aighearach]

In a modern "cloud" setup restart might not be risky at all because you might be discarding that node and instantiating a new one, and investigating the log on the log server.

Also, if a service can't be safely restarted, my advice, use the best mainstream open source server software available and this should not be an issue. This is not the 90s anymore, computers are still not reliable but mainstream software software is pretty good. For custom software, those are bugs I want to hit; I need to fix those. If restarting is dangerous, I've got a totally broken application architecture and I should fix it before it causes further embarrassment.

Re:Mixed feelings

[SharpFang]

Someone gave a reasonable example before. Someone fuzzing your server to gain access.

If you keep restarting your server, they will eventually get in. And then they can cost you a multi-day recovery operation. Not system recovery; it will be a matter of restoring it from backups. But of legal recovery: stolen user data, undoing fraudulent transactions, recompensing users for lost assets, damage control in the PR department... the system damage will be the least of your worries.

On demand startup of services at the socket level

[jbolden]

systemd is able to have server sockets and listen to them creating the underlying process on an as needed basis. One of the reasons the Unix shell was so successful was because there were all these little utility programs around that could be easily patched together via. scripting. This made simple applications really really easy in Unix. What systemd does is allows the creation of something like this for application services. You could have hundreds of thousands of socket services being offered by a collection of applications always available but not consuming resources until needed. Which allows applications to mainly consist of just pasting together services from other applications in unique ways.

To do this though the system has to be doing more than just simple initiating services during boot it needs to talk on other roles. This is one of the reasons that systemd is designed for process initiation all the time.

Re:Nice Thing: systemctl status shows you log entr

[ledow]

No, that's not what I mean. You've removed the new "useful" features that I'm okay with - and might want - but in doing so you've told me to replace everything I have with systemd.

Much more useful to me would be to get that listing, with those log tails, on a sysVinit. And that is far from impossible.

What we have here is bundling issues. Want the nice feature that does something quite simple? Then change everything you have to our system.

That's systemd's problem (and your response is their attitude) in a nutshell.

Arch Reasoning

[Anonymous Coward]

There's a nice post over at the Arch forums that breaks it down.

Arch Reasoning

[JamieKitson]

There's a nice post over at the Arch forums that breaks it down.

Re:Nice Thing: systemctl status shows you log entr

[ledow]

Correct me if I'm wrong but the cgroups features that allow this, without rewriting services, have nothing to do with systemd at all.

This is exactly my point. It's a fancy logging feature. We have fancy logging systems. But, no, apparently we HAVE to use systemd to get this completely unrelated "feature".

I wouldn't use it often enough to justify the development time. But even I can run the above through my head and come up with a way to do it using the existing systems.

Re: As long as it works

[Forgefather]

That's all well and good, but if Linux developers say that they want to take the desktop then they will need to come to terms with the fact that users don't care about anything other than usability.

server is not a server

[superwiz]

Most modern "computers" are not metal. Heck I usually run 5-6 instances of different virtual machines just at home. And that's at home. At work, it goes up to 15-20 at any one time. Any server needs to be designed to go up and down as quickly as possible and to have 1 instance of it running as transparently as 100 instances. Long start up times and monolithic servers whose start up can be observed by a human being are the thing of the 1990's. The world has moved on. Most cell phones today are more powerful computers than any server built in 2001. Quick spinning up of multiple instances of virtual servers is a requirement in today's world -- not a "nice thing to have."

Re:What system d really is

[suy]

Most distros are focusing on system d because they simply do not have the resources to do anything else. This is the sad reality. The Red Hat-isation of the linux world. It's either the Red Hat way or the highway. And most distros obviously are not chosing the highway.

Odd that of all possible choices, systemd developers chose almost always a way that is exactly the same or very similar to what Debian does. For example, I don't see stuff like /etc/sysconfig, while I do see things like /etc/hostname etc.

Try before you buy it

[jcfigueiredo]

Well, I have the same questions and been overwhelmed by the same amount of uninformative threads spawning every day so what I did is install one system with systemd in production on non critical system. My experience has been a good one so far and the systemd designs decisions (which people have been complaining a lot about) have not impacted my life as it's user. Another thing to consider, and most haters/fanboys forget, is that it might be the right/wrong option for YOU on YOUR context and it just might not be for another person or on another context.

Re:Thanks for making my point

[gatkinso]

I worked on space rated instruments at NASA Goddard for a while, and talked to a very old dude who claims to have seen this happen once in his very long career.

Keep it simple, stupid

[StripedCow]

I think systemd has too much functionality and should be broken into smaller modules.
That's the nicest thing I can say.

Re:VERY POSITIVE: Systemd is well-modularized

[Barsteward]

"Modularity not only implies duplication of code, it requires it." - can you explain that in a bit more detail ?

opposition to systemd keeps linux hard to use

[Eravnrekaree]

There are features in systemd that conceptually make sense, such as being able to tie the starting of a program to a system event, such as the insertion of a USB device or a file event, or any other system event, including the starting of another program. The concept and the implementation are two things, the concept can be good but the implementation may not be. It may also be that while the included concepts are a good base, they would benefit from additional refinement. The implementation in systemd may need some improvement, some more features and customizability ought to be added, but the general concepts are sound.

My view on systemd is that for most users it is fine and suitable. People who don't want it can configure systemd to start up a traditional BSD type script from which they can start their daemons, at which point that the presence of systemd would be imperceptible. Given that its high powered system administrators who want a traditional init model are knowledgeable enough to take an off the shelf distro with systemd and modify the system to their own liking, they really dont have any excuse as to why they cannot configure systemd to start their own init script and use that to start their daemons rather than directly from systemd.

Its probably even possible for these sysadmins to replace the /bin/init program with their own init program, whatever they want that to be. If they don't like systemd, being such experts, why don't they just configure their own systems not to use it?

So this whole uproar about systemd is NOT about whats best for or what common users want, what its really about is a few sysadmins forcing their own way on everyone else, and actually about making Linux difficult to use for common users. This elite group regularly opposes anything that would make Linux more useable for common people. Its as if they actually want to make sure that open source software never really becomes something that is common and ubiqitious by making the learning curve for Linux so steep that it keeps people on Windows. Many of these sysadmins actually do not want common users to use Linux or for Linux to be a desktop OS, they consider to be Linux an elite club and that Linux should be almost impossible to use without a degree in computer science, because it gives them a feeling of elitism to be able to use an OS that is almost impossible to use.

Re:opposition to systemd keeps linux hard to use

[serviscope_minor]

So, the nicest thing you can say about systemd is an ad-homenim attack on people who don't like it?

And I wonder why systemd threads end in massive flame fests.

Re:opposition to systemd keeps linux hard to use

[Eravnrekaree]

Did you ignore the first paragraph? I mentioned many positive attributes about systemd. There are capabilities there that would allow for much greater capability than before, such as if we wanted to start a program on of many system events, such as a filesystem event.

Re:opposition to systemd keeps linux hard to use

[walterbyrd]

> So this whole uproar about systemd is NOT about whats best for or what common users want, what its really about is a few sysadmins forcing their own way on everyone else, and actually about making Linux difficult to use for common users.

I think you have that backwards. A few sysadmins do have the power to force any radical change like systemd. Only a company, like Red Hat, has that kind of power.

Let me fix your statement for you: so this whole uproar about systemd is NOT about whats best for or what common users want, what its really about is a few developers at Red Hat forcing their own way on everyone else, and actually about making Linux difficult to use for common users.

Re:opposition to systemd keeps linux hard to use

[serviscope_minor]

Did you ignore the first paragraph?

Yep, but I fooled around with hotplug a while back. Bsically it resulted in a shell script being called. So you could execute arbitrary code on a hotplug event. Sure it might be nicer in systemd, but doing it at all (what you mentioned) was certainly -possible- before.

So since what you wrote was not actually an advantage of systemd the way you said it, I decided to ignore it.

That left a massive blob of ad-homenim attack on people who don't like systemd because they hate normal users and want linux to be hard so they can be super elite or some other bullshit.

In other words the mythical RTFM n00b linux neckbeard. I've been "in the community" for over 15 years and I don't think I've ever actually seen one in the wild.

No sane person wants Linux to be hard to use. And I doubt you can actually find any instance of anyone anywhere advocating sysvinit because it's harder than systemd and therefore better.

I think you're massively biased to the point of being bigoted against people who you simply do not understand. Your lack of understanding leads to hostility.

As I said, no sane person wants to have a system that is hard to use. People like me certainly don't count as "normal users". A system that is easy for me to use is one that is transparent and malleable. Any system that does to much "automagically" is harder for me to use because it is harder for me to bend it to my will. Changing the behaviour involves chasing down all sorts of levels of automatic systems to find who processes what. For example, for the first time in 10 years under systemd I can no longer get the power button to function properly under FVWM.

It so happens that that is the polar opposite of what "normal users" want where they would rather have a system that does as much automatically as possible. To them my system is hard to use. To me, their system is hard to use.

See, none of that involves me hating normal users, nor does it involve me feeling superior or wanting to squeeze them out in order to feel elite. It just involves me wanting to get my laptop up and running with the tools I like using working the way they worked before.

But according to YOU, I'm some RTFM n00b user hating neckbeard who uses linux only to feel superior to the smelly unwashed and despicable masses, and all because I don't like systemd. The fact that no one I asked on a variety of fora could tell me which component was supposed to deal with the power button and other ACPI events and how to override the default action has *nothing* to do with it. It's all because I hate users.

something nice?

[slashmydots]

Something nice about it....okay, Windows 8.1 didn't implement it :-P

It's not Bennett Haselton

[MagicM]

I love systemd because it doesn't continuously spout inane drivel to my favorite news aggregator. When systemd has something to say, it does so in its own log separate file which I can read at my leisure (or ignore completely if I so choose). As far as I'm concerned, systemd is the model that should be followed by everyone.

Journalctl logging is more secure (bug #1098132)

[Anonymous Coward]

Caveat: I am a server admin.

With systemd, one can't even remotely log a journal natively, which is par for the course in many server environments. You can't make this stuff up, please see bug #1098132 (https://bugzilla.redhat.com/show_bug.cgi?id=1098132) At the time I'm writing this, that functionality still just *doesn't exist* in systemd/journalctl. It was almost pushed into the last revision, but the bugs were show-stoppers so was pulled. Even if it does go into the next systemd revision, how long until it's really kosher for solid/production environments? 1 year? Two? Three? Yet it's being pushed as the default *now*.

To explain why this is important: if someone cracks in, the log files are going to be one of the first things they muck with. You have locked down syslog/et al, so you can tell if they muck with the binaries, but the log files themselves are considered compromised. Logging remotely at the same time before the data even hits the disk creates another layer of safety, which you simply can't do with systemd/journalctl. One day you will, assuming you want the binary journal and journalctl, but even if you wanted those now you couldn't. Yes, you could rsync over a copy of the files, but there's a reason why people aren't just doing that for regular logs and this is going long.

Over the last decades, people have worked out tried-and-true systems for documenting and verifying logging. So from an audit perspective, with journalctl you can't lock down syslog-ng and that process, because you've introduced an untrustworthy one above it. They know the current strengths and limitations -- to the point that there are legal/liability issues involved for many if their logging goes wonky. Journalctl adds a layer between the systems they have that work (and even have protocols in place for in terms of auditing), and as of right now adds a *wonky* layer that's very buggy. And by buggy I mean prone to corruption and simply not doing as its told.

Here's the real kicker: most of this issue would go away if systemd was willing to allow the user to not use journalctl and let things like syslog-ng have that data in the raw. It is choosing not to allow that as a tactic, as opposed to what the users and tech itself wants, and so here we are.

Also, this entire proposition by samzenpus is inane. When one thinks backwards from what the motivations might be, none of them are good and make me lose that much more respect for the site.

Systemd is for DevOps

[Anonymous Coward]

I haven't had a chance to use systemd, but reading the docs and blogs describing its goals, it seems like systemd is meant to make DevOps easier. Currently, most devs that end up doing sysadmin tasks end up using VMs along with containers. Deployments are automated by using some sort of service watcher like supervisord that has a declarative API for adding/removing services programmatically. These watcher processes act as a user level init system that babysits processes, helps configure logging, makes writing a "daemon" easier (no double forking, etc.) and pretty much does the stuff that systemd is doing.

Someone might be asking if we already have monitoring processes that takes care of this stuff, then why do we need systemd?

As systemd is getting adopted by distros, it means someone can write tools that depend on systemd and you can get the complex process management build directly in the OS.

I realize that this stuff is all possible with the current init systems, but systemd makes it a lot simpler. No more writing code that daemonizes manually only to turn it off to support some process management tool. No more custom RPC to communicate with to add and remove processes when scaling. No need to support multiple process management tools with radically different APIs and features.

I'm sure systemd will have its issues, but the ideas and improvements seem worth it in the long run.

Well...

[frank_adrian314159]

If you want a debate, maybe make the rules a bit shorter? In other words, TL;DR - and that's just the summary.

Most of us don't really care that much, you know.

Re:Nice Thing: systemctl status shows you log entr

[db48x]

cgroups just enable systemd to collect all of the log entries from all of the processes belonging to a service without missing any*. When a sysvinit service daemonizes itself, the pid of the daemon isn't the same as the pid of the process that init actually created. This means that every service has to keep track of its own pid (in a pidfile), and that every service would have to report this information to syslog somehow.

Or you could add this capability to init, but then your new init is no longer doing just one thing and this is exactly the complaint most people have about systemd. Also, be careful not to change the existing interface with syslog, because then you're imposing your own views on everyone else, just like folks are saying about systemd.

Oh, and if your service logs to syslog, and it's being run under systemd, then systemd intercepts those and attaches all of the extra metadata before adding the log entry to the journal. You don't need to rewrite anything to be compatible with systemd. In fact, if you also have syslog installed then systemd will automatically send everything that gets logged to syslog as well; you get both at the same time and neither steps on the other.

I don't like systemd because it is systemd, I like it because it gives me a great way to query my logs and find out what my systems have been up to. If you give a sysvinit system the same capabilities then I will use those capabilities just as often.

* Well, cgroups also let systemd do a few other things not related to logging, such as setting resource limits on individual services, but I don't use them much myself.

Its going to make 2015 ...

[PPH]

... the year of BSD on the desktop!

Re: Thanks for making my point

[PhuCknuT]

Who said it had to be quietly?

Thanks

[waspleg]

it was an interesting read.

Re: systemd is evidence...

[tlambert]

If it was an OS X knock off then why aren't the distro's using launchd. Serious question - launchd is fine.

Something to to with the number of Mach messages a second Linux doesn't do...

Seriously, launchd suffers from the same constraint/soft dependency problem that systemd has. It's possible to deal with it by providing imperitive rules, but getting the races out when trying to express them as constraints is ... difficult. Perhaps if there were tools that were capable of doing that for you, but if you've ever build something with a circular set of package dependencies on Ubuntu, you know that such tools require making your graph through multiple dependent build files acyclic; it's an NP-hard problem to solve.

Re:What system d really is

[marcello_dl]

Except that a handful of devs ditched systemd for runit and have a 4000 package distro called voidlinux and it seems to hold pretty well.

Why can't others do the same?

compact syntax for the common things

[himdel]

I feel about systemd pretty much as you do, but there is one obvious advantage: the unit files for the most common things are very readable and quite obvious, without the boilerplate. I currently wouldn't want to do anything more complex with sytemd but for a basic daemon that just has to be started (as user x, after service y), it's actually *very* easy to read and write a unit file.

Now, if we could only add #!/usr/bin/systemd-unit-run to them and run them under sysvinit... :)

The first rule of systemd is:

[tlambert]

The first rule of systemd is: You do not talk about systemd. The second rule of systemd is: You do not talk about systemd. Third rule of systemd: Someone yells stop, goes limp, Godwins out, the discussion is over. Fourth rule: only two guys to a systemd conversation.

init freakin' works fine - so why bother?

[walterbyrd]

> I'm still really confused about the jihad-level hatred it seems to engender in some people.

I believe that hatred has been well explained, why the confusion?

Just because something "works fine" for you is hardly justification for such a radical change.

SYSTEMD IS THE NEW SCO OF LINUX!!!

[Anonymous Coward]

Ok, the crap systemd really hosed me on boot up. I wants to start up a GUI before it will run on Virtual Consoles. The gui is frozen, and Alt-F1, F2, F3, F4 are not functioning. What can one do. HARD - Reboot, corrupting the file system. Never had that with initd. So who ever wrote this abomination called systemd (The biggest scourge linux has be hit with. Why ... it's worst than SCO. )

In fact, systemd is the new SCO of linux!

systemd knows if somebody tampered with logs

[moo9000]

I found this when I was researching "OMG!#! systemd even includes QR code library." Why would they do that? They are smart guys after all, they don't do things without purpose. Then I found this gem. It is actually used to ensure the system is intact and no one has tampered with logs, etc:

http://www.h-online.com/open/n...

It's called Forward Secure Sealing: http://lwn.net/Articles/512895...

Another small gem is "Why, oh why, they created NTP clone?" There is a very good rationale for that, like having coherent timestamps on embedded device boot:

https://wiki.archlinux.org/ind...

Naturally these are optional, and not forced upon you.

Re:What system d really is

[psmears]

Development of Linux kernel is not done by consensus. It is done by 2-3 important firms the likes of Red Hat/IBM/Oracle and the rest/scraps are left for the open source community. [...] Apt-get was an exception, it is not a kernel project.

Note: systemd is not part of the Linux kernel.

Re:What system d really is

[walterbyrd]

The community is not forming around systemd. Systemd is being rammed down our throats by one company.

As long as it works for Red Hat . . .

[walterbyrd]

You have no concerns about the long term effects of Red Hat's hostile take over of Linux?

We may be seeing that last days of Linux as a free OS.

Soon enough, the only Linux that will be able to get upgrades will be Red Hat.

Re:As long as it works for Red Hat . . .

[tibit]

If you're a business, nothing is free. You have to spend the money, the question is how much do you spend and who are the checks written to. From the perspective of my business, not having free Linux is fairly immaterial, as the costs of supporting it and the multitude of applications we run on it far outstrip the cost of the OS. It really helps that we don't run it on big iron, but on plain old x86 hardware :)

Re:As long as it works for Red Hat . . .

[walterbyrd]

> From the perspective of my business

Speak for yourself then. I think most Linux users want Linux to be honestly open, and free. Most Linux users do not want Linux to be another Windows, or Solaris.

> not having free Linux is fairly immaterial, as the costs of supporting it and the multitude of applications we run on it far outstrip the cost of the OS.

Why not run AIX, or Solaris? Linux is for people who want free - there are many alternatives for people who prefer the proprietary model.

Re:As long as it works for Red Hat . . .

[tibit]

Because it costs way more than a basic license of RHEL, and I don't care for either one of them. Yeah, ZFS would be nice. Whatever.

Re:Nice Thing: systemctl status shows you log entr

[Wheely]

I just need to get this clear what you are saying.

Are you saying that a "daemonized" process needs to keep track of what pid it had itself and that it has to keep it in a pidfile? I just wondered because nothing ever, ever, ever needs a pidfile especially as any service can get its own pid by going "getpid()"

And then you are saying that one advantage of systemd is that you get the pid in syslog and perhaps some other data about the process itself. I had never thought of that. I mean I never thought when I read something like "can not write to /oracle; device full" that having the pid of the process and that it was owned by oracle would be particularly useful.

Maybe it is sometimes for some people. Seems a terrible upheaval for a very small gain.

bleh, systemd

[Anonymous Coward]

What I hate about systemd?

- Violation of KISS. Especially an init system needs to be as simple as possible, without anything but the most important deps

- Violation of "do one thing only, but do it right". I don't welcome this new kraken overlord.

- Binary logging. Yes, you can force it into the old logs, but try to recover something from a crashed log. Oh, you don't need to because Lennart says that you should just delete the logs. What a retarded solution is that?

- Do everything. The more you stuff into systemd, the more chances there are that something will fail and crash the whole system. Not pretty.

- QRCode and a webserver are important deps of an init system? WTF is wrong with these developers?

- Fast boot time arguments. Might be nice for a desktop, but we all know how many are desktops, and how many are servers. I don't reboot my servers on a daily basis and can live with a few more seconds.

- Lennart and Kay. Those two have a bad history as developers. Even Linus got angry at Kay because he refuses to fix bugs he caused. There's a discussion where they argue that the kernel cannot expect to own its own kernel line parameters (!). That's in a response to a bug where systemd causes kernel panics with debug garbage because it just takes over ever option.

I don't mind a new _clean_ init system. But I hate the idea of "my linux in your linux" solution from Lennart. If he wants his own distro, he should just fork an existing one and see how well his "great idea" does without the pushing power of Redhat.

Re:bleh, systemd

[SuiteSisterMary]

The Linux kernel itself violates 1,2,4 and probably 6 of your arguments. If it was designed according to those tenants, it would be a microkernel.

Compliment: Clear and specific rules of discourse

[DutchUncle]

Were you on the debate team? :-)

Re:Any relation to Systeme D -- the restaurant ter

[Geste]

Note: Not a term restricted to or owned by the restaurant culture.

Re:Thanks for making my point

[psmears]

Many hardware failures are transient, and a process restart is a very effective fix, at least in the short term

Not to mention crashes caused by rare, hard-to-reproduce race conditions. These do happen (correct multi-threaded programming is hard), and personally I'd prefer it if the process crash didn't take down my websites with it - though of course I do want the logs to let me know, loud and clear! Sure, if the service crashes repeatedly on restart, it needs to be throttled, but I assume systemd can do that (after all, this is one of the things SysV init has always done, at least for getty processes).

Re:Bud Light?

[Culture20]

as informative as an old Bud Light commercial

Pretty sure the 'less filling/tastes great" thing was Miller Lite

Whichever it was, it wasn't a "this is bad/this is good" type argument. And it was both informative and educational. To this day, we all remember that whatever beer this was, it tasted great and was less filling, even if it was neither.

Re:Thanks for making my point

[Anonymous Coward]

Oh, cosmic rays again. We had those in the server room once, crashed our HP9000 system a couple of times. Funny thing is, the server room is in a concrete basement underneath the main building, where radiation would find it very hard to get in, and the server case was metal.

After a couple of crashes, the kernel bug causing these "cosmic rays" was found, and after the update, the problem stopped.

downgrade.

[zebedi]

i'm a small time admin, running about 100+ wireless nodes for artisans, private and commercial users. the -majority- of users running debian on desktops (autopilot upgrades rolled out), the rest are smartphones etc. windows is -actively- banned from the network. all routers, servers, firewalls are running debian, handrolled with lenny, wheezy and jessie, but all configs by the book, and audited by an experienced 2nd set of eyes. i'm 35 years in computing, telecoms and electronics. systemd is the worst single time-waster event in my professional career. although not yet enabled by default in jessie, it's causing a -lot- of disruption with basics like remote rebooting becoming an economical hazard (petrol costs), remote desktops not cranking up, auto logins not working (previously reliable packages like gdm3 break on upgrade due to forced dependencies to systemd related packages), endless hangs on startup/shutdown, many users complain about slow shutdowns, or machines not shutting down at all, services not starting. and yes: i understand how the beast works, and i can see the beast is doomed. the logging is a ---fucking--- nightmare, works fine on paper, but is making it impossible to get basic stuff done when in the real world things break, and taking the unreadable logs with it into the ether. i'm yet to see a machine that actually booted faster, or indeed shut down faster. agressive parallelization seems to apply ony for a subset of computing equipment i'm unfamiliar with. i can already hear the smart arse comments from corporate armchair admins: 'do this, do that ...' but the reality is that the problems caused by the yet flaky systemd is creating such an extra workload that is buries any hope of getting to grips with it. driving to each customer and wipe the systems fucked by systemd and re-install them with wheezy or carefully pruned jessie is cheaper, and we can all have our lives back. i never thought i'll be wading through backported software again ... for regular user systemd brings no obvious advantages, at least not for their ancient harddrives on single core desktops - but instead a few ended up with trashed installs, e.g. by old non-critical errors being dragged into an upgrade and then breaking on (remote) reboot. if i hadn't left the core machinery on lenny and wheezy i'd be in deep shit now, and likely going out of business. stefan zalewski, burren.org

Re:downgrade.

[buchanmilne]

although not yet enabled by default in jessie, it's causing a -lot- of disruption with basics like remote rebooting becoming an economical hazard (petrol costs), remote desktops not cranking up, auto logins not working (previously reliable packages like gdm3 break on upgrade due to forced dependencies to systemd related packages), endless hangs on startup/shutdown, many users complain about slow shutdowns, or machines not shutting down at all, services not starting.

Upgrades of other distributions from pre-systemd to partial systemd (e.g. systemd-sysvinit) to full systemd (units for all services) have worked fine for me. My personal machines (2 desktops, one xbmc box, one home server/NAS/virtualisation host, multiple VMs) that have been running with systemd for more than a year have no issues like this.

Maybe your problems are more due to Debian (testing) and less due to systemd.

That said, there are some problems reported with network filesystems mounted from /etc/fstab, my boxes are running autofs for network mounts which may be why I haven't seen any of those issues.

Thanks

[waspleg]

Also a good read, like the uselessd dev post linked before it.

Re:Nice Thing: systemctl status shows you log entr

[Eunuchswear]

Much more useful to me would be to get that listing, with those log tails, on a sysVinit. And that is far from impossible.

So do it already.

Systemd Does Not Cause Ebola

[Anonymous Coward]

To date, there is no evidence that systemd causes ebola.

Parallel booting

[brunes69]

The reason systemd came to being and the only thing anyone who uses it ACTUALLY cares about is boot times. Period.

systemd allows proper dependency management, and therefore parallel booting and thus faster boot. When you are talking about consumer grade systems, this is important. When you are talking about servers, it isn't.

That's the long and the short of it as far as I am concerned. There is a lot of other "this and that" technical pros and cons around systemd, but the MAIN REASON it has ever been pushed is proper dependency management which can enable a parallel boot process. If you don't care about this due to your application is some long-running server, that's fine, but to pretend NO ONE should care about it is just stupid.

Re:Parallel booting

[Narcocide]

But Debian's existing sysv-style init in wheezy already does that without needing to be swapped out for systemd. How could it have escaped everyone's notice that systemd's primary justification isn't even new functionality?

Re:Parallel booting

[AdamWill]

That's far too reductionist. For a start, there are many sysv-compatible init implementations that do parallel boot; upstart does it, Mandriva's pinit does it. There's a whole subset of LSB that exists exclusively to provide a way for sysv initscripts to represent dependencies *precisely in order to enable parallel init* - see https://wiki.debian.org/LSBIni... for a good write-up of that.

Secondly, insofar as systemd is intended to improve boot speeds, it wasn't actually just about implementing simple parallelization of sysv-style services using dependencies. If you read http://0pointer.de/blog/projec... it talks a lot about parallelization but it's actually talking about making *more* parallelization possible, not just *implementing* parallelization: the big idea Lennart had back then was the idea that you don't actually have to completely start up a service in order to start up another service that 'requires' it, if you can create the socket it listens on before it's ready, then queue up any requests and pass them on to the service once it's actually done starting up. Lennart was clearly really excited about this idea at the time, but if you look at systemd these days, it's a really pretty small corner of all the things it does.

All the way through the first part of that first post, Lennart is really talking about making more parallelization possible, he's not simply talking about implementing inter-service dependencies.

These days systemd does an awful lot more, and it really isn't just about making boot faster any more. Even in the very first post, once you get past the first half, it starts talking about improved capabilities. I find startup speed the least interesting thing about systemd, really, I'm much more interested in the improved capabilities for units and especially in the improved logging journald provides.

Re: Thanks for making my point

[swillden]

Also, not coincidentally, quietly allowing hardware problems to persist until data structures and the filesystem to be corrupted before anybody notices.

Hence the importance of monitoring so that the failure is not quiet, as I already pointed out. Please try reading and fully understanding posts before responding.

Re:Thanks for making my point

[Carewolf]

I worked on space rated instruments at NASA Goddard for a while, and talked to a very old dude who claims to have seen this happen once in his very long career.

It happens about 40 times a day on you average PC, it is just rare it hits anything vital. If you run ECC memory you can track how many read errors it corrects. In fact error-correcting memory exists for servers and workstations for this very purpose. It is real and common.

Say nice things?

[Khyber]

What the fuck? When did Slashdot become FARK?

Oh, yea, the second all those SJWs took over Slashdot.

Re:VERY POSITIVE: Systemd is well-modularized

[Theovon]

We're talking about low-level system services here, where it's not really necessary to have swap-out options. Ok, sure, we have nano and vim, less and more (which nowadays are just the same program), variations on cron, etc. But a any one time, we just need to pick ONE. Moreover, most of us don't care which cron was chosen, as long as it does the right things at the right time.

With systemd, there is CURRENTLY less choice in some cases, but probably for ones that don't matter. Most components are already optional, and sooner or later, there will be multiple choices for a given service. (The lack of that is due to the young age of the project.)

As for duplication, you're not getting it. In a good system, common functionality is bundled into shared object liibraries so that they can be dynamically linked into multiple programs that need the same capabilities. Those are mapped to the same physical memory pages, so it saves memory too. It's also good to avoid reinventing the wheel. How many different config file parsers do we really need?

Re: As long as it works

[kthreadd]

If the major distros all switch to Systemd, which looks likely; then that's one less thing that prevents people from switching to another distro. If you want to belive in some kind of conspiracy around Red Hat, then wouldn't they be more likely to just invent their own proprietary init system and make sure that no one else adopted it?

Re:VERY POSITIVE: Systemd is well-modularized

[Theovon]

Wow. The usual complaint is the myth that systemd is monolithic. It's not. But now you're complaining that it's broken up into too many services? And how is this any different from sysvinit, which also starts any number of different binaries?

All they've done in systemd is write C code to start up services that used to be started instead by shell scripts and added the ability to make dependency resolution automatic so that services are only started when they need to be. So basically, they made it smarter and faster. The complaint that it's got too many binaries is moronic and a complaint just as well against sysvinit.

Systemd is modularized into a number of different binaries, each of which handles a different service. Thus, different functions are isolated from each other. This enhances stability and improves startup performance when not all need to be running first thing at boot time.

Oh, and all of systemd's config files are written in ASCII, in the traditional UNIX way. One cool thing they've done is made a single parser implementation (in a shared object library) so that all of the config files have the same syntax. Also, when you debug a problem with parsing for one service, you automatically debug it for all others at the same time.

Re:Any relation to Systeme D -- the restaurant ter

[synaptik]

If so, the name choice was brilliant (regardless of whether the project itself is.) Thanks for the info.

Also: Wikipedia suggests that the 'D' in "Système D" can stand for "démerde" :)

Re:Hangtime

[thrig]

Incorrect, sir, I've RHEL6 systems with the traditional init that do sometimes randomly hang on NFS or tmp or lord knows what and need to be power-button-poked to get them to reboot, as requested. So, feature parity with systemd in that regard, if your claim is true. I have not yet moved anything to RHEL7, as there's been zero demand or need for it (Windows 8 on surface seems popular with the users; but hey there's always next year for Linux on the desktop, right?), and I think only earlier this week they fixed a local RHN satellite issue preventing access to necessary additional packages, plus there's that happy bundle of commercial CAD apps that would need to be got working on RHEL7, the typical sort of Augean shoveling the graduate student they probably aren't paying enough somehow isn't in a hurry to get neck deep into.

Re:What system d really is

[LordByronStyrofoam]

Slackware.

Re:Thanks for making my point

[swillden]

Not to mention crashes caused by rare, hard-to-reproduce race conditions.

Indeed. That is one sub-category of the obscure software defects I mentioned. It's probably the best example, actually.

It's interesting to describe the approach used by many systems at Google (where I work; I'm now in Android but used to work on Google servers): a common pattern at Google is to crash immediately upon detection of any error. This is actually just a logical extrapolation from Google's long-used approach of building reliable systems on top of cheap, unreliable, commodity hardware, applying the same notion to individual software components. System designs assume that anything can fail at any time, and are built to recover gracefully, possibly with some degradation. So there is extensive infrastructure to fail a request over to to another process instance, and to automatically restart any failed processes. And of course there is extensive and detailed monitoring, with lots of statistical analysis of failure modes plus charting of everything to enable patterns to be recognized and various forms of alerting, ranging from automated bug filings, to e-mails, to pages delivered to on-call engineers.

Given that approach to fault tolerance, it's often very reasonable, at least for non-Java processes, to simply abort/crash whenever anything goes wrong. Restarts are automated and fast (for non-Java processes; JVMs are a bit slower to start) and monitoring and alerting take care of letting people know what happened and how often. This includes both hardware and software-related failures. Monitoring also pays special attention to processes that fail repeatedly (called "flapping") upon restart and generates high-priority alerts. The restart infrastructure will also slow and even stop the restarts of flapping processes.

Anyone who's used the googletest unit test framework for C++ may have wondered about the extensive support for and documentation of so-called "death tests", which allow you to verify that your code crashes when it's supposed to, and in the right way. This is a consequence of this particular approach to fault tolerance; if crashing is part of your reliability plan, you need to test that your code crashes when and how it's supposed to.

None of this has anything to do with systemd, of course. The fact that a strategy is effective in Google's environment is utterly meaningless in single-server contexts. In this case, though, auto-restart plus monitoring and flapping control seems like something that could usefully work in many contexts, perhaps even as the default.

Re:CentOS 6.5 & Debian Wheezy

[walterbyrd]

I run CentOS 6.5 and CentOS 7. I like CentOS 6.5 far better: much better GUI, and no useless systemd. Also, 6.5 boots faster.

Re:My Mom told me

[walterbyrd]

Some people think honest criticism can be more useful than mindlessly praising everything Red Hat does.

moving common code from individual daemons

[himdel]

Another thing which IMHO systemd gets right (although it's definitely not the first to go this way, just the mainstreamest): daemons used to have to be able to damonize, log to syslog, setuid to a different user, etc. - a functionality implemented separately in each daemon (or included via libdaemon or similar). Now, a daemon is just a regular program, logging to stderr and the only thing it still needs to do is re-exec on sighup.

So let's just wait for all the deamons to remove the cruft and then we can switch to daemontools :).

Re:What system d really is

[ISayWeOnlyToBePolite]

Users are going for systemd and liking it https://qa.debian.org/popcon-g... Notice how the rush starts after gnome (in debian) drops the hard dependency on systemd, that's when systemd-shim appears, and how systemd-shim users are declining and also not voting for the package.

Re:Nice Thing: systemctl status shows you log entr

[psmears]

Not much harder than rewriting all the services to log to systemd instead of calling syslog(), except that now they're still compatible with non-Linux servers.

Except that this feature of systemd doesn'trequire any rewriting of services, at all. They just carry on sending output to stdout, stderr, and/or syslog, as they have always done - and the "cgroups" feature ensures the logs can be distinguished and stored appropriately. Doing the same consistently for SysV init would actually be genuinely harder, because (for example) when services are started manually this is done by running a service-specific shell script - so to ensure each service ends up in the right cgroup, you have to add a lot of Linux-specific stuff to each service's startup file.

I'm not yet 100% sold on whether the log filtering is worth all the extra code implementing it - but saying it's "not a big deal" to add the same feature to sysvinit is not telling the whole story.

Socket Activation/Passing

[Wrath0fb0b]

With a dozen or so lines of code you can convert any services that listens on a socket (UNIX, INET, NETLINK or POSIX) to have systemd create the socket and pass it in -- and that includes code to fall back to socket creation if it's not launched by systemd. This has a few benefits:

• Startup: Services don't need to signal back init systems that a service is ready to receive requests (or, worse: I've seen colleagues either put in a sleep, or having dependent processes poll, shudder). As soon as the socket is created, requests can be received. When the process is ready to read/select, it gets everything in the buffer.

  In fact, while a ton of people are focused on the way systemd manages dependencies between startup processes, they overlook that socket-passing actually removes dependencies between them. In other words, even if you have some horribly complex web of socket-based services, you can treat them as entirely independent.

• On-demand-services: Got a socket service that doesn't have tight startup latency requirements and is launched infrequently like sshd or ntpd? Why does it have to stick around all the time consuming resources? Let systemd hold the socket and launch it whenever a client connects and just exit() when your last client goes away. Apple has been doing this for years -- aggressively reclaiming memory from daemons that don't need to be immediately available. This also improves startup times because non-essential services aren't launching at the same time as essential ones, decreasing CPU/IO thrash -- I've seen admins create init-groups that launch 5 minutes after startup for this purpose actually, this solves the issue more sensibly.
• Crashes: Services that crash obviously lose all session state, but having the socket persist means that requests never get rejected -- they just wait a bit longer. For a concrete example, if Apache relies on SQL and then SQL crashes, obviously any in-flight queries are going to return errors. But new queries launched by different Apache worker threads will just sit in the socket buffer until SQL comes back to life. This is a pretty big win for mitigating client impact.
• In-place-updates: Services that need to be updated/patched are just a different manifestation of the "Crash" bullet above. Need to patch your services without killing all its clients? Stop processing new requests, fulfill everything in the queue, restart, pick up where you left off. Unless the client is closely monitoring the latency of requests, they won't even know that the service was patched underneath them.

So that's at least one thing that systemd brings that other init systems don't, that solves a few real problems and enables some new features that other init systems can't.

Still easy to remove on a server in Debian sid.

[nsaspook]

Currently on Debian unstable on a server without all the fancy desktop functions nuking systemd is still possible and easy.

Re:Still easy to remove on a server in Debian sid.

[gweihir]

Keyword: "still". There will be significant effort invested by some quarters to close that escape-way.

systemd is Linux logging done right

[Peter H.S.]

systemd's logging system is a huge improvement over old legacy style text logs. It has more early boot logs since it can log while still in initramsfs, and with kdbus it will probably get even earlier and late logging; the goal is "metal-to-metal" logging.

Having structured and indexed logfile (called journal) is a huge improvement in many ways; it allows for rich meta-data like monotonic timestamps, high precision time stamps, UUID's, exe file names and paths, and incredible easy and powerful sorting and filtering with tools like "systemctl".

If you try to add meta-data like monotonic timestamps in flat text files, they become very long and cluttered, making them hard to read for humans.

Another problem with flat text files are the fact that watch scripts depends on the exact wording of the daemon output strings; if the developers changes the wording, third party scripts will fail. In a perverted sense, the exact wording have become a API that cannot easily be changed or extended.
Not so with systemd; it has a stable API and lots of language bindings. It is easy to make a watch script that targets the stable field's.

Some CLI examples: I have used full length options for readability and since systemd have excellent bash completion for everything, it doesn't involve much more typing.

journalctl --boot -1 --priority err

Show all log entries from previous boot only, that have log level "error".

journalctl --since -5m

Show log entries generated the last 5 minutes.

journalctl --follow --unit smartd.service

Follow (tail) the smartd daemons log output.

journalctl _KERNEL_SUBSYSTEM=usb --priority warning

Show only messages generated by the kernel USB subsystem that have log level "warning"

journalctl --field _PID

The "--field" option makes systemctl show all values of the following journal field. In this case it will show a list of all PID's that have ever written to the journal. Want to see every executable that have ever generated log output, substitute _PID with _EXE. Notice the underscore. Field values with underscores have kernel guarantee for being correct.

It is also easy to track two services that you suspect are causing each other problems:

journalctl --output short-monotonic --boot -u NetworkManager.service -u chronyd.service

This will show the log entries for NetworkManager and a sNTP client from the current boot, and show the output with monotonic timestamps. Nice.

Re:systemd is Linux logging done right

[Peter H.S.]

That is all nice and good until journalctl hangs on you, or you can even reach a command line because systemd has insists that the GUI configuration has priority is more important than setting up virtual terminals early in the boot process.

You got it all backwards; systemd provides outstanding early boot support, including VT's, especially because it starts from initramfs even before the root-filesystem is mounted.

The systemd journal is an open standard with a stable API and many language bindings, so there already exist alternative readers.
There are no realistic scenarios where a systemd log file can't be read. They can be copied just like files to another machine one way or another, or the machine can be booted with a rescue disc

In spite of that, you give a good example of how really cryptic journalctl can be.

journalctl --output short-monotonic --boot -u NetworkManager.service -u chronyd.service

short-monotonic? --boot ? Why not --output snakes-n-oil???

The systemctl syntax is extremely easy to both use and understand. Yes, you will have to read a man page before using it, but then again, the only intuitive interface is the nipple, everything else is learned. It is trivial in comparison to learning regex, but much more efficient.

I see you find "--boot" and "short-monotonic" cryptic. That is probably because they are features that doesn't exist in traditional flat file log files (and more or less impossible to implement). But with systemd, every boot is marked in the journal with an unique ID, so it is trivial to select certain boot sequences. Really hard to do reliable with a regex.
Monotonic timestamps is a meta-data time stamp in every log entry. The monotonic time counter starts from zero at every boot, so that every hardware, kernel and service initialization can be followed with an easy time delta. Here is a short monotonic log snippet; notice how time is incrementing.

[ 1.586450] lhost kernel: hidraw: raw HID events driver (C) Jiri Kosina
[ 1.586648] lhost kernel: usbcore: registered new interface driver usbhid
[ 1.586747] lhost kernel: usbhid: USB HID core driver
[ 1.586867] lhost kernel: drop_monitor: Initializing network drop monitor service
[ 1.587025] lhost kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
[ 1.587148] lhost kernel: TCP: cubic registered
[ 1.587253] lhost kernel: Initializing XFRM netlink socket
[ 1.587456] lhost kernel: NET: Registered protocol family 10
[ 1.587714] lhost kernel: mip6: Mobile IPv6
[ 1.587807] lhost kernel: NET: Registered protocol family 17
[ 1.588196] lhost kernel: Loading compiled-in X.509 certificates

What about 'cat /usr/adm/SYSLOG' which stands for 'conCATenate' /usr/adm/SYSLOG. Or if I want to use grep;

grep /usr/adm/SYSLOG error | mailx -s "Errorlog" youradmin@youremailhere.com

(or /var/log/SYSLOG for that newer variation).

You can still use "grep" and all the other standard Linux tools in conjunction with "systemctl". "systemctl" just act as a powerful log filter so often grep isn't needed.

I like your example for grep'ping for the word "error". That way you would miss both "Error" (no "i" switch") and "Warning" "Critical" "Failure" and what not. For systemd you could just use "systemctl -p err" and you would have found all critical log entries.

And why call everything a 'service'. It's called a 'daemon' in unix. Daemons provide services. Services are windows things. To me systemd is the toy for the noobs and wantabe cool ubuntu-ites that have no experience in the thick of server land. And second, I don't find systemd an elegant solution at all. systemv-init, now that is elegant, with the various run levels, and system states.

Service vs. daemon=bike shedding

You may imagine that syste

Re:systemd is Linux logging done right

[Peter H.S.]

They are not "options", but field names in the systemd journal.
So journalctl is querying the "database" directly for the values in the "_KERNEL_SUBSYSTEM" field that again contains fields like usb, pci, etc., that again have log entries.

"journalctl -F (tab)" will show you all possible main field names. Selecting eg. "journalctl -F _KERNEL_SUBSYSTEM (tab)" will show the the possible values:
sound
hid
pci_bus
acpi
watchdog
usb
pci
pnp
scsi
vc
clockevents
(snip)

You can basically "tab" your way to every log entry since they are indexed, and every log entry can be selected and shown by exactly which part of the system that generated them. It is an incredible powerful feature. It also allow you to generate on-thefly log entry lists of every PID/GID/Hostname/executable/service name/etc. that have ever written to the log file. Just press tab and all the values appear instantly.

The field names starting with _underscores have Kernel guarantee of not being faked.

Re:VERY POSITIVE: Systemd is well-modularized

[Barsteward]

Thanks. I always thought that libraries contained all the bits of common functionality that would be used by different programs.

I'm not sure that systemd does lock out competitive replacements. I'm using opensuse 13.1 and it uses the usual NTP and DCHP and not the systemd derived versions so that implies to me that its configurable as to which programs systemd can use.

Nice thing: It makes enemies of freedom obvious

[gweihir]

They sit at Red Hat. They plot a take-over. They aim to destroy most of what FOSS stands for. Systemd finally is the last bit of proof needed of the nefarious machinations going on. It is nice to be sure.

Re:VERY POSITIVE: Systemd is well-modularized

[Theovon]

Systemd is also modular in that it is comprised of multiple components that run in isolated processes, which avoids having one service crash due to bugs in another. It's also not as spaghetti as people say it is. As I said in another post, the high level differences between systemd and sysvinit are:
- sysvinit starts a whole bunch of services whether you need them or not sequentially at boot time, and the startup is controlled by shell scripts.
- systemd starts services entirely on demand, only when they are needed, automatically managing dependencies, and the startup is controlled by C code.
So basically, they're a lot a like, except that systemd maintains more components internally to the project, and it's smarter and faster.

Thinly Veiled Attempt...

[Lodragandraoidh]

The only good thing I can see about systemd is the exposure of some Linux system APIs that were not exposed via the POSIX subsystem. Nice - but not required by most of us - and could be added to existing standards based initialization daemons without totally rewriting the rules.

Otherwise it seems to be more likely a thinly veiled (actually not veiled at all...given comments of the principles) attempt to fragment the POSIX world - and forcing projects with limited resources to make a Hobson's choice of whether to support systemd based Linux or POSIX standards exclusively. It breaks write once - compile/run anywhere - that was generally available for those who made sure their applications were POSIX compliant. This means that a lot of software that was available across Linux, and Unix flavors (BSD) will now be exclusively available on one or the other - thus fragmenting the *nix world.

Software is not separate from the ethics that surrounds it. This approach and apparent rabid anti-interoperability view is arrogant and self-serving at the expense of cooperation and choice. Furthermore, the monolithic architecture, obfuscated binary logs, and centralized configuration are antithetical to the Unix way - and makes a linux system as difficult to deal with as a Windows system from an automation and management perspective, and raises concerns in terms of security (the greater the complexity in a system, the greater the opportunity for bugs - and thus the greater the attack surface).

Finally it throws away many many years of experience/knowledge acquired by system admins, developers, and users about how a *nix system operates and is configured. This fragmentation of the human factors aspect will by its very nature cause faults/issues during operation.

So - for a host of reasons, I believe it is technically - and more importantly - ethically wrong.

There is actually one more good thing I can think of: it will spawn new distros, software projects to provide alternatives of various applications in the stack, and perhaps new operating systems altogether - with a renewed focus on design simplicity (KISS) and all of the benefits that come from that. Once a system becomes too complex to understand - are you sure you can trust it? So to recap: systemd has two things going for it; exposure of Linux APIs, and the power to breath life into the further exploration of alternatives in the OS/application layer.

Re:What system d really is

[TheBrez]

Wrong. Redhat's first release was October 1994. RPM didn't come along until 1997. Debian's first release was August 1993. Their history doesn't indicate the date that the first release of dpkg was unleashed, but it was prior to 1.1, which was in June 1996. apt is a more recent addition, dselect was the package management tool of choice prior to that, and was around since 0.93R6 in November 1995.
https://www.debian.org/doc/man...
http://en.wikipedia.org/wiki/R...
http://en.wikipedia.org/wiki/R...

I've been a Debian user since sometime in 1996, was a RH user from 3.0.3 until around the 6.X days, and was a Slackware user before that (back in the pre-kernel 1.0 days when a distro was 50+ floppies for a full install)

Re:Thanks for making my point

[geoskd]

It happens about 40 times a day on you average PC, it is just rare it hits anything vital. If you run ECC memory you can track how many read errors it corrects. In fact error-correcting memory exists for servers and workstations for this very purpose. It is real and common.

If it is happening at all with any regularity, it is a sign of faulty hardware. The fact that you would allow a machine to continue operating with a demonstrated record of on-going hardware errors shows you are either using very faulty equipment, or don't have any reason to care.

NASA uses mil-spec parts for good reason. They dont have the luxury of hot-swapping a broken part. Long story short, if youre seeing any ECC failures, you have a faulty part that needs to be replaced. If you're seeing it across an entire range of machines, youre observing either a design flaw, or a manufacturing problem.

Less fragmentation

[Peter H.S.]

I like the fact that systemd's wholesale acceptance by all major Linux distros means much less fragmentation in both the way the Linux OS is managed and the easy that upstream projects are now able to support advanced features in a distro agnostic way.

I also like the fact that it exposes advanced kernel features like "cgroups" and "Capabilities" and make them easy to use; just add a keyword in a text config file and restart the service.

Add ProtectSystem=full in a service config file, and the service and all processes it makes can only "read" /usr and /etc enforced by capabilities. So even if the service is compromised, the hacker can't modify these directories, even if the hacker are able to execute code with root privileges.
http://www.freedesktop.org/sof...

Also "ProtectHome=" makes the service unable to read /home, so that no information stealing can take place.

Perhaps the best thing about these features and the many other systemd features like those, are that they can be enabled by either upstream or the distro makers, so that the end user doesn't have to anything in order to improve the system security. It will simply mean improved security and "defense-in-depth" as deafault on systemd distros.

Re:Less fragmentation

[walterbyrd]

You are happy about Red Hat's hostile takeover of Linux?

Re:Less fragmentation

[Peter H.S.]

You are happy about Red Hat's hostile takeover of Linux?

Red Hat have always been a corner stone of Linux. If it wasn't for Red Hat, Linux wouldn't exist today. They have fueled money and developer time into almost all aspects of Linux over the decades, and their lawyers have fought off so many patent trolls and entities trying to harm Linux. AFAIK, Red Hat have been one of the biggest kernel contributors for decades too, so they have had a huge influence on both its design and features.

So I think the "let's hate Red Hat" fad among systemd haters is puerile, stupid and anti-Linux.

And I think even less about the tin foil hat conspiracy theories about mysterious Red Hat forces, working behind the scenes hell bent on taking over Linux.

The accusation of Red Hat's intention of "hostile takeover of Linux" is always vague. How exactly are RH controlling Linux by being a contributor among many when developing systemd? Is there some kind of mind control in the source code, or is it done by chem trails?
Why is RH Kernel and glibc contributions not a problem, while their systemd contributions are?

All the major distros have changed to systemd simply because it is superior in every way to the existing alternatives. systemd simply solves real world problems for both distro makers, upstream developers and end users in a much better way than anything else.

Re:Less fragmentation

[JustNiz]

>> If it wasn't for Red Hat, Linux wouldn't exist today.

Thanks for the laugh. I really didn't think anyone could be that clueless.

Re:Less fragmentation

[Peter H.S.]

>> If it wasn't for Red Hat, Linux wouldn't exist today.

Thanks for the laugh. I really didn't think anyone could be that clueless.

Your high UID suggest that you weren't around when Linux was young. If it wasn't for Red Hat, Linux wouldn't have made it as a viable commercial alternative to MS, period!
Red Hats technical contributions alone was a huge factor in Linux' success. The fact that RH understood to make money on Open Source software, something most other Linux vendors failed to do or even understand, made it possible to hire lots of software engineers, and pay lawyers to defend Linux from the barrage of constant patent lawsuits Linux faced. Remember the SCO case? And while IBM lawyers played a role in that too, IBM was only involved because RH had made Linux enterprise ready.

Here is an old statistic from 2007 that shows how much of the Linux kernel that is written by RH.
http://www.cnet.com/news/who-w...
The pattern have been like this more or less since the late 1990's.
Same with other core Linux projects like gcc, kernel utils, glibc, etc. Take a look of this incomplete list:
http://fedoraproject.org/wiki/...

Most other Linux distros are thriving in the slipstream of the development made by Red Hat in all core aspects of Linux as an OS.

Re:Less fragmentation

[JustNiz]

>> Your high UID suggest that you weren't around when Linux was young.

Your automatic presumption that my slashdot membership age in any way relates to my industry experience only serves to further highlight that logical thinking is not one of your strengths.

>> If it wasn't for Red Hat, Linux wouldn't have made it as a viable commercial alternative to MS, period!

I agree that Red Hat has and does make valuable contributions to Linux, just as many other large companies, such as Google. I also agree that RedHat's contributions have helped (but are not singularly responsible for) Linux breaking the Microsoft monopoly, especially in the server space, however there is far more reason to Linux's existence than just being an anti-MS weapon.
you assertion that Linux would just not exist without RedHat remains patently ridiciulous.

Good things about systemD

[phantomfive]

For the most part, people like the features attempted by SystemD. That is not the issue. SystemD is trying to make a clean bootup system. Who doesn't like that?

Most of the complaints are complaints about the architecture of the thing, not features. If we only wanted an OS, we could use Windows and all the crap that comes with it. Windows works fine. We care about how our OS is built, so we use Linux. We want the bootup system to be architected well.

Systemd has more than halved the reboot wall time.

[tibit]

I have an RHEL 6 system with multiple commercial Java applications. For some reason, every commercial Java application out there seems to bundle half of a linux distro with it: they insist on using their own instance of a web server, their own application server, their own database, their own mail daemon, etc. Starting those things serially is true insanity and takes forever.

With all of this stuff migrated to RHEL 7, tweaked so that there's no init + rc.d craziness left, a 4 minute boot-up turns into 1:30 boot-up. This is with spinning drives. I have another iteration of tweaks where I exposed all internal service dependencies inside each of those monolithic app monsters to systemd, and we can be up and running in 1:15. Looking at I/O statistics, with further judicious use of preloading we should cut it down to 1:00-1:05 after a clean shutdown. The shutdown times, usually well over 2 minutes long, are down to 30 seconds.

This is all measurable, no-bullshit, experimental data. We even managed not to have to touch any of the commercial app's rc scripts, I simply coded up the requisite systemd configurations for those services, based on the rc scripts. If there's any question as to systemd's effect on the application, or if we need to deal with vendor support, we can always start it up using the rc scripts.

So, I don't care about ideology behind systemd, and how it fits with someone's ideas about what Unix or a Linux distro should or shouldn't be. All I know is that it'd have taken me 5-10x as long to tweak the system rc.d scripts to parallelize them than it took me to "port" the commercial apps we use over to systemd. Of course the distribution's own services already use systemd, so I didn't have to touch that, only tweak a few things slightly to further leverage parallelism. It has saved us time and money, and the system availability is much better in face of the rare reboots. Everyone is happy. We're a small shop with a single server, and we use no virtualization nor any other enterprisey stuff. Just a plain old RHEL 7 running directly on hardware, with selinux turned on, with custom policies written for each of the commercial apps.

A lot of the "recommendations" I've got from "veteran" admins essentially reduced to throwing money and resources at the problem. That's IMHO a rather direct vindication of systemd: if it takes a SAN, multilevel storage and VMs just so that the damn init/rc.d-based system will boot in a reasonable amount of time, and all of that is taken care of by systemd, it'd be rather irresponsible for me to try and ignore systemd. In the name of what? Nothing I can think of. It's not like I can tell the management "hey, RHEL 7 comes with systemd, but I can keep using RHEL 6, not use systemd, and spend $25k+ for a SAN, VM and OS licenses, and the time to set it all up and document it all".

<rant> It takes some chutzpah for commercial vendors to claim RHEL 7 "support" in their solutions, if they support neither selinux nor systemd.</rant>

Re:The best feature of SystemD

[Peter H.S.]

It's not available on OpenBSD.

But it will be. The "systemBSD" and "Uselessd" projects are just a warm up.
Of course all the BSD's will get modern init systems like systemd before this decade is over.

Resource Activation

[tkotz]

I like that systemd combines the functionality of insserv, inetd and autofs into a single resource activation model so that whether the resource is a file, a process, an IP socket, UNIX socket or a named pipe.  It manages everything. You don't have to worry about which resource kicked off or race conditions on processes tied to multiple resources. We could get to a point where things like mysqld could be reliably started by activation from either named socket or TCP/IP without concern for race condition. It really is inetd done right.

Parallel booting of services

[Spacelord]

... and then the systemd kids will just end up reinventing the same sort of hacks that they were complaining about in SysV scripts to begin with.

Stop means STOP

[Spacelord]

So what does it do if a service does not respond to a request to shutdown properly? Does it just pull the plug with a kill -9, because that seems like a terrible idea to me.

Solaris smf

[tbuskey]

I went through the Solaris 10 transition to SMF.
  I don't think it was stable until 10.4. You can still create new init.d stuff.

Systems feels similar, but it is more stable (in RHEL 7). The man pages are useful.

I find the upstart man pages in useful. Why doesn't the upstart page reference
stop, start, etc?

Now if they require us to use network manager instead of sysconfig/network-scripts..

Integrated resource limitation

[Canek]

With systemd, you have integrated resource limitation, meaning you can explicitly set nice level, OOM score adjust, IO scheduling class, CPU scheduling policy, etc., in the unit file for a service. You can see the different knobs available in systemd.exec(5) http://www.freedesktop.org/software/systemd/man/systemd.exec.html

I have a very old Pentium 4 machine acting as a web server (500 mb of memory!); sometimes the MySQL instance would consume all of the CPU, and the Apache requests would get queued until it brought the machine to its knees. If I was really patient I could try to get an SSH connection to zap the MySQL and/or Apache processes, but what I usually did was to ask the people nearby to push the red button and restart the machine. With systemd now I adjusted the CPU scheduling of MySQL, and I have never had the issue again.

Yes, I could do that independently of any other init system; but it's clearly integrated with systemd, and is really easy to set (and with drop-ins, you don't even need to worry about the upstream unit file changing). Only for that, I will not change again to any other system that doesn't provide, out-of-the-box, the same functionality. Or any of the other nice thins that systemd provides.

Re:What system d really is

[Aighearach]

So basically, everybody with resources (such as skill+time, or money+desire) choose to migrate to systemd, and people without resources (no time or no technical skills, or no money) have to take the "scraps" (other people's work) and... they can't just keep using SysV init? Why, again?

No, they do have choices. Distros are real, they have real people working on them, and they choose package A or B based on their needs and philosophy. Keeping SysV init is an easy choice for a distro that doesn't care about the needs of sysadmins. Choosing systemd is also easy; it already exists and solves real problems.

Protip: if "your side" has a bunch of trolls name-calling the developer, double-check all technical claims. Don't just believe and repeat whatever FUD you hear that sounds technical, or came from a guy you're sure "knows something about... something."

Speed

[Spacelord]

So what kind of stuff are you starting up in parallel then, that you gain so much in boot time?

I have not seen any practical gains here. Even on my second PC, an old core2duo with an SSD, I don't see any difference in boot time between Slackware, Arch and Mint. The longest parts in the process are definitely the POST and grub phase, but once Linux actually boots it just zips on to my boot screen in a few seconds.

If there is a difference, it's going to be in the magnitude of a second or so, and that hardly warrants a new init system in my opinion.

Re:Journalctl logging is more secure (bug #1098132

[steveha]

Caveat: I am not a sysadmin. But I have read up on SystemD.

With systemd, one can't even remotely log a journal natively

Why not? SystemD offers its own logging system, but does nothing to prevent you from installing a more capable logging daemon such as rsyslog.

Note that before Fedora 20, rsyslog was installed by default, along with the SystemD logging. In the announcement it says:

rsyslog will remain the recommended option to install if users require /var/log/messages, need support for the syslog network protocol, or need to enforce strict data lifecycle policies. It's sufficient to install and start rsyslog to get /var/log/messages and BSD syslog support.

Emphasis added by me.

http://fedoraproject.org/wiki/Changes/NoDefaultSyslog

You stated "one can't even remotely log a journal"... well, one can if one is able to type: yum install rsyslog

So IMHO your whole argument fails. Not only is it not impossible, it's not even difficult.

...this entire proposition by samzenpus is inane. When one thinks backwards from what the motivations might be, none of them are good and make me lose that much more respect for the site.

The story was submitted by a user named "ewhac". Unless you are accusing "ewhac" of being a sock puppet fro samzenpus, this whole mini-rant seems rather pointless.

Parallel booting of services

[roemcke]

Wrong, services are considered "booted" when they are ready to process requests. For most services, the kernel kan be made to "buffer" request, so we don't care in which order they are started. For those rare cases when we do wan't to hold off a service, the unit-files can specify exactly what to wait for.

Oh, and by the way Sys-V init scripts never solved this. They depended on the daemons to solve this, which they virtually never did. Or sprinkle the init-scripts with strategically placed sleeps. This resulted in either the boot taking to long, or fail.

Try to do a 'grep sleep /etc/init.d/*' Every sleep you find is a potential boot failure.

You can read more about it in the systemd-documentation. You'll find it on the systemd homepage: http://www.freedesktop.org/wik...

Re:What system d really is

[Aighearach]

Odd that of all possible choices, systemd developers chose almost
always a way that is exactly the same or very similar to what Debian does.
For example, I don't see stuff like /etc/sysconfig, while I do see things
like /etc/hostname etc.

Everybody else has /etc/hostname too, sorry to pop your fanspiracy.

My second biggest problem with systemd

[tkotz]

Abandonment of classic config files and locations.The unit files are nice, but create a pretty large barrier to entry.  This has created the requirement for a lot of duplication of work and two different places in the file system to look for config info. The information in the .service files could have been added like the LSB headers to the /etc/init.d/* files.  The socket activation information could have been stored in inetd/xinetd compliant configurations with some ignorable syntax for adding named pipes and sockets. Automounts could have been parsed from /etc/auto.master. Fortunately they did this with /etc/fstab and the existing LSB headers at least.

I feel that most sys admin angst on systemd comes from the fact that they moved all the config files and created a new standard. They could have saved themselves a lot of ill will with this more backwards compatibility friendly configuration interface. instead of everything being a 20 character file name stuffed in one of the many systemd directories.

Re:Thanks for making my point

[MSG]

It happens about 40 times a day on you average PC

No, it doesn't. I operate lots of machines with ECC RAM. I've seen ECC correction. Bits flip, but nowhere near that frequently. It's very rare.

Re:Where do you think you are?

[Aighearach]

Yes, he is. Coward.

Re: Thanks for making my point

[Aighearach]

Please try reading and fully understanding posts before responding.

If he comprehended your words, he wouldn't have had to post as a Coward. lol

If LP hadn't invented Systemd, someone else would

[DanielOom]

My laptop boots almost as fast with Systemd compared to System V, and it shuts down much faster.

Re:Thanks for making my point

[Aighearach]

So the random bit flip you're not at high risk of, means that none happen? Derrrrrrrrrrr..... Oh, wait, my mistake, you're Anonymous Coward, it was my mistake to think you're more technical than a tree frog.

Fun fact: digital computers are made of analog parts, and each transistor has different performance. Random-seeming, unexpected bit flips can and do happen (dozens per day per host) just based on various minor manufacturing flaws and material inconsistencies. Rarely hurts anything important, I mean, unless you have a whole server farm, then you're having a small number of things go wonky all the time. If something only crashed one time, ever, you want it to have just restarted. You're not going to solve 100% of those in a large environment. The ones that call for resources and troubleshooting are the problems that happened 2 or more times, or the problems that line up with known causes, or that created a useful crash report in the logs.

My biggest concern about systemd is not technical

[tkotz]

Their image as an embrace and extend project. And more concernedly that they don't care that they are viewed this way. The big problem here that they could easily fix is breaking up their source repository into multiple smaller projects. I think the best example of this is "systemd-"consoled.  Now don't get me wrong I like consoled a lot. It looks like a great next gen production of kmscon. Which I also though was a really good innovation project. But there is no good reason it should be in the systemd git repo. systemd obiously doesn't need it and it doesn't need to be any more tightly integrated with systemd than X11 or mariadbd does.

They don't care that they are perceived as not understanding the importance of keeping things as loosely coupled as possible.

I guess the alternative is you look at the systemd repo as the whole Redhat system stack with the ability to pull out the subcomponents you want, but you are really taking part of a whole distro not one of many separate services. And it will be supported as such.

I forgot...

[emil]

1. You need to "export SHELL=/bin/sh" before you start.
2. The "exit" above should be on a line by itself.

More stuff I forgot.

[emil]

• You can check for static linkage with "file busybox" - it should say: busybox: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
• After you login as root above, you can "halt" to shut down the container and get back to the normal system.

Re: Nice Thing: systemctl status shows you log ent

[Wheely]

OK thanks for the clarification.

However, I have never ever needed a pid file. If I have written the deamon myself, it ensures it "ps" only produces the correct "hit" or can be readily found in /proc (if the OS supports it) or can otherwise be communicated with via an IPC. For other daemons I will trust to careful ps and grep and have never stopped the wrong thing.

Ok that might be a bit annoying for most its true. However, as all daemons are the child of init, init will be informed by the kernel if a child dies and wait() will get the pid so all that difficulty could be fixed in a few extra lines to init.

The grouping of everything together is achieved by cgroups, not systemd so theres no reason why you cant arrange that using standard sysvinit. To be honest as cgroup like technology has been around in other systems before, youd wonder why nobody ever bothered to implement such a solution before, maybe nobody saw the need.

Actually, the binary logs bother me the most.

Systemd is great because...

[hazeii]

The killer advantage of systemd is the money it makes. By integrating this software into our distro, we can be sure that any business using linux will take one look at the complexity, binary logs, and other great features and realise they really need to pay for a support contract. You see, this fixes the problem of the old, really lame (simple, yuk!) systems that have been around for years - anyone with a bit of shell knowledge can learn them in a few minutes, and it's really hard to make money when kids with some computing knowledge can sort system problems out. No, in order to convince customers that support contracts are necessary we need to replace the easy, working stuff with something we invented, something far richer, something that we can integrate into the system and which gives us addtional control. With this approach, we can effectively neutralise all those damn people who can learn how the system works in their spare time. Just make it so complex, only paid professionals can afford to flail about fixing things! As is clear, systemd fits that bill perfectly (along with pulseaudio and a nod to udev). Never mind all those whining ninnies (hey, tell them to go pay for a support contract if they want to use linux). What really matters here is the benefit to the bottom line - just remember, people, complex crap sells support contracts!

In summary, systemd is great on other's people machines - when you'd getting paid by the hour!

Re:As long as it works

[alva_edison]

Actually the Mas and Pas is a easy Linux market, just setup a desktop with a functioning copy of firefox or chromium, remote administration via ssh and you're set. Add open office for the random document and that pretty much covers the Mas and Pas requirements.

As long as it has functioning Java and Flash. Unfortunately, Java in Firefox on Linux tends to break a lot and my experience has been Flash only works correctly on 32-bit systems.

Re:Journalctl logging is more secure (bug #1098132

[steveha]

syslog-ng is receiving a copy of what journald is deciding to write

Yes, that seems pretty clear. What of it?

The original poster was claiming that SystemD is unsuitable for servers because there was no possible way to get remote logs, and thus if someone cracks the server he could mess with the logs. Installing rsyslog would solve the problem. The attacker could scramble the SystemD binary journal files, but not the remote log.

Why should I care whether the log data was collected by the SystemD logger (I guess it's called "journald"?) before rsyslog got it? As long as the log messages are faithfully passed along, where's the problem?

Re:VERY POSITIVE: Systemd is well-modularized

[DrJimbo]

All they've done in systemd is write C code to start up services that used to be started instead by shell scripts and added the ability to make dependency resolution automatic so that services are only started when they need to be.

If that had been all then there would not be this huge controversy. You are describing a very stripped down version of uselessd which is already a stripped down version of systemd. You are ignoring 98% of what is most objectionable about systemd by reducing it to the least controversial component.

ISTM such vast oversimplifications add fuel to the fire and further polarize the debate.

Re:Thanks for making my point

[sjames]

I do use ECC in servers and I definitely do not see 40 bit flips in a day.

If you see that many, it's worth making sure the power supply is stable and the power quality is good.

Power supply ratings are total crap these days. To get actually stable power, you may need to go with one rated for double the power that will actually be needed.

Re:Systemd has more than halved the reboot wall ti

[walterbyrd]

As I understand it:

1) Systemd has a much slower shutdown, which means a reboot takes much longer.

2) Debian can be rebooted in 30 seconds. So even if boot was speeded up, it is a negligible advantage, and hardly justifies such a radical change.

3) Linux servers are not rebooted very often, making supposed advantage even more negligible.

4) If a service is critical, there should be a parallel server running it. Which make boot time even less meaningful.

5) According to this article at Distro Watch: http://distrowatch.com/weekly.php?issue=20141027#qa : boot times are not improved. That has been my experience as well.

It's open source. It's part of the ongoing convers

[BitwizeGHC]

Systemd is open source software, which Lennart has made available more or less out of the goodness of his heart. You may hate it -- God knows I fucking hate it -- but the world really is a better place for it having been written. Why? Diversity. Systemd is yet another set of ideas in the ongoing discussion that is open source development. Software gets written, then it gets patched or replaced by someone who thinks they can make it better, and alternatives for every use case flourish. It's a conversation, a debate. So while there may be vehement disagreement with the ideas that systemd represents, we are all better off for at least having heard and considered those ideas.

Just don't make the entire user-space stack depend on systemd. Please.

Re:Nice Thing: systemctl status shows you log entr

[buchanmilne]

Please provide a link to your patch or git repo with this feature.

Yes, I like this feature of systemd. None of the wonderful, stable, featureful init systems (I have maintained init scripts in linux distros with two different init systems before systemd) linux init systems has it.

Until one does, please acknowledge this as a feature systemd has that is nice, and is non-trivial on any other traditional init system (at least without invoking the wrath of the 'I don't want my init system to take over /dev/log' crowd).

Re:Where do you think you are?

[fustakrakich]

Well, absent any useful information, your opinion on systemd would have been preferred to a lecture. Me? I'm suspicious of anything new, and believe that SCO should have had the last word in this whole UNIX thing.

Re:Bets solution for systemd

[jbolden]

Windows and iOS.

iOS uses launchctl which is systemd's father.

Re:Journalctl logging is more secure (bug #1098132

[buchanmilne]

Caveat: I am a server admin.

With systemd, one can't even remotely log a journal natively, which is par for the course in many server environments.

If you are referring to the feature enhancement tracking bug you link to below, the text of the bug states:

Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs. This can be used as an alternative or in addition to existing log forwarding solutions.

I assume the 'par for the course' is normal log forwarding via syslog, which is noted as already available in the text above.

You can't make this stuff up, please see bug #1098132 (https://bugzilla.redhat.com/show_bug.cgi?id=1098132) At the time I'm writing this, that functionality still just *doesn't exist* in systemd/journalctl.

The feature linked to from the bug is a feature that doesn't exist in any logging solution I am aware of. It brings the benefits of the journal (being able to detect if there are missing messages) to remote logging. Yes, there are means to try and prevent an attacker from reaching your logging server, but can you *prove* your remote logging server has not been tampered with? No? With remote journal logging, you would be able to.

No, this will not remove journald from being the owner of /dev/log (as you imply in replies below). If you use this feature, you will have the 'binary logs' feature the rest of the anti-systemd crowd decries on your remote logging server.

The feature you want has been available since journald was availble in any released distribution (and I might add is usually the default in a server-oriented distribution such as RHEL7); the feature tracked by the bug you linked to probably isn't what you want.

Re:On demand startup of services at the socket lev

[sjames]

man xinetd

Re:Where do you think you are?

[sjames]

The problem is that he didn't want a debate, he wanted a love-in.

This is not woodstock.org.

Re:Nice Thing: systemctl status shows you log entr

[TechyImmigrant]

I tried it. It took 5 seconds to complete and put funny carreted As in the output..
                      ââ 670 /usr/sbin/httpd -DFOREGROUND

WTF?

Re:On demand startup of services at the socket lev

[jbolden]

xinetd does that for internet ports. It doesn't do it for generic sockets. Something like an xinitd+ could do it for sockets. The idea is clearly there, a key hard part done. There might be some work to getting it to work smoothly for partial loading but I'm not sure how useful that is in practice.

Re: Stupid to switch os?

[beermad]

If you're in the situation like me where systemd has a SERIOUSLY deleterious effect on your computer, there's nothing stupid about switching to a distro that doesn't use it. Frankly, I'm sick of having my shutdowns delayed because for no apparent reason it wants to wait for 90 seconds for some process it doesn't even bother to identify to finish before finally shutting down. That said, I WAS rather hoping someone might post some top-level stuff as the OP requested about what's GOOD about systemd, so I could see if there's ANY benefit to it.

Re:VERY POSITIVE: Systemd is well-modularized

[rastos1]

Systemd is modular: ...

Consisting of multiple binaries/libraries is not sufficient to call it modular. Not in my book anyway. What are the options to replace a specific "module" with a different implementation?

Re:Systemd helps run Slashdot

[DuckDodgers]

You got it in one. I think real flame war over systemd would have been much smaller if there wasn't so much money to be made in fanning the flames. Sorry I don't have mod points at the moment.

Re:Systemd has more than halved the reboot wall ti

[tibit]

"I have an RHEL 6 system with multiple commercial Java applications." That's the difference you're looking for. I'm not running a barebones RHEL system. 95% of the resident set on that server is code that didn't come from any distro, it's the heaps of a multitude of JVMs and database servers that are bundled with commercial apps. Every one of those damn things takes at least 10 seconds to start up, and that's only if it's a simple thing. A full-stack application like Zimbra can be starting up for 40 seconds. There's also the issue of parallelizing the bring-up of network interfaces, which I did. For some reason a stock RHEL 6 takes 5+ seconds per network interface - I managed to parallelize that, too, and to set up dependencies between each interface and the services that use it. Since we isolate nodes on the internal network using tagged vlans, there's about 50 interfaces that have to be brought up, and most of them have no dependencies.

"If a service is critical, there should be a parallel server running it." Maybe in an alternate reality. Who can justify spending on a very decent server that is then vastly underutilized because you don't run everything you can on it? That "server" would be, at best, a VM. Of course a VM by itself doesn't fix the internal dependencies between elements of full-stack monolithic commercial apps.

It wouldn't matter if I used a pre-systemd Debian, since the serial shutdown of the commercial apps that I run would take 2 minutes. It's distro-independent after all, since all those apps are 3rd-party monoliths as far as the distro is concerned.

Again - we run a multitude of services - CRP/ERM, building automation, support for our own hardware, email (groupware), document management, phone system, security system, and a couple of other things, including support for our own R&D hardware labs. It's all on a stable, well-performing piece of hardware, that's well utilized with a bit of capacity to spare.

Re:Journalctl logging is more secure (bug #1098132

[steveha]

where's the problem?

Upon re-reading the original post, I have figured out what I missed the first time around: the original poster doesn't trust the SystemD journal system and wants the ability to completely remove it. (I had tunnel vision on the remote logging thing; mea culpa.)

The original poster also claims that, as existing logging solutions are well-understood, that using the SystemD journal system might expose the owner of the computer to liability. I consider this idea rather wild; I'm not a lawyer but I'm pretty sure that no court would consider it negligent to use the provided logging daemon that Red Hat has been shipping for years now. And, one of the reasons for the binary format in the first place is to make it impossible to alter a log without the changes being detected; this seems like a rather strong advantage with respect to liability.

I would like to see statistics of how many computers are running SystemD, and of those, how many have had actual problems with the journal. If it's as bad as the original poster is claiming, then let's see the numbers.

Systemd broken PulseAudio!!!

[Trevelyan]

I have a Debian HTPC system tracking testing and systemd tried to save from the indignation of PulseAudio. Given configuring ALSA for AC3 S/PDIF is not as easy as it should be, I let PulseAudio stay on my system.

Then came systemd and any application (Flash, KDE itself, VLC) would hang as soon as it attempted to output sound. "PulseAudio --start" instances would just multiply and multiply.

My girlfriend was somewhat annoyed that she couldn't watch her programmes, and trying to work out what was happening was getting to me too.

After battling PulseAudio and ALSA settings, I was started to question if it was a mistake to leave PulseAudio installed all this time. Systemd was trying to help me see my error.

However given my girlfriends mood and lack of patience, as well as the fact that everything worked before Debian switch my init system, I tried apt-get install sysvinit-core and reboot (mostly out of desperation). From that moment on we've had no problem with sound, PulseAudio nor any of the other 'bugs' that showed up recently.

Given my sense of humour, I find it hilarious that systemd seemingly broke PulseAudio. Beyond making me laugh it also induces a sense of nostalgia. As I was in Uni all those years ago, I remember playing CoreWars. This was a game where two users would to develop a programmes that tried to avoid and eradicate the other users program.

Up until I removed systemd I imagine a similar battle being waged on my HTPC. PulseAudio battling with PID 0 and spawning many copies of itself as protection. On the other side systemd using it ultimate control of the system to hijack dbus and udev in order to isolate PulseAudio and to prevent it from communicating with the outside world.

If it weren't for the non-amused look on my girlfriends face, I might have let the two battle it out. However as it stands PulseAudio has won, as systemd is no longer running on the system. Did good or evil win? We'll never know. Suffice to say during the whole affair systemd said nothing, not a single peep to stdout nor stderr.

Say something nice about systemd

[buckfeta2014]

No.

Stop harassing me to use your shitty software.

Regards,

A gentoo user

Re:Nice Thing: systemctl status shows you log entr

[thegarbz]

That's systemd's problem (and your response is their attitude) in a nutshell.

Well actually that's systemd's solution. It never has been about fixing a problem with init like a lot of people claim. Systemd is supposed to be a one stop shop for complete integrated system management. A ground up redesign and a change in philosophy.

Yes some .... err many... people hate that idea since it's not Unixy (but they give X a free pass and poo poo Wayland so ... whatever). Fundamentally systemd is not about making something better. It's about bringing a lot of functions under one umbrella. I actually like this. Many people hate this.

In fact many people seem to hate the idea that a new feature needs a new ground up re-write even if they are doing something simple. Some of the comments here seem to suggest that the correct solution is 3-4 bolt on helper applications running on top of sysvinit as a way of doing even a tiny subset of what systemd provides.

Nice things about systemd

[jacob8404]

IMHO there are many nice things to be said about systemd:

• 1) it provides a predictable baseline set of features that developers can rely on
• 2) it allows apps to create and manage services using a well-defined API rather than random, break-prone, kludgey scripts
• 3) dependency resolution, evenement handling etc.
• 4) at last it gets rid of the *nix heritage

Standarization

[hobarrera]

When jumping on a machine with a distro different to my own, I'd have to read for a while before understanding how to start/stop services. This was a pain if I needed to quickly help someone out on how to do something.

Now all distros run systemd, so it's just "systemd start nginx" on any gnu/linux distribution. Except gentoo, but I don't see a gentoo user asking me for help on how to do X. I also haven't come across clients with gentoo-based servers.

Standard service unit files help too. The work is done once, (generally upstream) instead of having to write service configuration files for every single distro (and keeping them up to date!). This may sound trivial, but the amount of effort reduced is immense!

Re:Standarization

[walterbyrd]

Seems like Linux could standardize without radically changing everything.

Seems like Red Hat breaks real standards. And replaces those standards with Red Hat standards. And then says "hey look, we've standardized things (and we've done it in such a way that now Red Hat can take over Linux! Yay!).

Re:Standarization

[hobarrera]

In all honesty, there was no single standard before, but one for each distro (of small family of distros).

True, systemd did change a lot of things, but that doesn't invalidate the former point: it did standardize a lot in the process.

Re:Standarization

[hobarrera]

Why would it be dificult to migrate from red hat to another distro in the first place?

Re:What system d really is

[suy]

Odd that of all possible choices, systemd developers chose almost always a way that is exactly the same or very similar to what Debian does. For example, I don't see stuff like /etc/sysconfig, while I do see things like /etc/hostname etc.

Everybody else has /etc/hostname too, sorry to pop your fanspiracy.

Let me quote from the biggest myths:

Now, as it turns out, more frequently than not we actually adopted schemes that where Debianisms, rather than Fedoraisms/Redhatisms as best supported scheme by systemd. For example, systems running systemd now generally store their hostname in /etc/hostname, something that used to be specific to Debian and now is used across distributions.

Maybe the example was too subtle, but for sure there are some things from /etc/sysconfig that are gone from Red Hat, and are substituted by Debian-style configuration.

Re:Systemd has more than halved the reboot wall ti

[walterbyrd]

You are manufacturing special situations to support your conclusion.

Are you kidding about the server? If a service is critical, the cost of an extra server is nothing. Also, if you are running all the stuff you say you, how "under utilized" could the server be?

Linux has it's problems - no doubt about it. But boot time would rarely top the list. SystemD is solving a problem that is not there. The radical changes that are required to utilize systemd are not justified, not by a long shot.

Re:What system d really is

[walterbyrd]

Redhay is using MS's playbook.

- Systemd seems a lot like Microsoft's OOXML strategy: say it's open, when it's really controlled by one company. Claim that users demanded it

- Hide everything in a binary blob

- Embrace monoculture

- Do not play well with others - especially UNIX

- There can only be one and so you must win at any cost

- Replace accepted standards with *your* standard

- Embrace, extend and extinguish because the people responsible for it have a culture which wants that

- Adopt Borg philosophy: resistance is futile, we have already won, why are you arguing?

- Be intensely hubristic: systemd is the best, therefore systemd is superior to all other systems, therefore systemd should to the jobs that other systems do.

Re: Nice Thing: systemctl status shows you log ent

[SharpFang]

Pidfile is a pretty simple approach to singleton-like behavior of a service. Check for pidfile, if other than own, check for process under that pid, treat it as master/server, and pass whatever commands you had to it, then quit. If the pidfile is absent or no master resides under its pid, create/overwrite it and become master yourself.

That's not the only possible approach but it's much simpler than elections/arbitration and searching the whole process table for other instances of self or otherwise advertizing yourself to other instances.

Otherwise, a pidfile tends to be a handy tool for companion scripts/tools, but far from essential.

Re:Bingo: Exactly what scares "admins"

[walterbyrd]

You do not know what you are posting about.

I worked as a developer, and an admin. Admins are way more than users with root access. I doubt you would last a day as an admin.

Re:No points for bringing up performance???

[walterbyrd]

> If you are telling me systemd boots up my system faster, then you've just convinced me to use systemd.

Good lord, more crap about fast booting, as if that's some huge issue. It's not.

You think there is nothing more to performance than fast booting? No concerns about security, or stability?

Re:On demand startup of services at the socket lev

[sjames]

I can't imagine it would be all that hard to add AF_UNIX sockets to xinetd.

I'm not so sure the whole idea is actually all that helpful on a modern system. If the daemon runs standalone but isn't active, it will be paged out (well, the data segment gets paged out, the rest is already backed by the bin and library files) to make room for things actually being used. At that point it doesn't really hold significant resources. If something actually connects to it, it will page in already initialized and ready to go.

OTOH, if xinetd or systemd holds the socket, still no significant resources, but if something contacts it, you have to wait for both the page-in AND initialization.

That whole scheme made more sense back when Unix systems typically had less sophisticated memory management.

Re:Thanks for making my point

[Noah Haders]

were you talking to santa claus?

Re: Nice Thing: systemctl status shows you log ent

[Wheely]

pidfile approach is guaranteed to fail or require operator intervention from time to time. It can even be dangerous and result in the wrong thing being killed just as much, if not more than not using a pidfile.

Your description of the workflow using a pidfile already requires accessing the process table so why bother with all the other stuff. Just look for another instance of your daemon. If there is one, send it your commands but if there isnt start up.

Thanks to Everyone!

[ewhac]

Well... All told, I think that went rather well.

I wanted to chime in and thank everyone for participating in what was clearly an insane exercise in trying to cut through the acrimony and vitriol and get some actual information on what systemd is and what it's trying to do. You can't always grok what complex things are about just from the docs. That's why I wanted actual first-hand experiences from people who could point to actual gems they'd found.

To respond to some recurring remarks throughout the comments:

• "Obviously a pro-systemd shill."
  No, I'm not shilling for RedHat or Poettering. In fact, I gave Poettering some stick for the whole corrupt-binary-logs-aren't-a-bug thing a couple weeks ago. I was being forthright in the opening paragraph: The simple fact that systemd has been widely adopted despite widespread protest made me genuinely wonder what I was missing that I hadn't figured out from the docs I'd read. So, no, there's no conspiracy here.
• "Who are you to establish posting rules?"
  Well, gosh, sorry, but I was trying to save everyone time. Seriously, tell me you haven't gone, "Oh, ${DEITY}, another systemd thread; there goes my afternoon as I pick through the rat's nest of comments." So I hoped -- perhaps naively -- that requesting some organization would let us all get to the meat of issues of interest fairly quickly. And enough people did choose the follow the rules that the discussion overall turned out valuable (for me, anyway).
• "Why do you dislike something you admit you know nothing about?"
  For largely the same reason I dislike Windows without having comprehensively pored over the "design" docs for COM, DCOM, MFC/ATL/WTL, WDM, NTFS, NTLM, Direct${THING}, Active${THING}, etc. etc. etc. Poorly-designed systems seem to have a certain "pattern" to them, and systemd at first glance seemed to match that pattern (the use of Windows-style INI files syntax didn't help, either). But the people adopting systemd are clearly not idiots, so I hoped people with actual experience with the thing could convey insights that (for me) the docs so far have not.
• "You're thinking of the ads for Miller Lite, not Bud Light."
  *headdesk* I would like to apologize to a no doubt deeply irritated TV ad executive for completely misattributing their fifteen-odd years and millions of dollars worth of loud beer ads to the wrong company (I think this speaks well to my socially-isolated geek cred, though :-) ).

In the best tradition of USENET, I thought I'd summarize the highlights of what I got out of the whole thing. Most of the good posts have already been modded up, but the ones that especially stood out for me were these:

• http://linux.slashdot.org/comm... , describing what 'systemctl status ' can do.
• http://linux.slashdot.org/comm... , pointing out a point/counterpoint summary on uselessd's Web site.
• http://linux.slashdot.org/comm... , describing that systemd plays nice inside a container, presumably making it easier to create VM-ish setups.
• http://linux.slashdot.org/comm... , where the poster describes how systemd does a better job of stopping processes/daemons. The poster then sticks around, giving clear answers to further questions.
• http://linux.slashdot.org/comm... , describing how systemd exposes Linux cgroups to create limited execution environments for daemons or (it appears) any process.

Re: Nice Thing: systemctl status shows you log ent

[SharpFang]

How do I find the master instance, say, from a tool written in shell script?

Re:VERY POSITIVE: Systemd is well-modularized

[Theovon]

As I have been coming to understand, you have a good point. What I don't know is if these components have well-documented interfaces so that they can be swapped out.

Re:What system d really is

[Peter H.S.]

The community is not forming around systemd. Systemd is being rammed down our throats by one company.

systemd had hundreds of contributors before it was used in any long term stable Linux distro like RHEL7. So many developers started to drool when they saw the systemd feature list; it presented much of what many people have longed for in a Linux init system. So yes, systemd was quick to gather a community and is now probably one of the largest Open Source projects when it comes to developers.

systemd is simply superior to SysVinit in every way which is why all the major distros adopted so quickly. It simply solve a lot of real world problems and makes life easier for both upstream developers, distro makers and end users.

For those who think SysVinit style init systems is what Linux should be using the next 30 years, there is Slackware. It is a nice general purpose distro that is very traditional.
So nobody is forced to use systemd if they don't want to.

Re:CentOS 6.5 & Debian Wheezy

[Hognoxious]

Which GUI on 6.5? I use the default Gnome 2 and it's OK. Is 7 on Gnome 3 (blech)?

Just my 2 bytes...

[bjoswald]

I am nowhere near an expert, but as someone who uses Linux everyday (Ubuntu. So what?), I have to say Pulse doesn't give me much trouble. It's annoying that I have to edit a conf file to set up my 5.1 audio channel map, LFE remixing, and resampling rate, but after that, all I have to do is adjust my volume in alsamixer and call it a day. Hardly a catastrophe. Systemd, on the other hand, I agree with in theory: I agree the boot process should be handled by daemons that dynamically load and unload what is needed. It should have been that way from the beginning. A simple script, I suppose, could do the job too, but it's 'dirtier', and seems rather ... hacky. However, systemd's tentacles have now begun to dig themselves into other parts of the system and that, to me, is wrong. It should handle booting and dynamically unloaded/loading modules that are needed. That's it. Why does it need a console? Debugging purposes? That can be done with the Terminal we already have. TL;DR: Systemd's roots are growing too big for the pot.

Re:On demand startup of services at the socket lev

[jbolden]

You have a good point about memory management being an alternative for holding huge numbers of sockets open.

Re:My mom always said...

[Hognoxious]

https://www.youtube.com/watch?...

Hmmmm

[Hognoxious]

This has it pretty much covered.

April Fools?

[Evan Langlois]

This is a Halloween joke, like April Fools right? Systemd doesn't have anything good I can say about it.

Something nice

[La Camiseta]

It's not on my FreeBSD servers, so it's got that going for it.

Re:What system d really is

[Lodragandraoidh]

... Keeping SysV init is an easy choice for a distro that does care about the needs of sysadmins. ...

There; fixed that for you. Your statement made a very big assumption - not borne out by statements I've read here by system admins.

Re:What system d really is

[Lodragandraoidh]

For those who think SysVinit style init systems is what Linux should be using the next 30 years, there is Slackware. It is a nice general purpose distro that is very traditional. So nobody is forced to use systemd if they don't want to.

Until some key functionality used by people is no longer available in that distro due to decisions made upstream to no longer support the code base, or other dependencies.

If I use KDE - which I do - then packages for that become unavailable at some point in Slackware given the above. That means I will be forced to use systemd if I want to continue using KDE; which also means I will have to change distributions, assuming Slackware remains systemd free, as well.

Not trivial. Not easy. Not freedom of choice.

It simply solve a lot of real world problems and makes life easier for both upstream developers, distro makers and end users.

That is simply a lie.

That is a hard question to answer

[vilanye]

It doesn't crash every five minutes? That is a positive, right?

Re:What system d really is

[Aighearach]

There; fixed that for you.

No, you're just trolling. Nothing was fixed, and the very concept that you can "fix" another persons opinion by stating your own opinion as if it was theirs... is not a realistic way to convince anybody of your opinion.

Re:What system d really is

[Aighearach]

Odd that of all possible choices, systemd developers chose almost
always a way that is exactly the same or very similar to what Debian does.
For example, I don't see stuff like /etc/sysconfig, while I do see things
like /etc/hostname etc.

Everybody else has /etc/hostname too, sorry to pop your fanspiracy.

Let me quote from the
biggest myths:

Now, as it turns out, more frequently than not we actually adopted schemes
that where Debianisms, rather than Fedoraisms/Redhatisms as best supported
scheme by systemd. For example, systems running systemd now generally store
their hostname in /etc/hostname, something that used to be specific to Debian
and now is used across distributions.

Maybe the example was too subtle, but for sure there are some things from /etc/sysconfig that are gone from Red Hat, and are substituted by
Debian-style configuration.

Sorry, redhat has had /etc/hostname since the 90s. As for /etc/sysconfig, I have a systemd distro from the RedHat family, and it still has /etc/sysconfig too.

You quote the least important part of that passage, and I think it has a very different flavor when the whole thing is quoted:

One goal of systemd is to unify the dispersed Linux landscape a bit. We try to get rid of many of the more pointless differences of the various distributions in various areas of the core OS. As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration. This is never exclusive though, distributions can continue to deviate from that if they wish, however, if they end-up using the well-supported default their work becomes much easier and they might gain a feature or two. Now, as it turns out, more frequently than not we actually adopted schemes that where Debianisms, rather than Fedoraisms/Redhatisms as best supported scheme by systemd. For example, systems running systemd now generally store their hostname in /etc/hostname, something that used to be specific to Debian and now is used across distributions.

So "more frequently than not" isn't the same as "almost always," /etc/hostname was probably a clumsy example since RH already had that file, which is read as configuration by other programs, but not usually what is setting it. But the point is that they have an agenda of pushing towards consistent configuration, and to do that by setting defaults. Because those are often the easiest to standardize on. They don't go into the why. I would speculate that since RH is perceived as being behind systemd already, and Debian fans won't complain as much about Debianisms as RH-isms, it is simply more down-hill to standardize in that direction. Because where these differences exist, all the variants have been proven to work, so the difficulty of adoption is the more critical thing.

It certainly undercuts the RH-ism complaint, the only problem is that it is standardization that the complainers are against. They don't want the distros to get locked into having the same setup as each other. What really destroys the complaint though is that these are only defaults, not requirements. I would not be at all surprised if a future Debian wants to move away from the Debianisms because they're hated by users as RH-isms as soon as somebody says, "well we can't change it because it is standardized."

None of the involved parties are trying to make standardization required, and they're not trying to choose the best configuration system either. That is why it is going to be hard to stop them from improving defaults.

Sure, but why the kitchen sink?

[Giant Electronic Bra]

I have all sorts of high reliability services running on quite a few different servers, and I have plenty of them that will restart themselves, monitor their own crashrate and terminate completely if they crash N times in M minutes, etc. This is not rocket science and doesn't require to be built into PID 1 or something like that.

Frankly I think its a bad idea to create dependency chains onto huge complicated subsystems that often aren't appropriate, aren't needed, or are simply overkill.

And again

[Giant Electronic Bra]

This is forced on me when I don't need or want it for exactly what reason that you can explain? If I want binary logging there are already solutions, which you have JUST NAMED which work fine. I've no need or interest in having an init system that is too big for its britches foisting another one on me. Compartmentalization IS important.

Re:And again

[Peter H.S.]

This is forced on me when I don't need or want it for exactly what reason that you can explain? If I want binary logging there are already solutions, which you have JUST NAMED which work fine. I've no need or interest in having an init system that is too big for its britches foisting another one on me. Compartmentalization IS important.

Well, you can just use a non-systemd Linux distro like Slackware. It is a nice, stable and conservative distro. So nobody is forced to use systemd on Linux if they don't want to.

But if you want to use a systemd distro, it is no problem to _only_ have flat file text logs. Just configure journald not to make any log files and forward all messages to rsyslog.
systemd doesn't force you to use its binary log files at all, and you can still use rsyslog just the way you always had. This is all in the systemd documentation and man pages.

Personally I think the reaction against binary log files is based on a lack of actual analysis and lack of experience with them. The journal files is seriously good stuff for any admin.

Same with systemd; there is too much blatantly misinformation about systemd going on, with people rejecting it with weak and feeble arguments like "Unix Philosophy" etc. Trying to make a virtue out of the fact that SysVinit is crude, simple and lacks basic functionality, isn't going to convince people who have tried the advantages of systemd.

Sure, SysVinit is "simple", but only because it puts the burden and complexity on each and every program using it; daemonization, dropping privileges after getting a low number port etc. are all implemented in each and every user space program, instead of just having a single code base in init.

Having often complex executable config files where code and config statements are mixed, is simply a bad idea. Of course a daemon should be configured with structured text files like systemd uses. Using scripts for config files is just a madness that have been so normalized that the victims no longer recognize it as madness.

Re:And again

[Giant Electronic Bra]

There's NOTHING wrong with script files. As I've said elsewhere in this thread you are failing to understand good overall system design and factoring if you think a large complex program that incorporates every behavior into itself and puts only configuration options into files is 'superior'. A better solution would be individual scripts which can perform all the functions required for each service and coordinate with each other, with all the commonalities between them pulled out into shared library code. This allows for any level of flexibility and initialization strategy a packager or developer requires without forcing anyone to do anything and avoiding large disruptive changes in key subsystems.

I am really not interested in whether or not you understand the Unix way of doing things, but it is a real and highly beneficial approach which you might do well to actually understand. I don't have a big issue with a lot of the functionality that we're talking about here, though I think you are very much oversold on binary logging, but it doesn't all need to be bundled together in one package that is in any practical sense impossible to incorporate what you want from without being forced to swallow the whole thing.

And no, I'm not really being given a choice when the only option I have is something like Arch Linux, which no offense to its maintainers, is not something I'm going to run my bank on top of. Neither am I going to suddenly convert said operation to using systemd willingly. I've already had to deal with a lot of fallout from this stupid idea. I didn't have any problems before that needed this solution frankly and the changes ARE disruptive while we've noted zero practical benefit.

Re:And again

[Giant Electronic Bra]

There's NOTHING wrong with script files.

Using script files to setup and manage daemons because init is so primitive like SysVinit is, is simply a bad idea.

I'm sorry, but just saying "X is 'primitive'" isn't actually very useful. There is nothing primitive about scripts.

Also this isn't about SysVinit, this is about systemd. Picking at the one isn't an argument for the other. In fact SysVinit is pretty sophisticated in its own way, but its fine if we make it better or replace it with something BETTER. Again, just pointing out the problems with it isn't automatically enough to make systemd the correct alternative. I've pointed out negatives about the systemd approach, you need to address those.

Mixing executable code and declarative config statements like script based init systems do, is simply indefensible; it makes it hard to parse for both humans and machines.

There are two problems with this statement. First of all properly written init scripts ala RedHat put all their config in /etc/sysconfig, not mixed into any script. This is a perfectly easy practice that has been the state of the art for at least 10 years. Secondly blanket statements decreeing what is and isn't 'indefensible' are ridiculous. You need to make concrete arguments, I and many others are FAR past the point where any sort of decrees like this mean squat to us. There are many cases where basic invariant configuration elements are perfectly reasonably placed within a script. These are things that are not going to be changed in your installation but should be parameterized as good PROGRAMMING practice. Don't confuse those with configuration options that the system's user is going to want to change, they are very different things.

No one would ever design an init-system these days that didn't use pure text files for daemon config. SysVinit and similar are relics from a time when computing was done in a completely different way than today.

I am not trying to be disrespectful here for the pioneers that made various OS's back in the 1960's, 1970's and 1980's. It is just that some of the design choices they made, reflected the contemporary problems they had.

They made some simple but very flexible init systems based on shell scripts. But the simplicity just showed all kinds of problems over to the user space developer side, like handling dropping privileges when a daemon needed a low number port etc. And many people, including me, have long been of the opinion that such init-systems have been obsolete for years (if not decades). Most if not all certified Unix vendors have replaced their script based init systems (SMF and launchd are major inspiration init systems for systemd).

Horse Petunias. Computing hasn't fundamentally changed, and the same use cases that existed back in the mid 1980's when init systems in use today were birthed exist today. Believe me, I was there, and I know. A machine room today is solving the same problems that they were back then. Some of the technology is different and there are obviously some new things, but my 1980's Sun Unix machines ran pretty much like my Linux servers do today. If you want to tell me that a mobile phone is quite different from a mini-computer, well yes. However nobody is asserting that a mobile phone should be running the same init system as a web server, except the people making everything depend on systemd....

As I've said elsewhere in this thread you are failing to understand good overall system design and factoring if you think a large complex program that incorporates every behavior into itself and puts only configuration options into files is 'superior'.

I do think I understand enough about how OS's work to have a qualified opinion. We just happen to disagree about some things and is having a civilized exchange of arguments.

The core of systemd is certai

Re:And again

[Blaskowicz]

Maybe a problem is the scripts look like shit? especially as a not-so-advanced user will only see them when cat'ing them on the command line.
Outside this context nobody would even think of writing a program more than ten lines in bash or sh.

Why not implement the scripts in lua or whatever.

Re:And again

[Giant Electronic Bra]

Its just introducing another dependency. While I agree that shell scripts aren't the most elegant thing in existence and you could certainly write better ones in say Perl that would just mean that everyone would have to install an interpreter, just to boot their machine, and I think that wouldn't go over too well. Shells are unavoidable, so that dependency is pretty trivial.

Beyond that you can certainly write some perfectly nice shell scripts, and it should be possible to hide whatever ugliness there is with some more extensive libraries. Shell scripts allow for includes of packages of routines, and RedHat did a lot of work in that direction way back when. I guess they just had better things to do and it was never pushed to its limits. As I said before there are also /etc/sysinit scripts which are intended to contain ALL the user-settable configuration parameters for system services. Again, this hasn't been pushed hard, probably because its just not glamorous work.

Frankly I think if someone put their mind to it they could clean up the existing sysVinit process, init itself, build some libraries and establish some better conventions and you'd have 75% of the benefits of systemd without all the ruckus. The other 25% most people can probably live without and its not at all clear to me it belongs in the same project. Much of it could exist as stand-alone tools/libraries and some better conventions covering how to use cgroups and etc. That would IMHO have been a better approach.

exactly

[Giant Electronic Bra]

this is precisely the point. There's no need for a single giant monolithic product that tries to do every damned thing.

Unix Haters Guide Rebutall

[badkarmadayaccount]

I feel that systemd in general addresses weaknesses listed here: http://web.mit.edu/~simsong/ww... Along with Wayland, ZFS, etc. of course.

Proper factoring

[Giant Electronic Bra]

You have the factoring wrong on this sort of system design. You shouldn't have a monolithic controller implementing all these features. Instead you should have individual scripts that CAN do it any way they want, and then a large library of tools that properly implement all the things that people ACTUALLY want to do in a proper fashion. This allows incremental adoption, avoids dependency lock-in, and preserves flexibility and modularity. Instead of replacing init and trying to incorporate every possible feature in systemd and exposing them with configuration options what systemd SHOULD be is a set of functions that daemons can call and some wrappers that will let you compensate for or enhance whatever ill-behaving services already exist which can't simply be fixed up with changes to their init scripts.

As for security, that's an independent cross-cutting concern which is already handled by other tools. If there's a need for some command-line tools to expose some kernel functionality, or some libraries to do so, then that's one thing, but why is this grafted into the same tool that performs system startup? That's not good factoring.

We could have the same discussion WRT container support and other elements of systemd, most of which belong in completely seperate tools. If there needs to be additional framework around those different tools so they can do some new/better things then that should be done in the wider community so that we can have standards, not dumped on everyone as a fait acompli.

Re:Proper factoring

[Rich0]

If there needs to be additional framework around those different tools so they can do some new/better things then that should be done in the wider community so that we can have standards, not dumped on everyone as a fait acompli.

Nobody dumped anything on anybody. Systemd pushes their stuff to a repository, and your distro decided that they'd rather use it than continue to do things their own way, and you decided to keep using the distro rather than doing things your own way. Sysvinit is still out there, freely licensed. If you want to use it, then use it! :)

One more thing I don't like about systemd.

[james_in_denver]

If it has been so well thought out, then why isn't there a parameter available for each service that says "don't automatically restart this if it fails"?

There are times that services WILL fail, and should not be restarted until the underlying problem is fixed.

And that binary log file? absolutely ridiculous, why? so i have to learn a new tool to find out why a service stopped? When before all i had to do was check the last 20 or so lines of a text file.

Re:One more thing I don't like about systemd.

[psmears]

If it has been so well thought out, then why isn't there a parameter available for each service that says "don't automatically restart this if it fails"?

There is... and the default is (I believe) not to restart.

Why EBCDIC?

[satch89450]

Actually, EBCDIC was weird because it's tied so closely to 80-column Hollerith encoding. Back in those early days of BCDIC encoding (which pre-dated EBCDIC), conversion of card hole punches was done with actual wires, plus a few transistors (or tubes!). When the System/360 came along, the engineers used the same techniques to decode card column patterns "at speed". I learned this for myself when I had to write a driver for a minicomputer (GA SPC-16) to interpret the punches. I didn't have enough words to use a proper 4096-entry table, so I had to use the same tricks to do a 1-of-n selection of the digits field, and then use the three bits from that and combine with the five bits of zone field, and look up the correct value in a 256-character table. The generation of the punch solenoid pattern used the same table in reverse, saving space at the expense of CPU cycles. In a 16-bit machine with 32 users, space -- especially low memory space -- was at a premium.

http://en.wikipedia.org/wiki/EBCDIC

One advantage of doing the punch portion of the driver that way was that there was no way for anyone to cause the punch to generate "lace cards", like the earlier, clunkier driver did. Great way to destroy the card punch we were using, as the power supply in the external box was too small to drive ALL solenoids for ALL columns of a card, especially card after card. The Field Service people told stories of the damage they found at customer sites because of lace-card punching. The FS people were relieved when the new driver proved to prevent the problems.

As I recall, there was an "ASCII mode" in the decimal arithmetic instructions in the S/360 and follow-on systems so "zero and add packed" (ZAP) worked just fine in dealing with ASCII source data. The conversion of the sign was a bit of a problem, but most ASCII input didn't try to encode the number sign in the last character anyway.

Did you know that one of the early porting targets for Unix was a System/360 computer?

Re:What system d really is

[ISayWeOnlyToBePolite]

Yes, liking it, absolutely! Systemd-sysv (the package that installs systemd as init) installs are thru the roof, and so are votes for the package. Note the decline in sysvinit-core and its votes, it's an active choice. Voters agree with you that systemd-shim is not a good ide, it's dwarfed in the scale against systemd, so it's hard to estimate just how few they are. If anything, the discreapancy between systemd-shim installs and votes indicate that it's pulled in by dependencies without people noticing.