The Debian init system general resolution returns
The Debian init system general resolution returns
Posted Oct 18, 2014 5:53 UTC (Sat) by misc (subscriber, #73730)In reply to: The Debian init system general resolution returns by mgb
Parent article: The Debian init system general resolution returns
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 ).
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 )
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.
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.
