What about systemctl? It talks to systemd-the-PID1 via D-Bus method calls. That the system state is fused with the OS process state remains the case.

What, I answered your questions and that's all you've got? I mean, you've made a few basic mistakes here, like nothing reaps orphaned processes, only zombie processes. And launchd does actually parse plist files directly.

So much for your devastating rebuttal I guess :-) what's your point with dbus by the way? It's just a form of IPC, and uses a bus daemon to transfer the message. Are you implying that's a problem? If so, how?

Fine, I meant orphaned processes get reparented to it by default (unless a subreaper has been defined explicitly via prctl() flag). As for the launchd thing, I'll need to do further research.

Your implication that nspawn isn't for production use strikes me as quite odd. CoreOS based their Rocket platform on it (at least, initially - they might have swappable backends now).

That you expect interdependencies from an init system strikes me as more of a personal bias than anything else, given all the counterexamples - s6, nosh, perp, etc.

Your list of utility binaries that don't directly rely on PID1 is a false one. systemd-activate very much depends on systemd-as-PID1 to perform method call(s) on it, journalctl talks to journald which expects systemd as PID1, systemd-inhibit talks to logind which needs systemd-as-PID1, systemd-readahead is deprecated, systemd-analyze can't possibly work without a systemd PID1 to profile its Manager object, systemd-run needs it, so on and so forth...

I never made a claim that any of those binaries run as PID1... it's pretty obvious only one can be PID1. You're strawmanning too hard.

I haven't tested their claim, that it makes handwavy promises like "tries hard" makes me skeptical. This is hardly the only issue with journald though.

Where the hell did I say that "socket activation" (superservers, fd passing...) is without merit?

I'm pretty sure the escape from predefined service order comes from the dependency system and transaction reordering parts of systemd, not socket activation. Not directly, at least.

I never intended my rebuttal to be "devastating".

And of course, you never did respond to what a dynamic event is, or even my point right now that your assertion about system and process state being separate because systemctl exists is totally wrong... You also didn't respond to your dependency list being outdated, nor my rebuttal to your feature listing about udev devices, mounts, swaps, etc.

Ultimately, it seems like you have a vested interest in defending systemd. That's fine. If it serves you well, all power to you. That all arguments against systemd are misguided as you so boldly claim, is simply wrong.

EDIT: My point is your argument is completely nonsensical. How does controlling systemd from a utility program (like virtually every daemon) rebut my assertion about state?

Ah, the old "you must have a vested interest" argument. Good luck with that. You also haven't raised those counter examples till now.

I've responded to the dependency list being outdated - I asked you to provide me with a later dependency list. I still am - given you stated hundred of binaries, when there aren't I'm curious what you'll come up with!

nspawn isn't for production use, or so says Lennart Pottering, numerous times.

That list of binaries is what is included in Debian Sid unstable. It's not hundreds of binaries. Heck, I've even listed a deprecated one there. If you disagree, it's easy to disprove me: list them.

You quoted the commentary of someone who strongly disagrees with socket activation. I'd assumed you quoted it because you agree. You also asked me if I "even knew what it was", which I do :-)

There is one binary that runs PID 1. The original argument speaks of PID 1 as a key problem, which is the reason most folks don't like systemd.

By dynamic event I mean an event such as a hardware device starting a service, a timer event initialising a service, etc.

Your entanglement argument uses an example that is incorrect, I didn't make this up :-) that's your argument, not mine!

Not all arguments against systemd are misguided. When I first learned systemd ran as PID 1 for what I though was everything, I was concerned. Then I looked into it further and it was all piss and wind, so far as I'm concerned. The one that I find most conducive is binary logs, I'm not a fan. But that seems to be the only thing that even folks like Linus talk about. His real beef is that some of the devs were being dicks, which is really a very Gnome like mentality.

You read into their documentation. They phrase things badly, and those looking for it read into that which I'd not there - like your claims about syslog compatibility, which you can't seem to back up.

Any ctl program needs a way of signalling to the daemon to change its state. Systemd uses dbus: so? What's the issue you have with that?

Init doesn't reap zombied processes, by the way. The kernel does this. Init doesn't do re-parenting either, it just so happens that because it is PID 1 then it's what becomes the parent by default - unless you have a kernel > 3.4 and as you say the child reaper big is set on the parent process.

You seem to have a problem with a process running PID 1 handling dynamic events like hardware changes. I don't think you've given particularly strong reasons why.

Your entire argumentative style in this thread is a combination of reasonable points interspersed with straw men, putting stuff in your opponent's mouth, subtle distortions and willful omissions. I've had enough of it, so this will be my last reply.

I've responded to the dependency list being outdated - I asked you to provide me with a later dependency list. I still am - given you stated hundred of binaries, when there aren't I'm curious what you'll come up with!

Where did I say hundreds? I said -likely- reaching a hundred. Single.

There is no official count - the article you linked was written with a special purpose. Nonetheless, I took an i386 experimental deb for systemd-219 (https://packages.debian.org/experimental/i386/systemd/downlo...) and roughly counted 77. I'm not sure what build was actually run (number could be lower than total), and due to the quick unveiling of new interfaces, the number has been higher at one point. Things move fast at systemd, and the fact that you linked an article measuring 204 as evidence for the present shows you're simply out of touch.

nspawn isn't for production use, or so says Lennart Pottering, numerous times.

Well, then it seems everyone is violating that quite tremendously. CoreOS must be incompetent, I don't know.

It's not hundreds of binaries

Nowhere did I say such.

Your entanglement argument uses an example that is incorrect, I didn't make this up :-)

So the fact that systemd, the PID1 which handles both the system state and the OS process state at the same time, isn't true? Bullshit. Deliberately misreading me to push your agenda.

When I first learned systemd ran as PID 1 for what I though was everything, I was concerned. Then I looked into it further and it was all piss and wind, so far as I'm concerned.

Well, of course. systemd doesn't put everything into PID1. That you're picking to focus on this low fodder argument out of everything that has been said by more acquainted people is just disingenuous.

like your claims about syslog compatibility, which you can't seem to back up.

I never mentioned anything about compatibility with syslogd.

Any ctl program needs a way of signalling to the daemon to change its state. Systemd uses dbus: so? What's the issue you have with that?

Now, this, is a total non sequitur. As in, you completely and horrendously misread everything that I said and deliberately projected your own biases into it. This isn't worth responding to simply because it's based on your own odd incredulity.

Init doesn't reap zombied processes, by the way. The kernel does this. Init doesn't do re-parenting either...

Where the hell did I say any of this? I specifically mentioned they get reparented to init(8), and nothing about zombies. Once again, putting words in my mouth.

I've had enough of this nonsense.

Your entire argumentative style in this thread is a combination of reasonable points interspersed with straw men, putting stuff in your opponent's mouth, subtle distortions and willful omissions. I've had enough of it, so this will be my last reply.

I could characterise your responses the same way :-)

Where did I say hundreds? I said -likely- reaching a hundred. Single.

Even over one hundred is way off. There are now 76, I checked myself.

There is no official count - the article you linked was written with a special purpose. Nonetheless, I took an i386 experimental deb for systemd-219 (https://packages.debian.org/experimental/i386/systemd/downlo...) and roughly counted 77. I'm not sure what build was actually run (number could be lower than total), and due to the quick unveiling of new interfaces, the number has been higher at one point. Things move fast at systemd, and the fact that you linked an article measuring 204 as evidence for the present shows you're simply out of touch."

You were close: 76 binaries. Of which the new ones are some extra utilities. Things don't move that fast, and they haven't been increasing their scope - it's stayed pretty much the same as what it was at version 204. I currently have systemd v208 installed, but out of curiousity I checked what libaries it links to:

  0x0000000000000001 (NEEDED)             Shared library: [libsystemd-daemon.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libudev.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libselinux.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libwrap.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libpam.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libaudit.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libcap.so.2]
  0x0000000000000001 (NEEDED)             Shared library: [libkmod.so.2]
  0x0000000000000001 (NEEDED)             Shared library: [libdbus-1.so.3]
  0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
  0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

Then I checked systemd version 219 - exact same libaries.

nspawn isn't for production use, or so says Lennart Pottering, numerous times.

Well, then it seems everyone is violating that quite tremendously. CoreOS must be incompetent, I don't know.

By "everyone", you mean CoreOS, right? CoreOS contribute to systemd, they probably know what they are doing. The man page does say "systemd-nspawn - Spawn a namespace container for debugging, testing and building" and also "Note that even though these security precautions are taken. Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container." I'd certainly hope anyone who uses it in production had read the man page first. If not, yeah - must be incompetent.

So the fact that systemd, the PID1 which handles both the system state and the OS process state at the same time, isn't true?

Can't follow what you are trying to say here. systemd is not a proposition. Could you restate that?

That you're picking to focus on this low fodder argument out of everything that has been said by more acquainted people is just disingenuous.

"Your entire argumentative style in this thread is a combination of reasonable points interspersed with straw men, putting stuff in your opponent's mouth, subtle distortions and willful omissions."

I never mentioned anything about compatibility with syslogd.

Yeah, you did actually. You said "journald hijacks /dev/log and expects all syslogd implementations to conform to its own standard."

Now, this, is a total non sequitur. As in, you completely and horrendously misread everything that I said and deliberately projected your own biases into it. This isn't worth responding to simply because it's based on your own odd incredulity.

You wrote "For example, even Apple had the engineering sense to separate their launchd plist configuration parser from the launchd PID1 itself.", which is wrong and you admit that you need to look into this more closely. I mentioned systemctl thinking that you believed that launchctl parsed the configuration files for launchd and somehow launchd communicated with this to get the configuration info. Of course, I assumed that's what you thought - otherwise what was your point? systemctl also parses configuration info. Maybe I got the wrong end of the stick, but given you were wrong in the first place I'm not sure what point you were making now.

In this case, it's less that I deliberately misread you, it's more that you weren't very clear!

Init doesn't reap zombied processes, by the way. The kernel does this. Init doesn't do re-parenting either...

Where the hell did I say any of this? I specifically mentioned they get reparented to init(8), and nothing about zombies. Once again, putting words in my mouth.

In case you aren't following along: an orphaned process won't get reaped. You stated that "init(8)'s duties are reaping orphaned processes and handling high-level global system state at best (like SAK, shutdown, halt, etc.)". You probably meant that init reaps zombie processes - you can't reap an orphaned process, an orphaned process is still running and is reparented by the kernel to PID 1. init doesn't do this.

You were therefore wrong on two counts:

1. The kernel detects when a process is orphaned and reparents to PID 1, which just happens to be init. init doesn't actually do any reparenting, which is sort of key to your argument as you believe that init should be the process that reparents a process when it's parent dies.

2. An orphaned process doesn't get reaped, because it's still running. A zombie process is one that has exited but is still in the process table and the parent process hasn't reaped it yet. You don't seem to understand the difference between the two, so I explained it. I'm explaining it again.

I've had enough of this nonsense.

That's good to know, so have I :-)