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

[Cook, Rich]

For completeness, here is the script I ran that hung: 

#!/usr/bin/env bash
output=/dev/pts/3
rm -f /g/g0/rcook/trapped.txt
touch $output
for s in $(trap -l | sed 's/[[:digit:]]\+)//g') ; do 
    echo "setting trap for $s" /dev/pts/3
    trap 'for c in $(jobs -p);do
echo kill -s '$s' $c >/dev/pts/3
kill -s '$s' $c
done' $s
done 
echo "traps set" >/dev/pts/3

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
strace /usr/local/tools/gnuplot-4.4.3/bin/gnuplot.real "$@"


On Sep 12, 2012, at 11:38 AM, Cook, Rich wrote:

> Aha, well, strace shows me I think why the "& wait" trick of address@hidden 
> didn't work: 
> 
> ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffffffd180) = -1 ENOTTY 
> (Inappropriate ioctl for device)
> 
> However, if I use strace without "& wait", then typing "^Z" causes the 
> process to hang.  ^C, everything is ignored.  
> 
> Here is the output up to that moment, 
> 
> rt_sigaction(SIGINT, {0x463e60, [INT], SA_RESTORER|SA_RESTART, 0x3cc300f4a0}, 
> {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGTERM, {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 
> {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 
> {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGALRM, {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 
> {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 
> {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 
> {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 
> {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGWINCH, {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 
> {0x32e0626d80, [], SA_RESTORER|SA_RESTART, 0x3cc300f4a0}, 8) = 0
> rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
> ioctl(0, TIOCGWINSZ, {ws_row=47, ws_col=109, ws_xpixel=1109, ws_ypixel=944}) 
> = 0
> ioctl(0, TIOCSWINSZ, {ws_row=47, ws_col=109, ws_xpixel=1109, ws_ypixel=944}) 
> = 0
> ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) 
> = 0
> ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = > 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> rt_sigprocmask(SIG_BLOCK, [INT QUIT ALRM TERM TSTP TTIN TTOU], [], 8) = 0
> rt_sigaction(SIGINT, {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 
> {0x463e60, [INT], SA_RESTORER|SA_RESTART, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGTERM, {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 
> {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGQUIT, {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 
> {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGALRM, {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 
> {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGTSTP, {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 
> {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGTTOU, {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 
> {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigaction(SIGTTIN, {0x32e0626ea0, [], SA_RESTORER, 0x3cc300f4a0}, 
> {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> rt_sigaction(SIGWINCH, {0x32e0626d80, [], SA_RESTORER|SA_RESTART, 
> 0x3cc300f4a0}, {SIG_DFL, [], SA_RESTORER, 0x3cc300f4a0}, 8) = 0
> rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
> write(1, "gnuplot> ", 9gnuplot> )                = 9
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
> read(0, 
> 
> Yes, the output stops right there... 
> 
> On Sep 12, 2012, at 11:12 AM, Chet Ramey wrote:
> 
>> On 9/12/12 12:34 PM, Cook, Rich wrote:
>>> I already supplied a stack trace -- do you think that strace would show 
>>> more information?  
>> 
>> It would confirm which signal gnuplot/readline is receiving.  That's what
>> I'm interested in.
>> 
>> -- 
>> ``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)