[Pkg-sysvinit-devel] Bug#582442: [sysvinit-devel] (fwd) Bug#582442: sysvinit: Failing to interrupt some script after upgrade

[Dr. Werner Fink]

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.

Normally startpar inherit the signal handling of its parent.
And it does reset the signals INT, QUIT, SEGV, TERM, and CHLD
to the default for each of its own childs.

Maybe using a trap on e.g. SIGINT will help to make startpar
more tough against Ctrl-C.  IMHO Ctrl-C on a running fsck
may cause real trouble (in my own experience I've seen
corrupted file systems).

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.


      Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr