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

[castet . matthieu]

Hi,

Selon "Dr. Werner Fink" <address@hidden>:
> 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