Re: Skipping fsck during boot with systemd?
On 12/8/2014 9:42 AM, Henrique de Moraes Holschuh wrote:
> On Mon, 08 Dec 2014, Christian Groessler wrote:
>> Why don't the systemd proponents understand that someone might want to
>> interrupt a running fsck? Don't scrutinize the reasons, just accept
>> the fact.
>
> Handwaving issues away is intolerable behavior in a professional capacity,
> but in this particular case you can just ignore the handwaving entirely, as
> it is not being done professionaly, nor is it being done by either the
> debian maintainers or upstream.
>
> This thread should have died off the moment it became clear that handling
> the interrupt signal in fsck _is_ in systemd's upstream todo file and also
> reported as a bug that is still open and _not_ tagged wontfix in Debian.
>
I disagree. The original bug was filed on 2011-07-08 - almost 3.5 years
ago, and nothing has been done on it. And on 2012-05-06, there was an
acknowledgement that it is on the upstream's TODO list. That's over 2.5
years ago.
It obviously is causing a lot of people problems, and is not being fixed
in a timely manner. And if people don't talk about the problems it is
causing, chances are it's not going to be fixed in the near future.
> The useful thing to do now is to come up with tested patches, file them on
> the bug report, and start the process to get them reviewed and accepted.
>
That would be great if I had the time to learn systemd, figure out how
(and why) the ability to interrupt fsck was disabled, how to re-enable
it and ensure there are no side effects. Note that while I develop
custom device drivers and applications, I've never dug into the init
system, so it would be a large learning curve. That's days, if not
weeks that I don't have.
Or, the developer of systemd, who should be intimately familiar with his
code, could probably do it in a few minutes, or at most, a couple of
hours. But it's obviously not a high priority.
> We broke the signal delivery in sysvinit as well for a while, when we added
> parallel execution (startpar). People would ^C and the signal would hit
> some unintended process because there were several running at the same time,
> all with the console open. This could break the boot horribly, of course.
>
> The initial "fix" blocked all handlign of the interrupt signal, with pretty
> much the same consequences as the current issue in systemd-fsck. I am not
> sure how well it got fixed in the end on the sysvinit+startpar+fsck side, it
> was some time ago.
>
> The truth is that keyboard-raised signal delivery can be hard to get right
> when you have both "parallel execution" and "console". And it can get
> either much more difficult or much easier to do right when you have a
> initsystem IO multiplexer front-end on top (i.e. stuff like plymouth).
>
Hence the side effects I spoke of above.
>> After all, it's *my* computer, and *I* want to be in control of it.
>
> Yes, that's perfectly understandable.
>
I haven't been bitten by this bug yet, because I'm not running Jessie.
But it's just another reason why it's not good for servers, and even
causes major problems for users.
Jerry
Reply to: