help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-bash] backgrounding a process sends it into a tailspin


From: Cook, Rich
Subject: Re: [Help-bash] backgrounding a process sends it into a tailspin
Date: Wed, 12 Sep 2012 00:29:58 +0000

Dang, it's a cluster and I don't have console access -- everything's in an xterm. 
I tried echoing to a file, and the file was empty:  
ls -l trapped.txt
-rw-rw-r-- 1 rcook rcook 0 Sep 11 17:29 trapped.txt

here's the script I ran:

touch /g/g0/rcook/trapped.txt
for s in $(trap -l | sed 'S/[[:digit:]]\+)//g') ; do 
trap 'for c in $(jobs -p);do
echo kill -s '$s' $c >>/g/g0/rcook/trapped.txt
kill -s '$s' $c
done' $s
done 

logger()
  if [[ -x $IMG_TRACK ]]; then 
      "$IMG_TRACK" "$1" gnuplot-4.4.3 "$BASH_SOURCE" "$@"
  fi

IMG_TRACK=${IMG_TRACK:-/usr/local/tools/imgtrack-1.0/bin/imgtrack}
trap "logger END" EXIT
logger BEGIN
# using exec avoids a problem with gnuplot spinning up 100% CPU usage, but disables the "EXIT" trap above.  C'est la vie
 /usr/local/tools/gnuplot-4.4.3/bin/gnuplot.real "$@"


On Sep 11, 2012, at 5:22 PM, John Kearney wrote:


well you could try
for s in $(trap -l | sed 'S/[[:digit:]]\+)//g') ; do 
trap '
for c in $(jobs -p);do
echo kill -s '$s' $c >/dev/ttyn
kill -s '$s' $c
done' $s
done 
basically every signal.
and  echo what its doing to ttyn where ttyn is the tty of another console, for debug purposes

run pty in a second console to find its device





Am 12.09.2012 02:10, schrieb Cook, Rich:
Sadly, lacking imagination and information, I don't know what other signals to try trapping.  
If I understand correctly, the theory is that readline is being woken from slumber by some signal repeatedly.  
It looks to me more like readline is ignoring an error state.  
I'm 99% sure it's readline because sqlcipher which I also compiled against readline has the same exact issue, I see after playing around with it. 
I'm going to post on the readline mailing list to see what I can learn there.  
Thanks for the help here!  It's been very instructive. 

On Sep 11, 2012, at 4:59 PM, John Kearney wrote:

sry on my bb it autocaps.
yhea that can't work try instead
#!/usr/bin/env bash

trap '
for c in $(jobs -p);do
kill -s SIGTTIN $c
done' SIGTTIN

logger()
  if [[ -x $IMG_TRACK ]]; then 
      "$IMG_TRACK" "$1" gnuplot-4.4.3 "$BASH_SOURCE" "$@"
  fi

IMG_TRACK=${IMG_TRACK:-/usr/local/tools/imgtrack-1.0/bin/imgtrack}
trap "logger END" EXIT
logger BEGIN
 /usr/local/tools/gnuplot-4.4.3/bin/gnuplot.real "$@" &
wait



andif that doesn't work  

for s in SIGTTIN  SIG.... ; do 
trap '
for c in $(jobs -p);do
kill -s '$s' $c
done' $s
done 
i.e. try propagating other signals

Am 12.09.2012 01:37, schrieb Cook, Rich:
Hi, thanks for the suggestion. 
I tried that (using 'kill' instead of 'Kill' and 'for' instead of 'For') and it did not change behavior, still seems confused. 

#!/usr/bin/env bash

trap '
for c in $(jobs -p);do
kill -s SIGTTIN $c
done' SIGTTIN

logger()
  if [[ -x $IMG_TRACK ]]; then 
      "$IMG_TRACK" "$1" gnuplot-4.4.3 "$BASH_SOURCE" "$@"
  fi

IMG_TRACK=${IMG_TRACK:-/usr/local/tools/imgtrack-1.0/bin/imgtrack}
trap "logger END" EXIT
logger BEGIN
 /usr/local/tools/gnuplot-4.4.3/bin/gnuplot.real "$@"

On Sep 11, 2012, at 4:31 PM, <address@hidden>
 wrote:

You could try propagating the signal.

I.E. Add something like this to the start of your script.
trap '
For c in $(jobs -p);do
Kill -s SIGTTIN $c
done' SIGTTIN


Cheers 
Sent from my BlackBerry device

-----Original Message-----
From: "Cook, Rich" <address@hidden>
Sender: help-bash-bounces+address@hidden: Tue, 11 Sep 2012 23:24:38 
To: <address@hidden><address@hidden>
Cc: address@hidden<address@hidden>
Subject: Re: [Help-bash] backgrounding a process sends it into a tailspin

Yes, this sounds like a good analysis -- would a patch be in order here?  Can this be fixed?  I know it's an edge case so probably doesn't come up much.  

On Sep 11, 2012, at 4:14 PM, Chet Ramey wrote:

On 9/7/12 8:46 PM, Cook, Rich wrote:
Hello, 
I have built and installed gnuplot and wrapped it in a bash script.  The script simply makes a usage entry in a database, calls gnuplot, then notes that it exits.  I'm including the script below.  

When the user runs this script and puts it into the background, gnuplot immediately starts taking up 100% of a CPU, spinning in readline.  This only happens when gnuplot is wrapped in this way, not when it's called directly.  I would like to avoid this behavior, obviously, but I would also like to continue using a wrapper script.  What is it about being called from a script that is causing this odd behavior on gnuplot's part?  
I haven't looked at this at all, but it seems fairly clear that the problem
has to do with process groups and access to the terminal's foreground
process group.  gnuplot, not being used to running in the background,
doesn't have anything to ensure that it's in the right pgrp before
attempting to use readline to read from the terminal.

The signal that gnuplot gets is most likely SIGTTIN.  If it's not, ignore
the rest of this.

Starting the script in the background means that it will not be in the same
process group as its controlling terminal, which will result in SIGTTIN
every time the process tries to read from the terminal.

The non-job-control shell started to run the script getting in the middle
between the interactive shell running the script in the background and
gnuplot is complicating things, but probably not really the problem.  It
receives the SIGTTIN as well, but should have the disposition set to
SIG_DFL and get suspended.

Readline catches SIGTTIN so it can clean up the terminal attributes it
modifies.  It cleans up, ending with a call to tcsetattr from
rl_deprep_terminal, restores the old signal handler, and unblocks the
signal, letting it through to the application.  I'm not sure what gnuplot
does with it then, but I suspect it's catching it somehow and calling
readline again.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/
-- 
✐Richard Cook   
✇ Lawrence Livermore National Laboratory
Bldg-453 Rm-4024, Mail Stop L-557        
7000 East Avenue,  Livermore, CA, 94550, USA
☎ (office) (925) 423-9605    
☎ (fax) (925) 423-6961
---
Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.
(opinions expressed herein are mine and not those of LLNL)






-- 
✐Richard Cook   
✇ Lawrence Livermore National Laboratory
Bldg-453 Rm-4024, Mail Stop L-557        
7000 East Avenue,  Livermore, CA, 94550, USA
☎ (office) (925) 423-9605    
☎ (fax) (925) 423-6961
---
Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.
(opinions expressed herein are mine and not those of LLNL)






-- 
✐Richard Cook   
✇ Lawrence Livermore National Laboratory
Bldg-453 Rm-4024, Mail Stop L-557        
7000 East Avenue,  Livermore, CA, 94550, USA
☎ (office) (925) 423-9605    
☎ (fax) (925) 423-6961
---
Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.
(opinions expressed herein are mine and not those of LLNL)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]