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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5485c7d0.7070...@gmail.com
