The Debian init system general resolution returns
The Debian init system general resolution returns
Posted Oct 17, 2014 20:15 UTC (Fri) by mgb (guest, #3226)In reply to: The Debian init system general resolution returns by jspaleta
Parent article: The Debian init system general resolution returns
Bloating pid 1 with that D-Bus interface increases the attack surface and the lack of modularization makes it harder to improve Linux in future.
Therefore, this is yet another example of systemd's bad design.
QED
Posted Oct 17, 2014 20:56 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
Lets make sure we've concluded the on-topic argument before moving on to the off-topic one about the security implications of relying on dbus.
you admit that logind does not in fact depend on anything being running on pid=1 Right? And you rescind your previous criticism that GNOME or anything else which depends on the logind API for functionality is implicitly dependent on any particular init being pid=1 right? I'll just go ahead and assume you've answered yes to those questions and we'll move on safe in the knowledge that you previously stated issues about high level software relying on a specific codebase running as pid=1 have now been address.
So... reliance on dbus in pid=1 as a security risk over other available ipc mechanisms available. I do not share your opinion that having pid=1 rely on dbus for IPC is an inherent security weakness. I personally look forward to the day when kdbus is a standard piece of kit for every process to rely on for inter process communication from pid=1 to pid=infinity+1.
Anyways... for everyone who agrees with you about the implications of relying on dbus in pid=1, then sysvinit with shim and cgmanager should work for you to keep logind for higher level bits of to rely on for now. You and those who agree with your opinion would of course be better off replacing shim with a fully independently developed codebase that implements the stable systemd dbus API.
As shim is just a fork of systemd and I don't see that being sustainable long term because users of that fork will be continually fighting against implementation decisions they don't agree with in the mainline codebase. That's not where you want to be.
Better to start fresh and build the implementation that works more consistently with your world view about the security risk of dbus. I've sort of hinted at extending runit with a helper to talk systemd APIs, as a way forward for you and people who share your opinion about the security of dbus while still keeping logind working. runit is in my estimation the best choice for you moving forward, as even upstart suffers from your perceived dbus over-reliance so you shouldn't even bother with resurrecting and extending it. The point being, logind will still operate as long as your independently developed service implementation running pid!=1 as long as it speaks the expected documented APIs logind expects to see.
-jef
Posted Oct 17, 2014 21:00 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (3 responses)
Posted Oct 17, 2014 21:02 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
-jef
Posted Oct 17, 2014 21:13 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
A few. To be precise, two .c and three .h files (out of the total of sixteen files comprising the C source code), which contain rather generic helper functions and look to be rather extensively pruned compared to wherever in systemd they came from, too. This really, really isn't a "fork of systemd" by any reasonable definition of the phrase.
Posted Oct 17, 2014 22:06 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link]
Either way I hope debian is able to sustain it and cgmanager, even if Canonical looses interest in maintaining either with staffed manpower. As clearly these two codebases are going to be critical if Debian is serious about multi-init support. GNOME might be today's firefight..but this is just a prelude to the much more difficult discussion concerning container support and the cgroup management question bound up in that. And containers go right to the heart of Debian's relevance in the server workloads and a much more interesting issue for the project long term I think. But I digress.
-jef
Posted Oct 17, 2014 21:10 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (124 responses)
It is reasonable to put cgroup management – which is what logind needs from systemd – into PID 1 because otherwise whichever external service is used to manage cgroups can't be managed by PID 1 like other services in the system are managed. This leads to nasty special cases in the code and increases the probability of bugs. It becomes a chicken-and-egg problem. The systemd documentation explains this in more detail here.
Many other things that systemd handles in PID 1 do make considerable engineering sense, too. For example, the fact that in traditional sysvinit, PID 1 has no idea what its child processes are and hence, how to restart a service that it notices has crashed is a glaring design flaw. Calling systemd badly designed because it fixes this obvious problem (among other things) isn't exactly logical.
Posted Oct 17, 2014 21:26 UTC (Fri)
by ctpm (guest, #35884)
[Link] (123 responses)
Why the heck should the init system restart failed crashed processes? Who restarts init if it crashes? A trained monkey?
If your daemon suffers from that, it should provide an overseer process. Or _you_ should use a configuration management/monitoring daemon, for which there are many to choose from today.
Your solution is to bloat PID 1 with more mechanism and more policy, knowing there's a kernel panic if it crashes? That would be a glaring design flaw, yes.
Init is engineered correctly as it is.
Posted Oct 17, 2014 22:34 UTC (Fri)
by jonabbey (guest, #2736)
[Link]
Posted Oct 17, 2014 22:41 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
This script was shipped in a major Debian release and it's not like BIND is some kind of obscure daemon that nobody uses. So "better testing" is not an answer.
Posted Oct 17, 2014 23:21 UTC (Fri)
by ctpm (guest, #35884)
[Link] (1 responses)
Posted Oct 20, 2014 0:06 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 18, 2014 0:05 UTC (Sat)
by nowster (subscriber, #67)
[Link] (15 responses)
Posted Oct 18, 2014 0:57 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
The worst bug is at line 92 - if for some reason BIND becomes unresponsive during the shutdown then this loop will go on indefinitely. Halting the shutdown process.
That has happened to me during a maintenance server reboot and required me to go at night to our datacenter and power-cycle the machine.
Systemd has timeout logic built-in and it can also reliably kill services.
Posted Oct 18, 2014 1:26 UTC (Sat)
by misc (subscriber, #73730)
[Link]
I am also not 100% on how the initscript would react with a chroot or a docker file, with named running inside the chroot and outside, due to pgrep likely seeing all processes.
I am personnally unsure of why this test the OS to be solaris. And I am not really sure that ignoring errors silently is the right thing to do ( like the chown line 52 ), and the check network seems a bit strange.
Posted Oct 19, 2014 23:17 UTC (Sun)
by simoncion (guest, #41674)
[Link] (7 responses)
start-stop-daemon --stop --retry 10 --pidfile $PIDFILE --exec /usr/sbin/named
There's so much wrong with how that guy is trying to stop BIND. He's already using daemontools. Take advantage of the tools that it gives you.
Go look at how Gentoo does it. http://pastebin.ca/2861076 (That pastebin expires in two months.)
Posted Oct 19, 2014 23:42 UTC (Sun)
by ABCD (subscriber, #53650)
[Link] (1 responses)
Posted Oct 20, 2014 22:09 UTC (Mon)
by simoncion (guest, #41674)
[Link]
Posted Oct 20, 2014 0:11 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
It'd be actually interesting to write a completely correct race-free init script that explicitly supports all the systemd's features. I suspect that it's close to impossible.
Posted Oct 20, 2014 22:27 UTC (Mon)
by simoncion (guest, #41674)
[Link] (3 responses)
Posted Oct 20, 2014 23:06 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (1 responses)
See systemd.service(5). The “ExecReload=” key lets you specify a sequence of commands. If one command fails then the remaining commands will not be executed, but the service will be kept running.
Posted Oct 21, 2014 9:08 UTC (Tue)
by cortana (subscriber, #24596)
[Link]
Posted Oct 21, 2014 5:56 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Running checkconf is supported by ExecReload. Running inside a namespace is supported out-of-box by simply doing this:
Gentoo's script is still racy - and there's no way to un-race it.
The reload action is asynchronous, because it uses a signal ('rndc reload' should be used instead).
And seriously, using 'fuser' to check if all processes have exited? Is it really real?? It's like these folks haven't heard about cgroups.
> 2) You want an init script to handle SELinux labeling and policy enforcement? Do I misunderstand you? If I don't, how, exactly, would that work?
You need to sanitize the SELinux environment to avoid passing user's labels.
Posted Oct 18, 2014 14:16 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
In systemd a configuration file is... just a configuration file.
I think that's a very nice piece of simplification. But doubtless if you're inclined to see beauty in every nasty sharp corner of sysvint you'd argue that a configuration file is exactly the right place to run arbitrary code as root...
Posted Oct 18, 2014 14:30 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (3 responses)
It is funny how people keep complaining about the purportedly large “attack surface” of systemd while at the same time not seeming to mind that large swathes of the traditional setup basically amount to shell scripts being run with root permissions. In particular, many Linux distributions use bash as the default shell, and anybody who has recently been following security news should have been reminded that bash isn't the most secure piece of software around.
In that sense, systemd's attempt to dispense with the shell to as great an extent as possible does not seem to be entirely misplaced. The various binaries within systemd that take part in the boot process, for example, are generally small enough to be individually audited, and as such their potential to reduce a system's attack surface is considerable compared to the status quo.
Posted Oct 21, 2014 18:00 UTC (Tue)
by nix (subscriber, #2304)
[Link] (2 responses)
Meanwhile, the APIs systemd exposes are, IIRC, exposed to *everyone*. One hole in the libdbus permissions checking -- tested, sure, but much less tested than the battle-hardened kernel fs permissions code -- and systemd is suddenly much more exposed than that.
(Is this point *really* not immediately obvious?)
Posted Oct 21, 2014 18:22 UTC (Tue)
by JGR (subscriber, #93631)
[Link] (1 responses)
The problem is not modifying the shell scripts themselves, but that the attack surface comprises the shell script, the shell itself, and all the various other scripts, executables, etc. which get invoked in the script.
Posted Nov 2, 2014 14:57 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Oct 18, 2014 1:40 UTC (Sat)
by misc (subscriber, #73730)
[Link] (71 responses)
So yeah, maybe your employer do not have such policy and do not care about restarting crashed processes, but there is a lot that care enough to have spawned a industry around the whole idea of supervision and first level handling.
Posted Oct 18, 2014 3:07 UTC (Sat)
by mgb (guest, #3226)
[Link] (70 responses)
Anything more complex requires active monitoring and intelligent response. Systemd handles a trivial corner case by restarting a dead daemon but does nothing for the more common cases of resource exhaustion, process hangs, disk failures, configuration errors, and network outages.
Systemd bloats pid 1, increases attack surface, makes Linux much harder to improve in future, and provides only trivial benefits in return.
A case can certainly be made for a better init, but systemd is not it.
Posted Oct 18, 2014 3:35 UTC (Sat)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Oct 18, 2014 3:51 UTC (Sat)
by mgb (guest, #3226)
[Link] (1 responses)
Posted Oct 18, 2014 4:08 UTC (Sat)
by raven667 (subscriber, #5198)
[Link]
Posted Oct 18, 2014 5:53 UTC (Sat)
by misc (subscriber, #73730)
[Link] (55 responses)
Now, as you were already explained, systemd do more than inittab since it will log the restart and it will not restart if something is restarting too often.
As a side note, I also think that repeating the same thing over and over do not really help to make your case. People do usually understand the first time, and it personnally only increase my perception that some of the most vocal critics of systemd do seems to have a problem ( which is sad, because this prevent more reasonable people problem to be taken in account by the fact they are less visible under the flood of message ).
Now, maybe you speak of the the code that listen to socket, who is small enough to be audited and was audited. The majority of problem would occurs in a parser, and that's offloaded to the started daemon. Not that there is no problem ever but again, this bring features and I think people see them worthwhile, as seen on the first article on systemd.
Now, the whole idea of making Linux harder to improve in the future is laughable, wrong and wouldn't make sense if it was not wrong. I mean, you seriously suggest to prevent innovation now just to permit someone to innovate later, something that didn't seems to happen that much in the previous years ?
If we were able to change everything in the past few years ( like redoing kde/gnome, moving to wayland, using kms, splitting xorg in smaller tarball, moving from static /dev to devfs to udev, consolekit, hal, pulseaudio, alsa, oss ), I do not see what would prevent replacing systemd one day. You keep repeating it, but you do not give anything concrete, just hand waving. As we have source code for lots of stuff, there isn't much that would prevent anything.
And for trivial benefits, it is sad that it doesn't bring you anything, but it do bring benefits for others. That you only care about you is ok, luckily, not all people are like you.
Posted Oct 18, 2014 6:09 UTC (Sat)
by mchapman (subscriber, #66589)
[Link] (49 responses)
systemd does have "runlevels"... they're just named instead of numbered. :-)
It would be fairly straight-forward to have each service unit generated from inittab depend upon the appropriate systemd target unit.
> Now, as you were already explained, systemd do more than inittab since it will log the restart and it will not restart if something is restarting too often.
To be fair, sysvinit has the latter behaviour as well.
I've always wondered why systemd's lack of built-in inittab support is such a huge problem. systemd isn't the first init system to lack inittab support: Upstart has no support for inittab services either. Neither sysvinit nor Upstart even support initscripts natively; there's always some kind of shell wrapper to negotiate which services should be started or stopped on a runlevel change.
So arguing about feature parity across init systems is kind of silly, even without bringing systemd into the picture. Different init systems simply have different features. There's no a priori reason they *should* all be the same.
Posted Oct 18, 2014 13:52 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
And the numbers still work. I use them out of habit still.
Posted Oct 21, 2014 18:03 UTC (Tue)
by nix (subscriber, #2304)
[Link] (47 responses)
Posted Oct 21, 2014 18:47 UTC (Tue)
by mgb (guest, #3226)
[Link] (46 responses)
All but one of our systems - that includes desktops, laptops, servers, and VPSs - have one or more inittab entries in addition to those supplied by the distro.
There is no point in creating an initscript in those cases where inittab already does exactly what is needed.
This reminds me of Poettering's surprise when sound drivers in the real world were not as he had imagined either.
Posted Oct 21, 2014 19:28 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (5 responses)
I'm not discounting the idea that people have a customized inittab. But I am seriously skeptical that there is a functional situation in the wild where inittab semantics is more capable of expressing the desired action than what systemd unit semantics are able to provide.
If you simply don't want to learn a new system. Fine. I can respect that. I'll let you continue to use like and prefer inittab, just as long as you let me like an prefer 8-track cassettes. But please don't continue to express an expectation that factory installed default options will continue to support your preference. I've given up on getting an 8-track cassette player installed years ago.
-jef
Posted Oct 21, 2014 19:45 UTC (Tue)
by mgb (guest, #3226)
[Link] (4 responses)
You are at liberty to replicate an inittab function with a Turing machine if you wish.
F/LOSS and Debian are about choice. They are not about RH using EEE to force us to use the wrong tool for the job.
Posted Oct 21, 2014 20:32 UTC (Tue)
by louie (guest, #3285)
[Link] (1 responses)
Posted Nov 18, 2014 17:26 UTC (Tue)
by blujay (guest, #39961)
[Link]
Posted Oct 21, 2014 22:24 UTC (Tue)
by rodgerd (guest, #58896)
[Link] (1 responses)
Posted Oct 22, 2014 12:27 UTC (Wed)
by micka (subscriber, #38720)
[Link]
_But they do the work themselves_!
Posted Oct 21, 2014 19:39 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (39 responses)
More power to you. So keep using sysvinit.
In the unlikely event that you'd ever want to move to systemd, it's a pretty trivial exercise to come up with a systemd unit file corresponding to an inittab entry. If your /etc/inittab has a line like
From a maintenance POV, this setup has the additional benefit that you don't have to fix your configuration by hand like you need to when your distribution installs a new version of the /etc/inittab file.
Posted Oct 21, 2014 20:03 UTC (Tue)
by mgb (guest, #3226)
[Link] (38 responses)
sysvinit has provided respawn rate-limiting for as long as I can remember.
> additional benefit that you don't have to fix your configuration by hand like you need to when your distribution installs a new version
inittabs are updated by the configuration management system.
//
There may well be situations where systemd is the right tool for the job. The problem is RH using EEE to preclude us from using the right tool for the job when that tool is not systemd.
Posted Oct 21, 2014 21:26 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (37 responses)
Sort of. Sysvinit's rate limiting is hard-coded and not configurable – it's great if its fixed parameters suit your application but it sucks if they don't. Systemd gives you a lot more control.
In general, systemd lets you do many more things out of the box that would be a hassle to configure with sysvinit.
With sysvinit, there is a completely arbitrary and superfluous distinction between services started from inittab and services started by init scripts. This is one of sysvinit's various design flaws. Systemd, on the other hand, treats all services the same regardless of how they're started. This makes life easier for admins and people who are learning or teaching how the system works.
You still need to reconcile your tweaks with whatever changes to the base configuration file the distribution makes from one version to the next. With systemd this is a complete non-issue since the distribution's base configuration files and one's own local changes are cleanly separated by design. (/etc/inittab is a reasonably simple file but the issue is worse with init scripts.)
Posted Oct 21, 2014 21:30 UTC (Tue)
by mgb (guest, #3226)
[Link] (36 responses)
You are not welcome to force other people to use systemd where it is the wrong tool for the job.
Posted Oct 21, 2014 21:34 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (19 responses)
And by that logic, when an application or framework developer thinks the systemd APIs are the right tool for the job, they have the freedom to choose to support those APIs without being forced to support other less optimal APIs.
-jef
Posted Oct 21, 2014 21:48 UTC (Tue)
by mgb (guest, #3226)
[Link] (18 responses)
And Debian has the freedom not to include software which violates Debian's policies.
Posted Oct 21, 2014 22:06 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (17 responses)
And in point of fact.. up until very recently sysvinit was the _only_ forced init in debian due to its essential nature:
http://www.vitavonni.de/blog/201410/2014102101-avoiding-s...
So even without the GR in place to coerce or mandate, maintainers have already been working to make it easier for everyone involved in Debian to have more "choice" and to agree to disagree as to watch choices are best.
Makes me wonder... Why was it okay to mandate sysvinit as essential prior releases? if this is really about choice...why weren't the choice proponents making the case back then that sysvinit as essential was taking choice away? Where were the proponents champion the choice to run a system on runit or minit without having sysvinit installed at all on the system?
The GR solves nothing, addresses nothing. Even if it passes, sysvinit compatibility in the future when uselessd becomes available as a packaged alternative to systemd.
-jef
Posted Oct 21, 2014 22:31 UTC (Tue)
by mgb (guest, #3226)
[Link] (16 responses)
Debian's "Essential: yes" package attribute does not mean what you think it does.
Thanks to modular design, Debian Wheezy supports numerous tools in this space including daemontools, filerc, openrc, runit, systemd, sysvinit, and upstart.
The problem comes now that RH deliberately breaks existing software so that it no longer works without systemd.
Posted Oct 21, 2014 23:06 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
For the record, “Essential: yes” means that the package can't be removed with the package management tools (without a special command line option to dpkg, anyway).
Please name a package in Debian that has been “deliberately broken so that it no longer works without systemd.“
Posted Oct 21, 2014 23:25 UTC (Tue)
by pizza (subscriber, #46)
[Link] (14 responses)
Whether or not you have any valid points...this is *not* one of them.
FYI, Your "existing software" will continue to work as well now as it did the moment you first installed it. If you *chose* to install a newer version of said software, then guess what? It isn't "existing software" any longer; it is "new software", usually developed by independent third parties, which may have new features, along with new prerequisites to support those features.
You've even conceded this point elsewhere in this thread, so I can only wonder why you keep bringing it up. Your insistence on harping on something demonstrably false only hurts your credibility and any legitimate arguments you may have. I respectfully suggest you drop it.
Posted Oct 22, 2014 1:16 UTC (Wed)
by mgb (guest, #3226)
[Link] (13 responses)
Debian is deciding whether to include in Jessie software which has been deliberately crippled to only work with systemd.
RH cannot force Debian to distribute broken software.
Posted Oct 22, 2014 1:19 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (9 responses)
Posted Oct 22, 2014 4:44 UTC (Wed)
by dlang (guest, #313)
[Link] (8 responses)
Posted Oct 22, 2014 5:28 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (7 responses)
But I'd be a little more nuanced than that. Its the dependence on the logind API specifically. There are other systemd provided APIs like hostnamed and friends which have not be controversial as they were easily re-implementable as small tools outside the systemd codebase. But there was a real question as to whether or not the existing -shim was going to gain support logind in time to matter for jessie.
Now with -shim supporting logind API that original concern has been taken care of. So credit where credit is due. The work to bring logind API support to -shim should be applauded as it definitely is going to benefit Debian users who desire to update systems to jessie and transition to systemd more slowly.
Moving forward I expect the next pain point is going to be the GNOME concept of app containers which will be using systemd APIs. But I don't have a good feel for the shape of that battleground yet. cgmanager does exist now so its not as dire. Maybe there might have to be an API translation layer to connect systemd API to cgmanager API, but not nearly as scary as the logind situation before -shim gained gained support for logind using cgmanager in the background.
Then in the longer term, kdbus is going to be a big problem... because nobody outside of systemd dev is looking to implement a userspace side to support kdbus. I fully expect GNOME to start making use of kdbus as soon as it goes mainline. And unlike for what happend for -shim, I'm not sure Debian can rely on Canonical/Ubuntu to help lead an alternative to systemd's implementation. If Ubuntu fully transitions over to systemd before kdbus is merged in the kernel mainline (and that seems likely) then there's no obvious candidate to do the work to provide the alternative implementation.
-jef
Posted Oct 22, 2014 5:37 UTC (Wed)
by dlang (guest, #313)
[Link] (2 responses)
Therefor fearing that such software may be created in the future is not someone being a fearmonger or being deceitful, instead it's someone expecting that what was done before will be done again.
If Gnome no longer requires systemd, that's a good thing. It's also what the response should have been in the first place rather than taking the attitude that doing anything other than forcing everyone to switch to systemd was putting an unreasonable burden on Gnome.
Posted Oct 22, 2014 5:59 UTC (Wed)
by mchapman (subscriber, #66589)
[Link]
To be fair, it never really *required* systemd. It can make use of a particular D-Bus interface that systemd provides, but it doesn't care one iota whether that interface happens to be provided by some other project instead. So it's probably wrong to think of Gnome as having undergone change -- what has happened is that the environment "around" GNOME has changed: there is now more than one implementation of this interface. And that most certainly is a good thing!
Posted Oct 22, 2014 6:27 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
GNOME is still technically depending on exactly the same thing it did 6 months ago. systemd-logind is still the only implementation of logind's API. -shim just now implements the systemd APIs that systemd-logind is using.
So again its more nuanced. If GNOME upstream or GNOME debian maintainers had waited for a second implementation to exist before depending on an API, would a second implementation ever been made? Or is it because GNOME upstream pushed ahead and the distro maintainers integrated the new upstream code, that created the need for the alternative implementation that caused it to be created? The need being the mother of invention and all that.
I think the historic Debian transition to use hal is instructive: https://lists.debian.org/debian-user/2009/09/msg00915.html
then the application incompatibilities transitioning from hal to udev in wheezy:
Call me a greybeard..but it sure seems like kids these days seem to have a poor grasp on how Debian has handled major userspace plumbing historicly.
The transition to hal and then to udev both introduced incompatibilities and there was never a requirement that multiple implementations be expected to work seamlessly as alternatives of each other. What mattered was a plan to get from old default to new default.
And so it should be with the transition for new default init. Regardless of changes in the API.
-shim is an important piece to aid the transition to the new default init. But to hold the idea of init diversity as something sacrosanct after years and years of previous Debian project experience transitioning plumbing in a more focused linear manner is.. smirkable.
No matter how this all shakes out sysinit is going to join HAL and devfs in the software retirement home. It's just a matter of time.
-jef
Posted Oct 22, 2014 8:29 UTC (Wed)
by johannbg (guest, #65743)
[Link] (3 responses)
I would take that "support" with a very and I mean very much grain of salt.
systemd-shim package is a futile attempt since the goal that it has to aim for, keeps moving around. There are no stability promises on a core functionality logind uses and as a result of that has left systemd-shim broken for months before and will do so again each and everytime it's (afaik sole ) maintainer Steve Langasek has to play catchup with upstream changes.
Now as it's name indicated requires you to still have systemd installed so the Debian community has the choice of using a) An component which is busy chasing rainbows and developed/maintained by single individual or b) Use systemd with logind and all the other bells and whistle systemd provides which is backup by Tollef Fog Heen, Michael Biebl, Marco d'Itri, Michael Stapelberg, Sjoerd Simon and the entire upstream systemd community.
Now let's return to the core of the matter, the work required by the Debian, ( as well as Gentoo,Slackware and whomever intents to support multiple and or use alternative init system than systemd whatever they may be called uselessd,openrc,sysvinit etc in the long run ) community has to come up with ( and the systembsd maintainer bumped into as well and significantly slowed down the development or grounded his development to halt entirely ).
In *addition* having to carry downstream compatibility patches for all upstream components that have decided to integrate/use what systemd provides them with *beside* logind and the added load on the service support community ( help,qa,releng etc ) and it's maintainers that will bring, they will need to write and thus provide a daemon that provides the external, supported, and guaranteed stable "login" API, an daemon that maps the "login" API to the non-portable operating-system-specific underpinnings which is an hefty chunk of development work.
You cant workaround this problem in apt through some dependency/resolving magic and you wont achieve this with something like systemd-shim or have it magically appear by whining about it on mailing lists, in forum, and various comment sections or by continually coming up with GR's and the likes, you actually need to get your hands dirty and start doing that hefty coding period.
Ian and his followers are doing pretty good job disrupting the Debian community from doing what needs to be done to make Jessie the most awesome release ever ( integrate it to the best of it's ability to systemd. I've been midst in this integration work myself and I know how much it pains users have things half integrated, half migrated and thus half working ) and ensuring Jessie will become the worst release ever by having no init working reliably since him and his followers are not coming up with components and the code necessary to do so.
I just sincerely hope for the sake of Debian that the DD will vote for Luca Falavigna proposal ( Choice 3 ) which will put this power into the hands of the maintainers themselves since I know quite few of them know the reality for what it is but have chosen to keep themselves outside any ( systemd ) discussion and mud sliding.
Posted Oct 22, 2014 15:40 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
point of information. I think ryan lortie is primary committer upstream.
both U and D bzr packaging systems suck in the upstream releases from ryan and seem to be point to http://people.gnome.org/~desrt/ as the source
Ryan seems to be using github primarily, but not github's release tagging mechanism, so the tarballs in http://people.gnome.org/~desrt/ are probably the canonical upstream release source.
Steve is acting primarily in the role of distribution packaging maintainer I think. And Martin Pitt is committing at both the distro and upstream levels.
Anyways... Ryan had a lovely blog post back in Feb, which I believe concurs with your assessment of the difficulty of using -shim to mimic the full systemd API. I think he draws different conclusions than you do from that. Considering what Ryan posted in Feb, I'm actually surprised that they got -shim updated to support logind. His post implied to me that it wasn't going to be attempted.
Seems -shim grew all the necessary cgroups stuff since september looking at ryan's github for -shim.
-jef
Posted Oct 22, 2014 17:45 UTC (Wed)
by johannbg (guest, #65743)
[Link] (1 responses)
Which happens to be one area him and or him and Martin will be constantly playing catchup with systemd.
I would not be surprised if they will only continue to maintain it until unity/ubuntu catches up with systemd and at that point they loose interest.
In anycase bottom line still remains the same if people want to ( continue to ) use alternate init system(s), be it single or plural instead of systemd in the name of choice or disgust towards systemd, individual members of the systemd community or the systemd community in whole, those individuals *will* have to code up/beef up those existing init system ( or write one from scratch ) to be somewhat on par with systemd. Once they have achieved that then they will have to convince wide variety of upstreams that currently use systemd to support that and or integrate it with their alternative.
Posted Oct 22, 2014 18:27 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
What I don't really have my head around is what the plan is for updating systemd in either U or D and how conservative the systemd packaging updating is going to be. Both could basically peg systemd to a specific upstream version and skip some upstream releases in an effort to lower the risk of creating an API delta that -shim will have to keep up with.
I expect work on -shim compatibility to be bursty...and only happen for upstream versions of systemd that land in Ubuntu pre-release packaging, even if systemd versions roll into Debian unstable/experimental on a more regular fashion thanks to the effort of the systemd debian maintenance team. So I expect to see a delta to build up in the Debian unstable/experimental repo just to the differences in available attention and interest in tracking upstream systemd.
I'm willing to see this admitted low expectation on -shim work to be surpassed and I'll take any well deserved lumps for discounting the commitment of the people working on -shim if they are able to keep the delta between -shim and systemd API coverage low without another 4+ month lapse in -shim activity.
-jef
Posted Oct 22, 2014 1:29 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
Proponents of the GR have stipulated in the ongoing discussion on -vote that there is no current issue in jessie currently which the outcome of this GR would impact.
Also they have explicitly stipulated that any RC bugs which are created due to the mandates of this GR for a yet to be found issue that -shim doesn't adequately handle, such RC bugs would be treated by the release team as jessie-ignore.
Do I need to provide citations to the ongoing discussion for these facts?
In very fundamental ways this GR is explicitly _not_ about fixing any perceived brokenness in jessie release. As there is no perceived brokenness in the jessie release.
Which is why the timing of this is a bit of a head scratcher. This could have waited for post jessie freeze.
-jef
Posted Oct 22, 2014 1:53 UTC (Wed)
by mgb (guest, #3226)
[Link] (1 responses)
Furthermore he said that ignoring such bugs is but one possible course of action. He did not say that the release team would ignore such bugs. Other possible courses of action include fixing the bugs and omitting Gnome from Jessie.
Posted Oct 22, 2014 4:38 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
The proposed GR text was amended by Ian after discussion concerning the impact on jesse. The amended GR text that exists right now stipulates that the expectation the release team with ignore RC bugs generated if the proposed GR passes for the express purpose of avoiding blockers on jessie release.
Citations:
Posted Oct 21, 2014 21:48 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (15 responses)
At the risk of sounding like a broken record, nobody is “forcing“ anyone to use systemd. Sysvinit isn't going away as long as there are people willing to put in the work to keep it around.
Posted Oct 21, 2014 21:56 UTC (Tue)
by mgb (guest, #3226)
[Link] (14 responses)
Posted Oct 21, 2014 22:03 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (13 responses)
Exactly which Debian packages in jessie force you to run systemd as PID 1?
(Other than systemd-sysv, that is.)
Posted Oct 23, 2014 3:37 UTC (Thu)
by xz (guest, #86176)
[Link] (12 responses)
network-manager
Here is another more complete graph generated by debtree for packages with hard dependecy on systemd: http://i.imgur.com/5MchQde.png
Posted Oct 23, 2014 6:56 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
For example: https://packages.debian.org/jessie/lighttpd has a dependency on systemd or lsb-base. Systemd is not mandated at all.
Posted Oct 24, 2014 1:05 UTC (Fri)
by xz (guest, #86176)
[Link] (10 responses)
The list I provided can be manually verified and they require systemd (via libpam-systemd or not). The fact that user applications far downstream start having hard dependency on systemd shows the dependency land grabbing scheme in the work.
Thanks for the catch on lighttpd though. That was because debtree doesn't have a good way to deal with alternative dependencies (`apt-cache -i rdepends systemd` doesn't show lighttpd as an alternative reverse dependency). I had to manually weed out many irrelevant packages, like -dbg, -plugins, -mod packages, and I skipped many of gnome packages for the sake of showing the effect on non-gnome users. It is certain there could be some errors. Large part of the result is valid.
Here, I patched debtree to ignore all alternative dependencies. The updated graph is largely unchanged: http://i.imgur.com/SxufNQ2.png . Error reports are welcome.
Posted Oct 24, 2014 1:20 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
Anyway, it still doesn't hard-depend on systemd. Libpam-systemd can work just fine with systemd-shim: https://packages.debian.org/jessie/libpam-systemd
Posted Oct 24, 2014 2:00 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
Moreover, libpam-systemd can work "perfectly well" -- as a no-op -- on systems that don't have any logind implementation at all. Looking at its code, it simply appears to check whether /run/systemd/seats/ exists, exiting successfully if it doesn't. Curiously, on Debian this check is patched out...
Posted Oct 24, 2014 2:32 UTC (Fri)
by xz (guest, #86176)
[Link] (7 responses)
Tell me, how do you install libpam-systemd without systemd? I'm sure you have reason for libpam-systemd to be technically optional, but why does it have a hard dependency on systemd? Is it a bug?
libpam-systemd itself is NOT optional if you happen to be one of the users of the packages I listed above. I listed hard reverse dependencies above to demonstrate which users will have to use systemd because of (reverse) dependencies. If everything depends on libpam-systemd but you're not using anything, I guess you can still have the truism of libpam-systemd being optional.
Posted Oct 24, 2014 2:39 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
libpam-systemd ( https://packages.debian.org/jessie/libpam-systemd ) has the following dependency:
>dep: systemd-sysv
So yes, systemd is optional and not required in Jessie.
Posted Oct 24, 2014 2:41 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
That's incorrect, libpam-systemd simply needs some files packaged in the systemd package. It doesn't require it running.
To actually activate systemd on Debian one needs to install the systemd-sysvinit package (or manually specify it in the kernel command line).
Posted Oct 24, 2014 3:38 UTC (Fri)
by xz (guest, #86176)
[Link] (4 responses)
Is the package designed for being installed without being used? No.
As Chapman pointed out, libpam-systemd is explicit patched in Debian to start logind on demand. Therefore libpam-systemd depends on and actively uses an integral component of systemd. If it is really as simple as using some files from the systemd package, why not put those files into libpam-systemd?
Or are you changing the definition of systemd? logind is not systemd! I know systemd the word can mean a lot of things.
P.S. who on earth think it is a good idea to start daemons from deep inside a library "on demand"?
Posted Oct 24, 2014 3:59 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
The first requires coding to fix, the second just requires packaging changes.
Since the systemd advocates have less than zero interest is supporting anyone not using systemd, it's not at all surprising that the packaging of the software drags in extra stuff
After all, it's the advocates who become package maintainers, they are interested in making that package work, not in supporting other packages working without their favourite software. It takes extremely mature maintainers to support that level of compatibility. This isn't the dig against systemd maintainers that it may sound like, _very_ few packages have maintainers or project leads that think about how people who don't use their whole package should be supported, either by breaking out components that are useful to others, or in terms of how users will be able to migrate cleanly away from the software.
Posted Oct 24, 2014 9:44 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
Packaging software pretty much always involves tradeoffs.
It would probably be possible to divide the “systemd” package on Debian into a number of packages that split out library support, etc. However, given that systemd is the designated default init system for Debian, we can reasonably expect that in the future a majority of Debian systems will run systemd. This means that for most users, splitting systemd into a number of packages that will all be installed doesn't really add value – it mostly makes extra work for the package maintainers and increases the probability of bugs.
For those who don't run systemd as PID 1 but still need the package installed for the libraries, a few extra files likely won't make that much of a difference, and if at some point a reasonable case for separating out some functionality emerges (say, when kdbus becomes popular) then the package can still be split.
Posted Oct 24, 2014 4:37 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
The Debian systemd package maintainers, clearly.
As I pointed out, the upstream systemd code does not do this. If you use the upstream pam-systemd on a non-systemd system, it's a no-op.
Posted Oct 24, 2014 4:44 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
Well, I think Cyberax is wrong there. It isn't as simple as "using some files".
pam-systemd uses the logind D-Bus interface, org.freedesktop.login1. Anything that implements that interface correctly should work with it, which is why Debian's libpam-systemd can work with systemd-shim.
The error here is in removing the "test if logind even appears to be installed" check. While that's probably the right idea, in that I suspect systemd-shim doesn't create the directory it looks for, it means that D-Bus activation now takes effect: it's made pam-systemd *require* a logind D-Bus interface, instead of failing gracefully if logind isn't present.
Posted Oct 18, 2014 8:08 UTC (Sat)
by mgb (guest, #3226)
[Link] (4 responses)
A weak non-modular design might be laughable were it not being forced on us. Sadly the consequence of this weak non-modular design is indeed to make it harder to improve Linux in future.
> it do bring benefits for others
And that would be fine if it were an option. Those who have serious work to do could just use sysvinit or openrc until something better came along.
When one has choices one can ignore bad software. Ultimately the most serious bug in systemd is that it is being forced on us.
Posted Oct 18, 2014 8:35 UTC (Sat)
by mchapman (subscriber, #66589)
[Link]
You keep using those words.
On my system, systemd consists of 80 separate binaries. Only one of them runs as PID 1. The software as a whole consists of 7 different DBus interfaces, each of which could in theory be implemented independently. When building systemd you have a choice of 59 separate --enable/--disable options to choose the components you want.
In what sense is it "non-modular"?
> When one has choices one can ignore bad software. Ultimately the most serious bug in systemd is that it is being forced on us.
If you feel that you lack influence over your distro's software decisions, then that sounds like a problem between you and your distro.
Posted Oct 18, 2014 13:56 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
You know, maybe if you cut it out with the backhanded comments, you'd have better discussions with others about systemd. As such, your apparent willful ignorance (e.g., insisting that it is non-modular) plus this makes you easily ignorable when you come with complaints.
Posted Oct 18, 2014 14:59 UTC (Sat)
by anselm (subscriber, #2796)
[Link]
Nothing is being “forced on you”. If you're a Debian user, the next version of the distribution will very probably still work with sysvinit – so far there are no packages that actually have a hard dependency on systemd as PID 1, and given that the freeze is just around the corner this is unlikely to change. That means that after the actual release of jessie (which is still some time away) there will be 2 to 3 years with jessie as “stable”, at least 1 year of additional security support after jessie+1 is released, and quite possibly even longer support under the auspices of Debian LTS, so a sysvinit-based Debian system should, as a conservative estimate, continue working with reasonable support for at least 4 years from now.
4 years should be ample either for Debian to figure out that systemd really is as crappy as some people claim and come up with a better approach for jessie+1, or for you to band together with other people who don't like systemd and create a systemd-free version of Debian jessie+1 (which should be straightforward even if Debian decides sysvinit support will not be mandatory in jessie+1 – consider that in jessie, all packages already support sysvinit, so it's not as if you would have to write a million init scripts from scratch).
Posted Oct 18, 2014 17:17 UTC (Sat)
by misc (subscriber, #73730)
[Link]
A more modular ( like actually modular in the sense there would be proper interfaces for module ) design would greatly help commercials vendors and out of trees kernels.
Yet, no one complain about that on the LKML would be considered, because as a community, we decide to not care about others people choice of license, and we think it is better to have all like this.
So tell us, why is the tight integration on the kernel fully ok despites having actual complain from coders since years and why is not ok on systemd ?
And why would it prevent innovation for userspace while it work fine with the kernel who kinda innovate a lot ?
In fact, thanks to systemd, there was much more innovation in the last 4 years than in 20 before. Your innovation point doesn't really work if anyone stop and think about it.
Posted Oct 18, 2014 10:44 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (4 responses)
In fact, systemd's resource control & watchdog features can be used to deal with many of the above failure scenarios.
Posted Oct 18, 2014 12:40 UTC (Sat)
by peter-b (guest, #66996)
[Link] (3 responses)
> In fact, systemd's resource control & watchdog features can be used to deal with many of the above failure scenarios.
All of them, actually.
Posted Oct 18, 2014 17:04 UTC (Sat)
by misc (subscriber, #73730)
[Link] (2 responses)
Posted Oct 21, 2014 17:51 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
Posted Nov 2, 2014 14:55 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Oct 18, 2014 21:15 UTC (Sat)
by jspaleta (subscriber, #50639)
[Link] (5 responses)
So starting with no gettys active I start a getty on tty4
and to manually restart it...
And then I can kill it off with
And looking at the getty service file seems its configured to always restart if it crashes... so I can test that... forcible kill the agetty process... and systemd respawns it as configured.
And starting up specific gettys on boot is easy as well through normal systemd target want mechanisms. arch wiki covers some of the options available to admins if you need a starting example.
So what am I missing with regard to getty restart that you want to do that systemd doesn't provide for? Serious question.
Given the capabilities I have access to right now with systemd's concept of targets, which are far more flexible than inittab's concept of runlevel.. I really don't understand the advantage of trying to keep support for inittab. I'm not aware of any functionality I'm giving up at present by not having access to inittab symantics.
Meh.
-jef
Posted Oct 19, 2014 14:09 UTC (Sun)
by flussence (guest, #85566)
[Link] (4 responses)
Some of RedHat's paying customers might be able to explain the value of not breaking a running system better.
Posted Oct 19, 2014 14:15 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Oct 19, 2014 14:57 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Systemd haters simply latched on to a minor detail and now it's becoming an icon of anti-systemd crusades.
Posted Oct 19, 2014 20:49 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (1 responses)
RHEL breaks stuff between major versions as if there was no tomorrow.
The good people at Red Hat do try to keep stuff stable within the same major version of RHEL,
which is good for more than a decade (i.e., longer than most servers last),
so upgrades from one major version to the next are rarely required.
Consequently, unlike Debian, Red Hat makes no attempt to even support
upgrading between major versions of RHEL.
Debian, on the other hand, makes no attempt to be RHEL. If you want that
sort of stability, be a Red Hat customer; it's their business, and they're
really pretty good at it.
Posted Oct 20, 2014 10:46 UTC (Mon)
by michich (guest, #17902)
[Link]
Posted Oct 18, 2014 1:46 UTC (Sat)
by misc (subscriber, #73730)
[Link]
See https://github.com/systemd/systemd/blob/master/src/core/m...
and the freeze() call, and the signal handler calling this function just after it.
Posted Oct 18, 2014 10:41 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (27 responses)
Increased service availability.
> Who restarts init if it crashes? A trained monkey?
Hardware watchdogs can be used to reboot the system if either systemd or the kernel stop responding. You can read more about these features at http://0pointer.de/blog/projects/watchdog.html.
> If your daemon suffers from that, it should provide an overseer process.
As a sysadmin, I do not want to deal with n different implementations of service babysitters, each of which work slightly differently, and have their own bugs and configuration mechanisms. This stuff is too critical to leave to application developers.
As an application developer, I want to program to the much simpler "new-style daemons" interface described in daemon(7) rather than the "sysv daemon" interface from the same man page, because one is much quicker and easier to correctly implement than the other.
Babysitting should be done by the init system. Even Microsoft got this right with the design of the service manager in Windows NT!
> Or _you_ should use a configuration management/monitoring daemon, for which there are many to choose from today.
None of which can _really_ guarantee robustness, given that the *only* way to monitor a service properly on linux is to wait(2) on it, which can only be done to a process's children.
> Your solution is to bloat PID 1 with more mechanism and more policy, knowing there's a kernel panic if it crashes? That would be a glaring design flaw, yes. Init is engineered correctly as it is.
Please accept that these are merely your opinions. Those adopting & using systemd (and the init systems that came before it: NT's service manager, daemontools & friends, SMF, launchd, upstart) do not agree.
Posted Oct 18, 2014 12:09 UTC (Sat)
by Zack (guest, #37335)
[Link] (24 responses)
Can I have that in writing? Preferably something like:
"User Zack is entitled to have opinions. As such we, systemd proponents, will not rams ours down his throat by making software he might use have a hard dependency on systemd so he will be required to accept our opinions when upgrading."
Come to think of it, that's pretty much what the proposed GR is about, isn't it? That those who for some unfathomable reason cannot see the glorious nature of systemd and all that it encompasses (and will encompass) will not be required to use it.
Posted Oct 18, 2014 12:39 UTC (Sat)
by peter-b (guest, #66996)
[Link] (13 responses)
If, in my opinion, using systemd interfaces makes my software better, then I'll enjoy the freedom to use them. And you'll have still get to enjoy the aforementioned freedoms.
You have the freedom to have whatever opinions you like. Guess what? *So does everybody else.*
Posted Oct 18, 2014 12:58 UTC (Sat)
by Zack (guest, #37335)
[Link] (12 responses)
> You have the freedom to have whatever opinions you like. Guess what? *So does everybody else.*
If only everybody else who champions systemd would feel as strongly about this you do.
Posted Oct 18, 2014 13:06 UTC (Sat)
by pizza (subscriber, #46)
[Link] (11 responses)
> If only everybody else who champions systemd would feel as strongly about this you do.
Those who do the work, decide what gets done.
To paraphrase a saying, "Your right to hold an opinion ends when it requires me to perform unpaid work for you."
Posted Oct 18, 2014 19:24 UTC (Sat)
by Zack (guest, #37335)
[Link] (10 responses)
Why should I be doing unpaid work for an init system I do not want or need? It's great people like systemd and have a high opinion of it, but that opinion should really end when it's about to be installed on someone else's machine as a dependency.
Posted Oct 18, 2014 19:50 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (8 responses)
And as has been linked in this article's comments already, nothing that worked with sysvinit before doesn't work now. As such, I think Lucas' amendment makes much more sense than Ian's.
Posted Oct 20, 2014 4:24 UTC (Mon)
by edomaur (subscriber, #14520)
[Link] (5 responses)
Anyway, as a sysadmin with a bunch of servers on Debian and RedHat EL, and I am quite happy to get systemd on both : this way, I will (probably) not needing to write the same scripts 2 time each, and I will be able to remove some complexity from my day job.
Posted Oct 20, 2014 10:21 UTC (Mon)
by Zack (guest, #37335)
[Link] (4 responses)
This isn't about systemd's availability in Debian, it's about preventing maintainers from deliberately stonewalling others from doing the work to keep an alternative init system usable because they are of the opinion that systemd should be the only viable option for Debian.
Posted Oct 20, 2014 11:45 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (3 responses)
AFAIK there is no evidence that this is actually a problem. Please tell me about such a case if one exists.
I don't think package maintainers will deliberately refuse to merge contributions by interested third parties that enable their packages to run with particular init systems. It's just that package maintainers should not be forcibly volunteered by third parties to come up with the required code by themselves if they don't want to (which would be against Debian's constitution).
One solution could always be to team-maintain the packages in question such that maintainer A can take care of the adaptation to init system X that maintainer B (for whatever reason) doesn't want to touch, while maintainer B maintains the adaptation to init system Y that maintainer A (for whatever reason) doesn't want to touch. On the whole, Debian package maintainers are reasonable people, and it should generally be possible to work something out.
Posted Oct 20, 2014 13:27 UTC (Mon)
by Zack (guest, #37335)
[Link] (2 responses)
> I don't think package maintainers will deliberately refuse to merge contributions
And I'm not so sure about that. This GR will (or will not) give me the reassurance that any work done on alternative init implementations (or maintenance of sysvinit) will not be blocked simply by systemd being the default.
This GR isn't about shoving around work; it's about reassuring those who are not (yet) convinced about systemd, that Debian is still a suitable distribution for them and that their contributions are welcome.
Posted Oct 20, 2014 15:31 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
I think that the GR is only peripherally connected with that. As I said, even without the GR it is unlikely that package maintainers will deliberately decline to include support for other init systems than systemd if that support is volunteered by interested third parties.
It seems to me, though, that the GR in its present form tries to force package maintainers to create support for additional init systems even if the upstream package doesn't come with such support and nobody else steps forward to do it. In addition, it is unclear whether packages must support all init systems that are part of Debian or whether any two will do as long as one of them is systemd. One might also ask exactly what actually constitutes an “init system”.
In my opinion it is unreasonable to ask package maintainers to actively create support in their packages for additional non-default init systems. As of now most if not all relevant packages do support sysvinit, and that support should not be removed without good cause. Bug reports can be opened if required, and if the package maintainers don't (or can't) take care of them themselves then those people who are sufficiently interested in keeping sysvinit support going in Debian can help out. The same goes for support for things like Upstart; I don't think package maintainers should be compelled to add, debug, and maintain Upstart support for packages that don't come with it in the first place. If they want to do it, fine; but let those people who are interested in widespread Upstart support in Debian do the work if the package maintainer won't or can't do it, and have the package maintainer integrate it once it is done.
Posted Oct 20, 2014 17:32 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link]
What this GR does is make specific set of potential release blockers... regardless of whether patches have been contributed or not.
And let me be clear about this... this GR is not scoped to be just about ensuring a systemd transition from sysvinit.
In the future, post jesse if uselessd shows up in the repo, and uselessd works as a systemd replacement that will meet the requirement of this GR, without anything having to continue to work with sysvinit.
And that is the fundamental problem with this GR. It's not actually addressing the specific ongoing concern of making sure users can transition from old default (sysvinit) to new default (systemd) with minimal disruption.
The abstract language of the GR about init choice is just silly. Nobody really expected everything to work with mini as an alternative init without a lot of close hand-to-hand combat by the admin. The "freedom" to choose an alternative init has been until this point in time the "freedom" to break your system by choosing to use an alternative init.
This GR tries to make an overly broad policy statement that drastically changes the character of how all alternative inits are to be handled, but does not actually do anything to address the ongoing concern of transitioning from an old default init to a new default init...which is the only actionable concern that was triggered by choosing to change the default init.
-jef
Posted Oct 20, 2014 21:29 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
Actually, the LO devs (and I should know, I'm involved in it) ARE rewriting LO to remove the Java dependency. Incidentally, if you do build LO --without-java, pretty much the only thing that will break is Base.
Cheers,
Posted Oct 26, 2014 19:23 UTC (Sun)
by HelloWorld (guest, #56129)
[Link]
Posted Oct 20, 2014 0:56 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Oct 18, 2014 12:56 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (3 responses)
Posted Oct 18, 2014 20:29 UTC (Sat)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
-jef
Posted Oct 21, 2014 21:33 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
And this is supposed to *dissuade* us? :P
Posted Oct 21, 2014 21:35 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
Posted Oct 19, 2014 15:24 UTC (Sun)
by misc (subscriber, #73730)
[Link] (5 responses)
Once this social dynamic is understood, you can clearly see that any user protests is going to have almost no traction, especially since that's one of the strong point of Debian, being free from pressure. A commercial distribution where you pay money would be a different beast, since the customer is listened, due to the fact he exchange money for the work, so the relationship is balanced. A community distribution, not so much.
So you decided to take a distribution where no one can influence it, so you get what you asked for
Posted Oct 19, 2014 23:17 UTC (Sun)
by jb.1234abcd (guest, #95827)
[Link] (4 responses)
Once this social dynamic is understood, you can clearly see that any user protests is going to have almost no traction, ..."
I think your interpretation of this social dynamic is lacking.
Now with regard to systemd.
If systemd were not questioned the way it was (which forced the devs to
From this point of view alone, this Debian's GR is an attempt to limit
So, this alone invalidates your interpretation of one-way social dynamic that presumably governs relations between devs and the rest of OSS
jb
Posted Oct 20, 2014 11:13 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link]
Said closed dev cabal, who you claim developed everything in a closet with no input whatsoever from the wider community, does include someone from all important distributions. Their "in a closet" development model contemplated detailed analysis of extant init systems (not only Unixy ones, BTW), careful consideration of existing configuration file formats and locations among Linux distributions, and extensive consultation with interested parties. Go check systemd's blog for development (pre)history.
Posted Oct 20, 2014 17:45 UTC (Mon)
by misc (subscriber, #73730)
[Link] (1 responses)
Sure, you can think users are part of the movement and they are, but the truth is quite clear. There is no voting right for them, and they are barely acknowledge. Most distribution do not have a group dedicated to feedback from people. never wondered why there is several bug reporting tools for free software, but not so much to get feedback with a clear user orientation ?
When there is a problem, the priority is on the developer side, by pushing the work on users ( ie, filling a bug report ), because we clearly put more value on the time of people who contribute code than people that don't.
You can delude yourself in the state of free software, and I would be the first one to say that this balance of power is unfortunate and should be fixed.
Yet, being sorry about the state of affairs doesn't make it disappear, no matter how hard you want to believe. If you want things to change, you have to be constructive and do something, not just protest and post. As Linus once said "talk is cheap, show me the code".
Posted Oct 20, 2014 20:31 UTC (Mon)
by pizza (subscriber, #46)
[Link]
When there is a problem, it is up to the person who finds the problem to report it. That's not "pushing work on users" or making value judgements of anyone's time.
You can't fix what you don't know is broken.
Posted Oct 25, 2014 15:10 UTC (Sat)
by ms_43 (subscriber, #99293)
[Link]
Instead, the systemd project was started as an open bazaar-style community without silly CLAs that give a single corporation control, and the project managed to attract many contributors (https://www.openhub.net/p/systemd/contributors/summary).
You can educate yourself by reading Scott James Remnant's comments on this post:
Thus it is hard for me to see what "philosophy and rules of software development" were violated by the systemd project.
Posted Oct 18, 2014 15:07 UTC (Sat)
by ctpm (guest, #35884)
[Link] (1 responses)
>Hardware watchdogs can be used to reboot the system if either systemd or the kernel stop responding. You can read more about these features at http://0pointer.de/blog/projects/watchdog.html.
Yes, hardware watchdogs have been around for a very very long time and are obviously useful when a *kernel* stops responding or there is no process running in userspace to let you in and recover the system manually. And that is where HW watchdog use is justified -- as a last resort.
But if your failure is caused by a bug on a potentially complex thing like systemd, which could be recoverable by restarting that service alone, why would you want to bring the system down with mounted filesystems and everything? Think of a server exporting luns via network or a distributed FS shard. That spontaneous reboot may cost quite a lot in terms of recovery for the whole system. Why would you choose to nuke the system as a first option, when a least a good portion of it might be still doing useful work?
So IOW, I'm not saying that the service monitoring and recovery features on systemd are useless. I'm saying that the complex logic and state machines to handle that, should run on a child of PID 1, not in PID 1 itself.
Posted Oct 18, 2014 18:43 UTC (Sat)
by peter-b (guest, #66996)
[Link]
I'm not sure why you consider it unreasonable to put functions for starting and monitoring services into a process that's sole role and reason for being is to start and monitor services...
Posted Oct 20, 2014 12:19 UTC (Mon)
by josh (subscriber, #17465)
[Link]
That's one of init's primary jobs, and has been since long before systemd. In particular, note that sysvinit has similar functionality to restart processes if they're launched via inittab rather than init.d; it doesn't work as well, but it does exist.
Posted Oct 21, 2014 16:56 UTC (Tue)
by nix (subscriber, #2304)
[Link]
The Debian init system general resolution returns
A cursory inspection of the systemd-shim source tree indicates that systemd-shim is not a fork of systemd. It is an independent reimplementation of a subset of systemd's functionality, which imports a few source files from the systemd code base.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
What is wrong with that init script? It looks fairly sane to me. How does starting named using systemd fix it?
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
2) You want an init script to handle SELinux labeling and policy enforcement? Do I misunderstand you? If I don't, how, exactly, would that work?
3) SELinux integration is handled by the SELinux subproject of the Hardened Gentoo project. The package manager handles FS labeling, and the system administrator can either manually install policies, or tell the package manager to auto-install them. More info here: http://wiki.gentoo.org/wiki/SELinux
The Debian init system general resolution returns
How do you make systemd run named-checkconf before you restart BIND, and refuse to attempt the restart if named-checkconf finds an error?
The Debian init system general resolution returns
The Debian init system general resolution returns
No it isn't correct and it doesn't do all the systemd's work, even if we do not consider socket activation.
> ProtectSystem=full
> ProtectHome=true
> PrivateTmp=true
> CapabilityBoundingSet=CAP_SYS_NET_BIND
See this for the discussion of the problem: https://access.redhat.com/documentation/en-US/Red_Hat_Ent...
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Guaranteeing that all of these are security bug free is non-trivial when compared to auditing a narrow dbus interface.
The Debian init system general resolution returns
If libdbus had a security flaw in that manner
'If' is the wrong word to use here. It's happened, repeatedly.
The problem is not modifying the shell scripts themselves, but that the attack surface comprises the shell script, the shell itself, and all the various other scripts, executables, etc. which get invoked in the script.
Guaranteeing that all of these are security bug free is non-trivial when compared to auditing a narrow dbus interface.
If GNU coreutils, iputils etc aren't safe to run as root, everyone is buggered in any case. Sysadmins routinely run these things as root, and systemd existing isn't going to make them stop.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Lot of people seems to be fine with the tradeoff of marginally increasing the attack surface for the benefit it provides ( ie, dbus provides a API unlike initscripts that don't ). Since dbus is locally accessible, the attack surface is not as catastrophic as you seems to think, and since upstart was already dbus powered, we would have seen this attack surface exploited since a long time as ubuntu and rhel do use upstart )
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
All but one of our systems - that includes desktops, laptops, servers, and VPSs - have one or more inittab entries in addition to those supplied by the distro.
fb:2345:respawn:/usr/local/bin/foobar -baz
simply add a file /etc/systemd/system/foobar.service containing
[Unit]
Description=Foobar service (from inittab)
[Service]
ExecStart=/usr/local/bin/foobar -baz
Restart=always
[Install]
WantedBy=multi-user.target
At first glance this seems more wordy but it does allow all sorts of useful features that sysvinit doesn't offer (like, for example, rate limiting for respawns). In addition, the service can be started and stopped manually like all other systemd services where with sysvinit you would need to edit the /etc/inittab file, and it shows up in the usual service status listings.
The Debian init system general resolution returns
The Debian init system general resolution returns
sysvinit has provided respawn rate-limiting for as long as I can remember.
inittabs are updated by the configuration management system.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Debian's "Essential: yes" package attribute does not mean what you think it does.
The problem comes now that RH deliberately breaks existing software so that it no longer works without systemd.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
https://wiki.debian.org/Suspend
The Debian init system general resolution returns
The Debian init system general resolution returns
ref: http://blogs.gnome.org/desrt/2014/02/19/on-portability/
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Please don't mislead people. Ian said he was not aware of any RC bugs - not that there are none, or that there will be none.
The Debian init system general resolution returns
"This GR seeks to preserve the freedom of our users now to select an
init system of their choice, and the project's freedom to select a
different init system in the future. It will avoid Debian becoming
accidentally locked in to a particular init system (for example,
because so much unrelated software has ended up depending on a
particular init system that the burden of effort required to change
init system becomes too great). A number of init systems exist, and
it is clear that there is not yet broad consensus as to what the
best init system might look like."
The Debian init system general resolution returns
https://lists.debian.org/debian-vote/2014/10/msg00124.html
https://lists.debian.org/debian-vote/2014/10/msg00197.html
https://www.debian.org/vote/2014/vote_003
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
libvirt-*
hplip - HP Linux Printing and Imaging System
fprintd - D-Bus daemon for fingerprint reader access
colord - system service to manage device colour profiles
bluefish - advanced Gtk+ text editor for web and software development
steadyflow - Simple download manager for GNOME
sparkleshare - distributed collaboration and sharing tool
nemo - File manager and graphical shell for Cinnamon
nautilus - file manager and graphical shell for GNOME
caja - file manager for the MATE desktop
brasero - CD/DVD burning application for GNOME
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
> system and service manager - SysV links
>or systemd-shim (>= 8-2)
> shim for systemd
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Ultimately the most serious bug in systemd is that it is being forced on us.
The Debian init system general resolution returns
And to give a example, the kernel policy didn't prevent android from emerging or grsec to innovate, despites them being out of the kernel.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
systemctl start getty@tty4.service
seems to work just fine to start the getty up. A see an agetty instance on tty4 now in the ps output.
systemctl restart getty@tty4.service
new agetty pid on tty4 on ps output.
systemctl stop getty@tty4.service
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Red Hat makes no attempt to even support upgrading between major versions of RHEL.
That's no longer true. There is a supported upgrade path from RHEL 6 Server to RHEL 7 Server (only on x86_64 so far). See KBase articles:
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
It's about preventing maintainers from deliberately stonewalling others from doing the work to keep an alternative init system usable because they are of the opinion that systemd should be the only viable option for Debian.
The Debian init system general resolution returns
The Debian init system general resolution returns
This GR will (or will not) give me the reassurance that any work done on alternative init implementations (or maintenance of sysvinit) will not be blocked simply by systemd being the default.
The Debian init system general resolution returns
The Debian init system general resolution returns
Wol
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
This ecosystem functions according to different laws than a commercial
organization offering a product to a paying customer.
The reason for that is obvious - Open Source Software has a participatory
and contributory character. Those active in it, whether devs or all other
people assuming formal or informal roles of users, testers, ambassadors,
commentators, etc depend on each other organically.
Many of OSS projects, including kernel, would be non-starters or suffer
quality issues without often anonymous and free code contributions, advice, discussions, and PR-like activities at home, work place, and public at large.
I do not remember any software project, in this ecosystem or elsewhere,
that polarized the participants (see above) so much.
And for a good reason, as its aims as presented violated that ecosystem's
philosophy and rules of software development. It was an ambush style,
"my way or hiway" approach to introduction of a new software that impacted
everybody dependent on this ecosystem. As a result, it was met with
resistance and mistrust as to its intentions.
In the process of subsequent evaluation, the devs were even shown to lack
understanding of which domain's problems (real or perceived) they were trying to solve, which led them to a wrong model, which led them to some
antics in design and implementation.
My opinion is that systemd, if it had been properly evaluated in advance,
it would be structered and look different today, if not stopped altogether
at least until revised from top to bottom.
It is my opinion that the distros that hastily adopted systemd contributed
mightily to subsequent uproar in the ecosystem.
make some corrections), then the damage would be even bigger.
the damage to themselves, but also to the rest of us, and so it is
a positive step.
That's why it should find support among Debian devs, and beyond.
participants.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
https://plus.google.com/+KaySievers/posts/C3chC26khpq
The Debian init system general resolution returns
Yes, PID 1 has the advantage of adopting every orphan in the system, but the costs of a failure can be quite high. I think a more useful approach would be to work with the kernel people to perhaps solve the waiting and re-parenting problem, instead of just overloading PID 1 and hoping for the best, and that nobody else minds about being restarted by HW watchdog. It's not like the kernel isn't already getting code whose main user will be systemd anyway.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Why the heck should the init system restart failed crashed processes?
The authors of sysvinit. (What else do you think /etc/inittab is for?)
Who restarts init if it crashes?
Nobody. If init crashes, the kernel panics. (It is quite hard for init to crash: it has a special dispensation to never receive signals for which it does not have a handler, including fatal signals.)
