Hi, Selon "Dr. Werner Fink" <wer...@suse.de>: > On Fri, May 21, 2010 at 11:37:19AM +0200, Petter Reinholdtsen wrote: > > Werner, any idea how startpar should handle ^c? This is the report in > > <URL: http://bugs.debian.org/582442 >. > > > > > since last upgrade (makefile style migration ?) I got strange > > > behaviour of the boot sequence. > > > > > > If I interupt some script with ctrl+c, the dependency are lost (not fs > > > mounted, no network, ...). > > > With the previous version this worked. > > > > > > I interrupt sometimes fsck (when I don't want to wait), now this doesn't > > > work. > > > > > > Also on my system udev script hang at the end (until there is a > > > timeout). I often hit ctrl+c to avoid waiting the timeout. This now make > > > the system not usable. > > > > > > If ctrl+c is not supported anymore, it should blocked to avoid this > > > strange behaviour. > > > > I tested this, and pressing ^c while rcS.d/ scripts are executed break > > the entire boot. > > If such a trap does not work we may set signal handlers for > startpar to avoid that startpar its self is stopped. Nevertheless > the question is do we want to interrupt the current jobs. > Please remember that the messages seen on screen are not > in sync with the execution progresses of the jobs. Those > messages are buffered to avoid extremly mixed messages. > Is that true for interactive process ?
Matthieu
