Bug#679630: insserv: Dependency-based boot changes SigIgn mask of daemons
[Michael Hanke] Unfortunately, the issue is still present -- on an up-to-date Debian wheezy. I still have no clue who to trigger this behavior other than a reboot of those machines. I can still reliably fix it by a restart of the condor daemons once the machines are fully up. Right. Then we should try to fix it. :) If there is anything I can try on those machines that would help you determine the problem please let me know. Please try this patch. It make sure run_single() and detach() both reset the SIGINT signal. Index: startpar.c === --- startpar.c (revision 192) +++ startpar.c (working copy) @@ -732,6 +732,7 @@ (void)sigfillset(nmask); sigprocmask(SIG_UNBLOCK, nmask, NULL); + (void)signal(SIGINT, SIG_DFL); (void)signal(SIGHUP, SIG_DFL); (void)signal(SIGQUIT, SIG_DFL); (void)signal(SIGSEGV, SIG_DFL); I suspect my test cases all ended up using the fixed code path. Not sure how to trigger the detach() code path in a test case. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679630: insserv: Dependency-based boot changes SigIgn mask of daemons
[Michael Hanke 2012-06-30] Hi, Hi again. In our squeeze-based cluster enabling dependency-based booting causes certain daemons to have different SigIgn masks -- more to the point, they start ignoring SIGINT. As you can imagine that has all kinds of implications (for the daemons and the processes they start). Are you still able to reproduce this? I'm trying to write a test case to trigger this bug, but am unable to do so. This is the test code I use, and it always report SigIgn: for both test scripts. What am I doing wrong? Note that you need startpar version 0.59 just uploaded to unstable to have support for the -e and -d options to use startpar without running scripts in /etc/init.d/. :) #!/bin/sh set -e if [ -z $STARTPAR ] ; then STARTPAR=../startpar fi mkdir -p etc/init.d touch etc/insserv.conf cat etc/init.d/test 'EOF' #!/bin/sh set -e ### BEGIN INIT INFO # Provides: test # Required-Start:$remote_fs # Required-Stop: $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: test script ### END INIT INFO echo success: the test script is running $1 echo signal mask for $$: cat /proc/$$/status | grep \(SigIgn\|Name\) EOF chmod a+rx etc/init.d/test cat etc/init.d/test2 'EOF' #!/bin/sh set -e ### BEGIN INIT INFO # Provides: test2 # Required-Start:$remote_fs # Required-Stop: $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: test script ### END INIT INFO echo success: the test2 script is running $1 echo signal mask for $$: cat /proc/$$/status | grep \(SigIgn\|Name\) EOF chmod a+rx etc/init.d/test2 /sbin/insserv -p etc/init.d test /sbin/insserv -p etc/init.d test2 $STARTPAR -d etc/init.d -e etc -P 1 -R 2 -M start rm -rf etc -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679630: insserv: Dependency-based boot changes SigIgn mask of daemons
Hi, On Thu, Apr 10, 2014 at 03:10:54PM +0200, Petter Reinholdtsen wrote: Are you still able to reproduce this? I'm trying to write a test case to trigger this bug, but am unable to do so. This is the test code I use, and it always report SigIgn: for both test scripts. What am I doing wrong? Note that you need startpar version 0.59 just uploaded to unstable to have support for the -e and -d options to use startpar without running scripts in /etc/init.d/. :) Thanks for keeping track of this one! Unfortunately, the issue is still present -- on an up-to-date Debian wheezy. I still have no clue who to trigger this behavior other than a reboot of those machines. I can still reliably fix it by a restart of the condor daemons once the machines are fully up. If there is anything I can try on those machines that would help you determine the problem please let me know. Thanks, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679630: insserv: Dependency-based boot changes SigIgn mask of daemons
Perhaps this problem with SIGINT and startpar was caused by the fix applied in URL: http://bugs.debian.org/582442 in 2010? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679630: insserv: Dependency-based boot changes SigIgn mask of daemons
Package: insserv Version: 1.14.0-2 Severity: important Hi, In our squeeze-based cluster enabling dependency-based booting causes certain daemons to have different SigIgn masks -- more to the point, they start ignoring SIGINT. As you can imagine that has all kinds of implications (for the daemons and the processes they start). Here is the symptom (ran on one of our compute nodes): root@snake1:~# cat /proc/*/status | grep \(SigIgn\|Name\) |egrep -B1 [0-9a-f][0-9a-f]+2$ Name: ypbind SigIgn: 0002 -- Name: condor_master SigIgn: 1002 -- Name: condor_startd SigIgn: 1002 -- Name: exim4 SigIgn: 1002 -- Name: cron SigIgn: 0002 -- Name: sshd SigIgn: 1002 root@snake1:~# grep CONCURRENCY /etc/init.d/rc |head -n1 CONCURRENCY=makefile As soon as I set CONCURRENCY to 'none' there is not a single process ignoring SIGINT running on the fully booted system. The SigIgn mask can be fixed by simply restarting the daemons after the system is fully booted -- for each and every single one: root@snake1:~# invoke-rc.d condor restart Shutting down Condor (fast-shutdown mode)... done. Starting up Condor...done. root@snake1:~# cat /proc/*/status | grep \(SigIgn\|Name\) |egrep -B1 [0-9a-f][0-9a-f]+2$ Name: ypbind SigIgn: 0002 -- Name: exim4 SigIgn: 1002 -- Name: cron SigIgn: 0002 -- Name: sshd SigIgn: 1002 root@snake1:~# invoke-rc.d exim4 restart Stopping MTA for restart: exim4_listener. Restarting MTA: exim4. root@snake1:~# cat /proc/*/status | grep \(SigIgn\|Name\) |egrep -B1 [0-9a-f][0-9a-f]+2$ Name: ypbind SigIgn: 0002 -- Name: cron SigIgn: 0002 -- Name: sshd SigIgn: 1002 root@snake1:~# invoke-rc.d crom restart invoke-rc.d: unknown initscript, /etc/init.d/crom not found. root@snake1:~# invoke-rc.d cron restart Restarting periodic command scheduler: cron. root@snake1:~# cat /proc/*/status | grep \(SigIgn\|Name\) |egrep -B1 [0-9a-f][0-9a-f]+2$ Name: ypbind SigIgn: 0002 -- Name: sshd SigIgn: 1002 root@snake1:~# invoke-rc.d ypbind restart invoke-rc.d: unknown initscript, /etc/init.d/ypbind not found. root@snake1:~# invoke-rc.d nis restart Stopping NIS services: ypbind ypserv ypppasswdd ypxfrd. Starting NIS services: ypbind. root@snake1:~# cat /proc/*/status | grep \(SigIgn\|Name\) |egrep -B1 [0-9a-f][0-9a-f]+2$ Name: sshd SigIgn: 1002 We have some indication that not only our cluster is affected (several condor user report SIGINT-ignore related problems on Debian squeeze). However there are also clusters that are not affected -- even with dependency-based booting enabled. Therefore there a chance that this is caused by something other than insserv. However, given the number of daemons affected, I decided to report this here. In any case, I can reliably change the SigIgn masks for all these daemons by enabled/disabling dependency-based booting -- and this should probably not be happening. Thanks, Michael -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/24 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages insserv depends on: ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib insserv recommends no packages. Versions of packages insserv suggests: pn bootchart none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679630: insserv: Dependency-based boot changes SigIgn mask of daemons
reassign 679630 sysvinit-utils retitle 679630 startpar: Concurrent booting change SigInt mask of daemons thanks [Michael Hanke] In our squeeze-based cluster enabling dependency-based booting causes certain daemons to have different SigIgn masks -- more to the point, they start ignoring SIGINT. As you can imagine that has all kinds of implications (for the daemons and the processes they start). Thank you for your report. It is most likely reported against the wrong package, as insserv only update the rc#.d/ symlinks, while startpar is the program starting services during boot. So it is not caused by Dependency-based boot ordering, but by concurrent booting. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
