Debian Bug report logs - #582442
sysvinit: Failing to interrupt some script after upgrade

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: matthieu castet <castet.matthieu@free.fr>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: sysvinit: Failing to interrupt some script after upgrade

Date: Thu, 20 May 2010 21:33:57 +0200

Package: sysvinit
Version: 2.88dsf-5
Severity: normal
Tags: sid

Hi,

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.

Matthieu

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-2-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to fr_FR)
Shell: /bin/sh linked to /bin/dash

Versions of packages sysvinit depends on:
ii  initscripts                   2.88dsf-5  scripts for initializing and shutt
ii  libc6                         2.10.2-8   Embedded GNU C Library: Shared lib
ii  libselinux1                   2.0.94-1   SELinux runtime shared libraries
ii  libsepol1                     2.0.40-2   SELinux library for manipulating b
ii  sysv-rc                       2.88dsf-5  System-V-like runlevel change mech
ii  sysvinit-utils                2.88dsf-5  System-V-like utilities

sysvinit recommends no packages.

sysvinit suggests no packages.

-- no debconf information

Message #10 received at 582442@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: Matthieu Castet <castet.matthieu@free.fr>, 582442@bugs.debian.org

Subject: Re: Bug#582442: sysvinit: Failing to interrupt some script after upgrade

Date: Thu, 20 May 2010 22:50:34 +0200

[Matthieu Castet]
> I interrupt sometimes fsck (when I don't want to wait), now this
> doesn't work.

Wow.  You are braver than me.  I never considered that use case. :)

> 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.

Does it help to disable parallel booting by adding CONCURRENCY=none in
/etc/default/rcS?

> If ctrl+c is not supported anymore, it should blocked to avoid this
> strange behaviour.

The parallel starting is done by by startpar, so I guess that is the
program that need to be adjusted.

Happy hacking,
-- 
Petter Reinholdtsen

Message #15 received at 582442@bugs.debian.org (full text, mbox, reply):

From: "Dr. Werner Fink" <werner@suse.de>

To: Petter Reinholdtsen <pere@hungry.com>

Cc: sysvinit-devel@nongnu.org, 582442@bugs.debian.org

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

Date: Fri, 21 May 2010 12:00:59 +0200

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

Message #20 received at 582442@bugs.debian.org (full text, mbox, reply):

From: castet.matthieu@free.fr

To: "Dr. Werner Fink" <werner@suse.de>

Cc: Petter Reinholdtsen <pere@hungry.com>, sysvinit-devel@nongnu.org, 582442@bugs.debian.org

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

Date: Sat, 22 May 2010 18:13:18 +0200

Hi,

Selon "Dr. Werner Fink" <werner@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

Message #25 received at 582442@bugs.debian.org (full text, mbox, reply):

From: Petter Reinholdtsen <pere@hungry.com>

To: castet.matthieu@free.fr

Cc: sysvinit-devel@nongnu.org, 582442@bugs.debian.org

Subject: Re: (fwd) Bug#582442: sysvinit: Failing to interrupt some script after upgrade

Date: Sat, 22 May 2010 18:24:23 +0200

[Matthieu Castet]
>> 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 ?

Scripts flagged interactive run alone with direct connection to the
tty, if I have understood how startpar work.  Not sure how that affect
^c behaviour.

Happy hacking,
-- 
Petter Reinholdtsen

Message #30 received at 582442@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Petter Reinholdtsen <pere@hungry.com>, 582442@bugs.debian.org

Cc: Matthieu Castet <castet.matthieu@free.fr>

Subject: Re: [Pkg-sysvinit-devel] Bug#582442: sysvinit: Failing to interrupt some script after upgrade

Date: Sun, 23 May 2010 00:36:20 -0300

On Thu, 20 May 2010, Petter Reinholdtsen wrote:
> [Matthieu Castet]
> > I interrupt sometimes fsck (when I don't want to wait), now this
> > doesn't work.
> 
> Wow.  You are braver than me.  I never considered that use case. :)

It is quite common.  Interrupting fsck if it is not in repair mode is safe,
and common.

SIGINT'ing the dhcp-client is also common.

Break that, and you will have a lot of people out after our blood...

Basically, if someone wants to ^C something, let them.

> The parallel starting is done by by startpar, so I guess that is the
> program that need to be adjusted.

Yeah. But how?  SIGINT, SIGTERM and SIGQUIT must be DWIM (do what I mean) in
a parallel boot scenario...  probably the best we can do is to have startpar
send the signal to all its children, and if it gets repeated signals in a
row [say, before it gets any SIGCHILD back], have it die.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #45 received at 582442@bugs.debian.org (full text, mbox, reply):

From: gregor herrmann <gregoa@debian.org>

To: 582442@bugs.debian.org

Subject: Re: Bug#582442: [Pkg-sysvinit-devel] Bug#582442: sysvinit: Failing to interrupt some script after upgrade

Date: Sat, 27 Nov 2010 18:42:59 +0100

[Message part 1 (text/plain, inline)]

On Sun, 23 May 2010 00:36:20 -0300, Henrique de Moraes Holschuh wrote:

> > > I interrupt sometimes fsck (when I don't want to wait), now this
> > > doesn't work.
> > Wow.  You are braver than me.  I never considered that use case. :)
> It is quite common.  Interrupting fsck if it is not in repair mode is safe,
> and common.

Right, I'm doing this on a regular base.
 
> Break that, and you will have a lot of people out after our blood...

Yup, I'm at least a  bit annoyed by the behaviour change :)


So, questions:
- Anything new on this issue? (No, I can't offer anything.)
- Is this really critical?

Cheers,
gregor
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-    BOFH excuse #185:  system consumed all the paper for paging 

[signature.asc (application/pgp-signature, inline)]

Message #50 received at 582442@bugs.debian.org (full text, mbox, reply):

From: Tommy van Leeuwen <chiparus@gmail.com>

To: 582442@bugs.debian.org

Subject: Bug#582442

Date: Wed, 15 Dec 2010 10:11:45 +0100

Is there any workaround available for this bug? We really need to be
able to interrupt the boot process.

We have some daemons hanging if we don't have a network or dns server
available. So we want to interrupt those.

We tried trapping the signal, setting stty, but nothing really works.

Add me to the list of people wanting to forcibly break our boot process :)

Cheers,
Tommy

Message #55 received at 582442@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: tommy@chiparus.org, 582442@bugs.debian.org

Subject: Re: [Pkg-sysvinit-devel] Bug#582442:

Date: Tue, 28 Dec 2010 11:30:35 -0200

On Wed, 15 Dec 2010, Tommy van Leeuwen wrote:
> Is there any workaround available for this bug? We really need to be
> able to interrupt the boot process.

Yes, disable concurrent boot.  It is what I have done on all my boxes and
set as policy for all servers at work.  Right now, it is more trouble than
it is worth when things go wrong, even on my laptop :(

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #60 received at 582442@bugs.debian.org (full text, mbox, reply):

From: "Steve M. Robbins" <steve@sumost.ca>

To: 582442@bugs.debian.org, 595431@bugs.debian.org

Subject: CTRL-C or parallel boot dichotomy

Date: Thu, 30 Dec 2010 16:49:38 -0600

[Message part 1 (text/plain, inline)]

On Tue, Dec 28, 2010 at 11:30:35AM -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 15 Dec 2010, Tommy van Leeuwen wrote:
> > Is there any workaround available for this bug? We really need to be
> > able to interrupt the boot process.
> 
> Yes, disable concurrent boot.

If I understand this issue correctly, the current situation is that
you have to choose between:

  a) concurrent boot
  b) ability to use CTRL-C safely


If that's true, then for the squeeze release, we could choose simply
to document this limitation prominently and tag this bug as
squeeze-can-defer.

Alternatively, could the code be changed slightly to ignore CTRL-C if,
and only if, the boot is concurrent?  That would remove the
possibility of creating an unusable system at boot time.  I had a
short look at the code but I don't think I could propose a patch
quickly.  

Also: it would be nice if CONCURRENCY were documented in manpage rcS(5).

Thoughts?
-Steve

[signature.asc (application/pgp-signature, inline)]

Message #65 received at 582442-close@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: 582442-close@bugs.debian.org

Subject: Bug#582442: fixed in sysvinit 2.88dsf-13.1

Date: Sat, 01 Jan 2011 05:47:35 +0000

Source: sysvinit
Source-Version: 2.88dsf-13.1

We believe that the bug you reported is fixed in the latest version of
sysvinit, which is due to be installed in the Debian FTP archive:

initscripts_2.88dsf-13.1_i386.deb
  to main/s/sysvinit/initscripts_2.88dsf-13.1_i386.deb
sysv-rc_2.88dsf-13.1_all.deb
  to main/s/sysvinit/sysv-rc_2.88dsf-13.1_all.deb
sysvinit-utils_2.88dsf-13.1_i386.deb
  to main/s/sysvinit/sysvinit-utils_2.88dsf-13.1_i386.deb
sysvinit_2.88dsf-13.1.diff.gz
  to main/s/sysvinit/sysvinit_2.88dsf-13.1.diff.gz
sysvinit_2.88dsf-13.1.dsc
  to main/s/sysvinit/sysvinit_2.88dsf-13.1.dsc
sysvinit_2.88dsf-13.1_i386.deb
  to main/s/sysvinit/sysvinit_2.88dsf-13.1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 582442@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ben Hutchings <ben@decadent.org.uk> (supplier of updated sysvinit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sat, 01 Jan 2011 03:45:28 +0000
Source: sysvinit
Binary: sysvinit sysvinit-utils sysv-rc initscripts
Architecture: all i386 source
Version: 2.88dsf-13.1
Distribution: unstable
Urgency: low
Maintainer: Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>
Changed-By: Ben Hutchings <ben@decadent.org.uk>
Closes: 582442
Description: 
 initscripts - scripts for initializing and shutting down the system
 sysvinit   - System-V-like init utilities
 sysvinit-utils - System-V-like utilities
 sysv-rc    - System-V-like runlevel change mechanism
Changes: 
 sysvinit (2.88dsf-13.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Disable SIGINT for non-interactive init scripts (Closes: #582442)
Checksums-Sha1: 
 a0c351bb29863c7a6940172059f7d44f66c1cf60 2159 sysvinit_2.88dsf-13.1.dsc
 e4deb4e3b37aff2f7b81cb371f79077e5c7b9d05 167932 sysvinit_2.88dsf-13.1.diff.gz
 a14ca695853625e4be73dd611668e27b9e73bc24 73140 sysv-rc_2.88dsf-13.1_all.deb
 1f953651ee4a1f4d798b1f529d8b57d535dd9074 115564 sysvinit_2.88dsf-13.1_i386.deb
 7ab0b88c24e2b802c0b058564d8020ee36e2c991 116444 sysvinit-utils_2.88dsf-13.1_i386.deb
 bc15095a4f7383afdd8f0369494e583493b71057 71172 initscripts_2.88dsf-13.1_i386.deb
Checksums-Sha256: 
 599e574988057ac3aaf4eb2926e389dbdce96f1fcb1d775e115b5f00c26d984e 2159 sysvinit_2.88dsf-13.1.dsc
 087cbfc222fc4fccbcbd63d7f507c94ece506e82f3d7a6f59f991df5b04a1b63 167932 sysvinit_2.88dsf-13.1.diff.gz
 8f9ed62be2f64baeca853f39e95adc312021883f145bfc34592adcee65a6068e 73140 sysv-rc_2.88dsf-13.1_all.deb
 0197239f70cfc1de5e4204cf6966af8ee1833d4424362de6054bfaed0d77460e 115564 sysvinit_2.88dsf-13.1_i386.deb
 7db522f12263166d939ad6b3fe643c3d2b019ac3474eb9842e1eae5b892a9513 116444 sysvinit-utils_2.88dsf-13.1_i386.deb
 fd29639933f6a5d646d4dfa67fbbd89ff985015265e912a9742dde6caa8931b8 71172 initscripts_2.88dsf-13.1_i386.deb
Files: 
 d554571081a3b5acba0fca4844c02821 2159 admin required sysvinit_2.88dsf-13.1.dsc
 a6f3707486b1f82a4593e8b12a81e650 167932 admin required sysvinit_2.88dsf-13.1.diff.gz
 437eab429125751663d0469c72b63099 73140 admin required sysv-rc_2.88dsf-13.1_all.deb
 ae32643072ffcc240368f1a3ec354fc7 115564 admin required sysvinit_2.88dsf-13.1_i386.deb
 eb633d54471ea21f10160318b63ee643 116444 admin required sysvinit-utils_2.88dsf-13.1_i386.deb
 fba4a3833e251e6156be29e2573e5322 71172 admin required initscripts_2.88dsf-13.1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIVAwUBTR6+lue/yOyVhhEJAQqBHRAA1LGJEPuQcFjsrFdgbz7m3Dwmw6cbbMd0
KrS3XSOZSDeYBZ4/hovoDUsjNKj73GtEDRqE3imFGs0H/GsqnY9PYEupuMK/Fx4y
XEl4wwPb9fTKtosjI7c3dg53YEH2Lu4BLWGHWCUVELvk/EaduHM9agHWEFXQyx26
eTodrG/vPN6NratUYsc8fo4IhUZFTF6lKxg41VvTAaxjLdaSM+2HgeaqckZDeTOf
MiwKjvdestotkxLiQmd+6Dq4eSpDLNVMbjHHndRGMCi8FB3NEOVdEjuGPHONaX1Z
1Ev6f/yUAfizAoyqPZwwHWYmwaGBu5J+ZLpbkLjLvcxHNdKbuiFAeSQQ7tCH019T
Pf1GqOOjGZa6DhzDVP6bRXvgLsMEQtYCbHSLfqHoei5zvZ9h5Zq9HN7v6ECrQYRE
NixYoTWgHpbKWZIvAxnaQi/ff8bQKRr83FK4ZgNCvPYOaBAzceEQ+pf388l7ryjE
4/HUdLLv/Mb9SoDZImHAaG1GscEZhhUqnk4sminZZbUBYYLnl0E/Mdw5Fel1SGrK
LTKdYmprJek/AhQaJna7TQea7+TNfsIMSf8ESXu8wX1ft4JpL1YnPj+luuwJC9o5
cTL4E7NKlnwZ6hd/ZCYDzKciQsJ6wqTQQExPTEERUwTofOaHNfGRbxamrnBLUNvb
fxSy2W0s6hI=
=laGv
-----END PGP SIGNATURE-----

Message #75 received at 582442@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: 582442@bugs.debian.org, 595431@bugs.debian.org

Subject: NMU diff for sysvinit 2.88dsf-13.1

Date: Sat, 01 Jan 2011 06:01:44 +0000

[Message part 1 (text/plain, inline)]

Note that this changes the behaviour only for non-interactive init
scripts, not for all init scripts in a parallel boot.  The current
behaviour of startpar when running interactive init scripts is correct
and it is a bug in initscripts that interrupting a periodic fsck is
treated as failure.  I have opened a separate bug (#608534) to cover
that (it's not possible to clone merged bugs).

Ben.

diff -u sysvinit-2.88dsf/debian/changelog sysvinit-2.88dsf/debian/changelog
--- sysvinit-2.88dsf/debian/changelog
+++ sysvinit-2.88dsf/debian/changelog
@@ -1,3 +1,10 @@
+sysvinit (2.88dsf-13.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Disable SIGINT for non-interactive init scripts (Closes: #582442)
+
+ -- Ben Hutchings <ben@decadent.org.uk>  Sat, 01 Jan 2011 03:45:28 +0000
+
 sysvinit (2.88dsf-13) unstable; urgency=low
 
   [ Kel Modderman ]
diff -u sysvinit-2.88dsf/debian/startpar/patches/series sysvinit-2.88dsf/debian/startpar/patches/series
--- sysvinit-2.88dsf/debian/startpar/patches/series
+++ sysvinit-2.88dsf/debian/startpar/patches/series
@@ -9,0 +10 @@
+09_noninteractive_ignore_sigint.patch
only in patch2:
unchanged:
--- sysvinit-2.88dsf.orig/debian/startpar/patches/09_noninteractive_ignore_sigint.patch
+++ sysvinit-2.88dsf/debian/startpar/patches/09_noninteractive_ignore_sigint.patch
@@ -0,0 +1,30 @@
+--- a/startpar.c
++++ b/startpar.c
+@@ -397,7 +397,6 @@
+   if (p->pid != 0)
+     return;
+ 
+-  (void)signal(SIGINT,  SIG_DFL);
+   (void)signal(SIGQUIT, SIG_DFL);
+   (void)signal(SIGSEGV, SIG_DFL);
+   (void)signal(SIGTERM, SIG_DFL);
+@@ -511,7 +510,9 @@
+ 
+   if (pid == 0)
+     {
++      /* Interactive init scripts may be interrupted */
+       (void)signal(SIGINT,  SIG_DFL);
++
+       (void)signal(SIGQUIT, SIG_DFL);
+       (void)signal(SIGSEGV, SIG_DFL);
+       (void)signal(SIGTERM, SIG_DFL);
+@@ -700,6 +701,9 @@
+   char *splashopt = 0;
+   int notty = 0;
+ 
++  /* By default, init scripts should not be interruptible */
++  (void)signal(SIGINT,  SIG_IGN);
++
+   (void)signal(SIGUSR1, sighandler_preload);
+   (void)signal(SIGUSR2, sighandler_nopreload);
+ 
--- END ---

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.