2 ms·

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'

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?

chris_wot 12y ago
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.
- vezzy-fnord 12y ago
  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/download 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.

chris_wot 12y ago

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.

vezzy-fnord 12y ago
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/download 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.