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 18:38:56 +0000

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)




reply via email to

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