Bug #1716
closedcan't stop "bmake" (without args) in /usr/pkgsrc
0%
Description
step to reproduce the problem :
- Fresh install of 2.6.1
- cd /usr
- make pkgsrc-create
- cd /usr/pkgsrc
- bmake
- press ^c (ctrl-c) after a few seconds
- you get the shell prompt, but some process (look like "configure" stuff) keep
running in the background and flood your terminal. doing a "killall bmake" (or
killall -9 bmake) doesn't help.
Updated by elekktretterr over 14 years ago
On Wednesday 07 April 2010 07:02:27 laurent laborde (via DragonFly issue
tracker) wrote:
New submission from laurent laborde <kerdezixe@gmail.com>:
step to reproduce the problem :
- Fresh install of 2.6.1
- cd /usr
- make pkgsrc-create
- cd /usr/pkgsrc
- bmake
- press ^c (ctrl-c) after a few seconds
- you get the shell prompt, but some process (look like "configure" stuff)
keep running in the background and flood your terminal. doing a "killall
bmake" (or killall -9 bmake) doesn't help.
I can confirm this is an isssue.
Petr
Updated by ahuete.devel over 14 years ago
Hi,
Well, yes. A lot of bmake process will be spawned and you will have a
bad time to stop them all. What I use to do the to run a ton of
'killall -9 bmake' very fast until there are no processes left. Of
course this is just a rude workaround, but it gives you the chance to
avoid the reboot :P
Cheers,
Antonio Huete
2010/4/7 Petr Janda <elekktretterr@exemail.com.au>:
On Wednesday 07 April 2010 07:02:27 laurent laborde (via DragonFly issue
tracker) wrote:New submission from laurent laborde <kerdezixe@gmail.com>:
step to reproduce the problem :
- Fresh install of 2.6.1
- cd /usr
- make pkgsrc-create
- cd /usr/pkgsrc
- bmake
- press ^c (ctrl-c) after a few seconds
- you get the shell prompt, but some process (look like "configure" stuff)
keep running in the background and flood your terminal. doing a "killall
bmake" (or killall -9 bmake) doesn't help.I can confirm this is an isssue.
Petr
Updated by dillon over 14 years ago
The main problem with bmake is that it temporarily sets a signal
handler to SIG_IGN before setting it to something else. This
means that when a ton of bmakes are running hitting ^C will often
be ignored by some of them. DragonFly is doing the right thing, it's
bmake which has to be fixed.
-Matt
Updated by swildner over 14 years ago
Am 07.04.2010 09:37, schrieb Matthew Dillon:
The main problem with bmake is that it temporarily sets a signal
handler to SIG_IGN before setting it to something else. This
means that when a ton of bmakes are running hitting ^C will often
be ignored by some of them. DragonFly is doing the right thing, it's
bmake which has to be fixed.
As far as I remember, our make(1) has the same bug. It can be triggered
quite easily (at least here) by going to /usr/src, do 'make clean' and
trying to ^C it. I just tried it.
Sascha
Updated by steve over 14 years ago
On Wed, 7 Apr 2010 09:26:48 +0200
Antonio Huete Jimenez <ahuete.devel@gmail.com> wrote:
Hi,
Well, yes. A lot of bmake process will be spawned and you will have a
bad time to stop them all. What I use to do the to run a ton of
'killall -9 bmake' very fast until there are no processes left. Of
course this is just a rude workaround, but it gives you the chance to
avoid the reboot :P
while killall -9 bmake; do cat /dev/null; done
Should do the job and drop out when they're all gone.
Updated by dillon over 14 years ago
: while killall 9 bmake; do cat /dev/null; done
:
: Should do the job and drop out when they're all gone.
:
:-
:Steve O'Hara-Smith | Directable Mirror Arrays
This is primarily due to a bug in bmake. bmake temporarily SIG_IGN's various signals before installing their signal handler so if a lot of bmakes are running and you hit ^C, sometimes some don't get killed.
-Matt
Updated by dillon over 14 years ago
:As far as I remember, our make(1) has the same bug. It can be triggered
:quite easily (at least here) by going to /usr/src, do 'make clean' and
:trying to ^C it. I just tried it.
:
:Sascha
There might be another issue with signal races and fork(). The only two possible issues are programs ignoring ^C and a signal race in fork() (where the signal gets caught during the fork() but the child is then created and never gets the signal).
-Matt
Updated by swildner over 14 years ago
Am 07.04.2010 18:29, schrieb Matthew Dillon:
There might be another issue with signal races and fork(). The only
two possible issues are programs ignoring ^C and a signal race in
fork() (where the signal gets caught during the fork() but the
child is then created and never gets the signal).
I've looked a bit at this with tuxillo and in our make's case it's -B
(compatMake == true) which exposes the buggy behavior.
compatMake is false when you use -j and true when you don't. As soon as
I run 'make -j 1 clean' it no longer fails.
Sascha
Updated by tuxillo almost 10 years ago
- Description updated (diff)
- Category set to Userland
- Status changed from New to In Progress
- Assignee deleted (
0) - Target version set to 4.2
Hi all,
Many changes have gone in since this was originally reported.
Can somebody please reproduce this one and see if the issue still persists?
Cheers,
Antonio Huete
Updated by tuxillo about 3 years ago
- Status changed from In Progress to Closed
We don't use pkgsrc anymore. bmake is now in base and it's been heavily updated since then. Closing this.