13 11 | 2014

Re: About choice

Written by Tanguy

Classified in : Homepage, Debian, Grumble, Replies

This is a reply to Josselin Mouette's blog article About choice, since his blog does not seem to accept comments¹.

Please note that this is not meant to be systemd-bashing, just a criticism base one a counter-example refutation of Josselin's implication that there is no use case better covered by SysV init: this is false, as there is at least one. And yes, there are probably many cases better covered by systemd, I am making no claims about that.

A use case better covered by SysV init: encrypted block devices

So, waiting for a use case better covered by SysV init? Rejoice, you will not die waiting, here is one: encrypted block devices. That case works just fine with SysV init, without any specific configuration, whereas systemd just sucks at it. There exist a way to make it work², but:

  • if systemd requires specific configuration to handle such a case, whereas SysV init does not, that means this case is better covered by SysV init;
  • that work around does not actually work.

If you know any better, I would be glad to try it. Believe me, I like the basic principles of systemd³ and I would be glad to have it working correctly on my system.

Notes

  1. Well, it does accept comments, but marks them as span and does not show them, which is roughly equivalent. ↑
  2. Installing an additional piece of software, Plymouth, is supposed to make systemd work correctly with encrypted block devices. Yes, this is additional configuration, as that piece of software does not come when you install systemd, and it is not even suggested so a regular user cannot guess it. ↑
  3. Though I must say I hate the way it is pushed into the GNU/Linux desktop systems. ↑
Tags : reply, blog, article, comment, systemd, SysV, init, use, case, refutation, example

15 comments

thursday 13 november 2014 à 13:22 Riku said : #1

> That case works just fine with SysV init, without any specific configuration

Well for some stretch of of "any specific configuration". People have put a lot of work to initscripts and debian packages involved to make "just work". Such packaging work is clearly missing around systemd.

I was wondering why I don't see this on my machines. I realized it is because my root is encrypted, thus the question comes from initramfs. All change that breaks existing setups is painful, but it is also a chance to reflect if previous configuration still makes sense. perhaps you might want to switch to encrypting root as well rather than having some plaintext and some crypter partions.

thursday 13 november 2014 à 13:29 Chris Cunningham said : #2

You're not really doing yourself any favours by doubling down on your previous "no way" comment. A truly parallel boot process requires input serialisation. This is an obvious technical matter, and there should be nothing remotely controversial about it. Refusing to install a package that provides such serialisation is irrational from a purely technical point of view, and childishly spiteful from a personal one.

A productive use of your time would have been to push for plymouth to be brought in as a dependency in any case where the boot process might require input serialisation (and to fix any bugs where said serialisation doesn't work). In the end, this work will be done anyway, by others, while the historical record will show that you were more interested in publicly airing your own prejudices.

thursday 13 november 2014 à 13:48 Tanguy said : #3

@Chris Cunningham : Please read again my article. I did try Plymouth, even though it is not even suggested or mentionned in the systemd Debian package. And it does not work: it makes things a bit better indeed, but the problem persists in a lesser way.

Also remember that, when it comes to init systems, I am a pure user, not interested in coding anything since the existing suits my needs. When a potential replacement comes, I try it, and if it does not work fine in my case, I go back to what I was using before.

thursday 13 november 2014 à 14:00 Konstantin Khomoutov said : #4

@Tanguy, this claim about being a pure user is also irrelevant: Jessie is frozen but is not yet released. The bug you describe, if it really exist, is not yet fixed but it well might be -- by the time Jessie is released. End users only install/upgrade to stable releases so compare apples to apples and come back to this after the Jessie's release announce.

On the other hand, you are clearly not an end user but, on the contrary, a power user at least (may be you even possess sysadmin or programming skills, or both), so you at least clearly have the necessary skills to deal with posting burgeports and testing possible fixes to them -- precisely to make *end users* have no such problems when they upgrade. In the end, this is why people like you use testing/unstable: they test -- and try to fix -- the system in its ever-transient state to make the version to be released next have no serious bugs.

thursday 13 november 2014 à 14:19 Np237 said : #5

So you found a bug in the Debian package of systemd.

This is precisely why we need to support both sysvinit and systemd in jessie: there are still some bugs, and having one release cycle to sort them out doesn’t sound too long.

But this is clearly not a use case that is not handled by systemd. Don’t get me wrong: this needs fixing. But saying that systemd does not cover this use case is a fallacy.

(BTW my blog accepts comments, but anonymous comments are moderated so they take some time before appearing.)

thursday 13 november 2014 à 14:23 Tanguy said : #6

@Np237 : I never said that case was not handled by systemd, only that it was poorly handled, and thus, that SysV init handled it better. Yes, it is only a bug, I agree on that.

About comments on your blog, when I posted my comment, I was shown a notice saying that, according to the blog settings, my anonymous comment was considered as a spam. I am glad to learn that it was in fact queued for moderation, but that means that notice was wrong, so it would be better if you could change it, if that is possible, that is.

thursday 13 november 2014 à 15:00 Martin Hradil said : #7

I must say I haven't had any problem with the crypto prompt in debian even without plymouth, but I only have the one systemd notebook which was a fresh jessie/systemd install and the only encrypted device is the root, so it's probably handled before systemd gets to even start.

As for Plymouth, if that's going to be the only officially supported way of having the prompt working, we need to do something about that. I will not tolerate a graphical boot screen on my laptop only to have passwords work, and there seems to be no way to make it use text boot (or my google-fu is not strong enough).

But actually, I think there's an even greater strength of sysvinit: failure :). As I understand it now, if my systemd fails to start, I'm pretty much screwed. It will give me bash, but I won't be able to do much debugging - systemctl foo start refuses to do anything without systemd running, an initscipt may not be present if the service is using an unit file already, AFAIK there's no way to run a unitfile just like that (respecting the settings it can and just running the daemon), and there's nowhere I can find out what it's actually supposed to be doing (all the stuff in rcS.d that gets handled inside systemd instead). OTOH if sysvinit gives me bash, I can run the whole boot process myself manually, in the right order, even skipping stuff as needed, and bash is actually not a bad init in emergencies (eg. it can handle reaping just fine).

thursday 13 november 2014 à 15:41 al said : #8

Yours is a wishlist bug... just like this one

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758902

/s

thursday 13 november 2014 à 17:26 Ritesh Raj Sarraf said : #9

Like you, I got auto-spammed on that blog. I'll put some I know rightway here.

http://anonscm.debian.org/cgit/pkg-iscsi/open-iscsi.git/tree/debian/umountiscsi.sh.init

http://anonscm.debian.org/cgit/pkg-iscsi/open-iscsi.git/tree/debian/open-iscsi.init

http://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/tree/debian/multipath-tools.init

I'd be interested to know how they could be adapted to systemd without a sub-shell script.

thursday 13 november 2014 à 17:37 Np237 said : #10

As for iSCSI, Multipath, LVM and the like, these kind of tools are precisely the reason why we need an init system that can manage events. It is sysvinit which is fundamentally deficient in handling dynamically discovered devices.

friday 14 november 2014 à 07:29 Ritesh Raj Sarraf said : #11

@Np237

We always had the mechanism to trap events. It is called udev. There is no strong reason to push it to init. Fine grained udev rules always did the job.

In its current form, systemd brings more limitations than features for the use cases I've listed.

friday 14 november 2014 à 09:50 Np237 said : #12

@Ritesh Raj Sarraf

What limitations?
Does the current script not work with systemd?

Can udev alone associate the startup of services associated with the discovery of iSCSI or LVM devices?

friday 14 november 2014 à 12:48 Chris Cunningham said : #13

Did someone really say udev was something that Debian always had? And this someone is anti-systemd? Back in the day, udev itself was the Horrible Non-Unixy Devouring Horror that all the neckbeards were categorically opposed to. Now not even the most sociopathic curmudgeon (and there are plenty of them in the community) opposes it.

monday 17 november 2014 à 11:10 Arno said : #14

There is also #618862, about missing keyscript support for cryptsetup. It puzzles me that that bug is known for 3 years yet is not marked RC, especially since it appears systemd-sysv will be pushed on dist-upgrade (#758825) as well.

Adding to that the newer kernel's requirement to add hid_generic to initramfs before usb keyboards will work, I see a high risk of hard to recover boot failures.

tuesday 18 november 2014 à 00:48 Np237 said : #15

Systemd does not support keyscripts because they are not compatible with the way it interacts with the console. This use case is covered by the password agent, which is an entirely different concept:
http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/

And again, I’m not saying this won’t cause problems. It will. Your keyscripts will not magically be replaced upon upgrades. From my research, this is the most significant incompatibility between sysvinit and systemd in Debian, and this is something that could have been better dealt with.

It is certainly one of the best reasons to keep sysvinit fully working for the timeframe of the jessie release. But it is something that will eventually be replaced without any significant impact on functionality and usability. In the long term, it is not a reason for keeping sysvinit available.

Rss feed of the article's comments

Write a comment

What is the third letter of the word tjuhq? : 

Archives