Control: tags -1 wontfix Control: close -1 On Mon, 21 Nov 2016 09:58:57 +0100 Martin Steigerwald <mar...@lichtvoll.de> wrote: > Package: systemd > Version: 232-5 > Severity: normal > > Dear Martin, dear Michael, dear Maintainers, > > as I added a removable LUKS crypto device to fstab like in > > /dev/mapper/someluksdevice /mnt/somemountpoint btrfs noatime,autodefrag,compress=lzo 0 0 > > I forgot to add "noauto". > > Consequently systemd ran into a timeout of 90 seconds that was not > interruptible. > > On the other hand atopacctd from experimental right now does not respond to > SIGTERM properly at the moment, again leading into a 90 seconds timeout, > that again is not interruptible with Ctrl-C. > > > Actual results > > Pointless waiting. I know the action is not going to succeed. I know this > *better* than systemd. Frustration cause I get the impression systemd tries > to control me while I think it should be the other way around. > > > Expected results > > When I press Ctrl-C when systemd runs into a timeout, I expect systemd > to execute my command as soon as possible. Cause actually I know better > than systemd in that cases and waiting for the completion of the timeout > is pointless. > > I have some understanding that systemd may not allow Ctrl-C in all circum- > stances, since it may be possible that someone tries to hack the boot > process by just pressing Ctrl-C, but when systemd notices that it runs > into a timeout and displaying so I expect it to give an option to tell it > to stop waiting pointlessly. > > > I think this is an upstream issue. Feel free to forward it. I don´t feel > like arguing with systemd upstream myself given my past experiences on > systemd developer mailinglist, please respect that. > > Thank you, > Martin
As explained in the upstream ticket this is pretty much intentional, hence closing. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
