bug-bash
[Top][All Lists]
Advanced

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

Re: jobs -p falsely reports the last background pid


From: Håkon Bugge
Subject: Re: jobs -p falsely reports the last background pid
Date: Thu, 10 Apr 2014 17:37:38 +0200

On 10. apr. 2014, at 17.14, Chet Ramey wrote:

> On 4/9/14, 6:43 AM, Håkon Bugge wrote:
> 
>> Bash Version: 4.2
>> Patch Level: 45
>> Release Status: release
>> 
>> Description:
>> This script never terminates:
> 
> Bash holds on to processes and their status until it's notified the user
> about the status of terminated processes.  It's especially careful to hold
> onto the status of the current job (the last background job started) until
> the user's been notified.  It seems like you're making unwarranted
> assumptions about what `jobs -p' will return.

It seems to be so, although I must claim, based on "help jobs", that a job, for 
which its process has disappeared (no sign of it in /proc/<pid> in Linux), is 
still is considered an _active_ job is not natural for me. But your point is 
that the job is _active_ until its status has been conveyed to the user.

Any work-around would do for me. The script is just a very simple version of 
what was going on. I am running a system with a Verilog simulation of a PCIe 
adapter, using a virtual PCI adapter (vPCI) in a virtual node (KVM), and are 
running "real" applications using the simulated hardware. I was just waiting 
for the user space applications to terminate, which takes hours due to the 
verilog simulation (RTL cycle-by-cycle simulator).

In this environment, where 196 jobs was launched, and all but one terminated in 
the sense that "jobs -p" didn't list their PIDs, I was sure I had a complicated 
error elsewhere since the very last one did not terminate...

Anyway, I am fine with any of the proposed work-arounds, and do not have any 
strong opinion whether this is to be considered a bug or not.


Thanks, Håkon


> 
> You have a couple of choices:
> 
> 1.  Use `wait', which, as Greg suggested, is much better suited for this
>    task.
> 
> 2.  Since you're interested in running jobs, ask for running jobs using
>    `jobs -rp' instead of running `jobs -p' and assuming things about the
>    output.
> 
> 3.  Throw a call to `jobs' in there so the shell thinks it's notified the
>    user about terminated jobs.  This is essentially the reason that it
>    `works' in an interactive shell: the shell does the notification about
>    terminated jobs asynchronously when it's interactive.
> 
> Chet
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/




reply via email to

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