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: Tue, 11 Sep 2012 23:24:38 +0000

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)




reply via email to

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