Bug #1716

can't stop "bmake" (without args) in /usr/pkgsrc

Added by ker2x over 4 years ago. Updated over 4 years ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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.

History

#1 Updated by elekktretterr over 4 years ago

On Wednesday 07 April 2010 07:02:27 laurent laborde (via DragonFly issue
tracker) wrote:
> New submission from laurent laborde <>:
>
> 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

#2 Updated by ahuete.devel over 4 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 <>:
> On Wednesday 07 April 2010 07:02:27 laurent laborde (via DragonFly issue
> tracker) wrote:
>> New submission from laurent laborde <>:
>>
>> 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
>

#3 Updated by dillon over 4 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

#4 Updated by swildner over 4 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

#5 Updated by steve over 4 years ago

On Wed, 7 Apr 2010 09:26:48 +0200
Antonio Huete Jimenez <> 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.

#6 Updated by dillon over 4 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
Matthew Dillon
<>

#7 Updated by dillon over 4 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
Matthew Dillon
<>

#8 Updated by swildner over 4 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

Also available in: Atom PDF