Bug #1716

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

Added by ker2x about 5 years ago. Updated 5 months ago.

Status:In ProgressStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Userland
Target version:4.2.x

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 about 5 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 about 5 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 about 5 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 about 5 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 about 5 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 about 5 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 about 5 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 about 5 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

#9 Updated by tuxillo 5 months ago

  • Description updated (diff)
  • Category set to Userland
  • Status changed from New to In Progress
  • Assignee deleted (0)
  • Target version set to 4.2.x

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

Also available in: Atom PDF