[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/