jobs in scripts?

jobs in scripts?

[Dan Muresan]

Hi, is the following normal? With set -m the problem disappears; bash
& ksh don't need set -m.

SUSv3 doesn't say job control is to be disabled completely unless "set
-m" is active. And, if job control *is* disabled, why does "job"
report a non-empty list?

0.5.5.1-3ubuntu2 on Ubuntu 10.04 here.

---

$ cat x
#set -m
sleep 100 &
echo "Before kill:"; jobs -l
kill -s TERM %1
sleep 0.5
echo "After kill:"; jobs -l
pidof sleep



$ dash x
Before kill:
[1] + 18775 Running
kill: 4: No such process

After kill:
[1] + 18775 Running
18775


-- Dan

Re: jobs in scripts?

[Jilles Tjoelker]

On Tue, Mar 08, 2011 at 09:02:30PM +0200, Dan Muresan wrote:
> Hi, is the following normal? With set -m the problem disappears; bash
> & ksh don't need set -m.

> SUSv3 doesn't say job control is to be disabled completely unless "set
> -m" is active. And, if job control *is* disabled, why does "job"
> report a non-empty list?

> 0.5.5.1-3ubuntu2 on Ubuntu 10.04 here.

> ---

> $ cat x
> #set -m
> sleep 100 &
> echo "Before kill:"; jobs -l
> kill -s TERM %1
> sleep 0.5
> echo "After kill:"; jobs -l
> pidof sleep

> $ dash x
> Before kill:
> [1] + 18775 Running
> kill: 4: No such process

> After kill:
> [1] + 18775 Running
> 18775

See the description of "set" in XCU 2.14 Special Built-In Utilities. It
is deliberate that "jobs" still works, as "set -m" only enables putting
jobs in separate process groups and various notices that are only
meaningful in interactive mode (there are no prompts in non-interactive
mode, therefore the notices about completed and stopped background jobs
do not happen, and if a foreground job stops in non-interactive mode
this tends to lead to unexpected results).

That much is clear. However, "kill" and "jobs -p" are less clear. Their
descriptions depend on the process group of a job, which does not exist
if job control was disabled when the job was started -- in that case the
job is run in the shell's process group. This could be interpreted as an
implicit requirement on the application that the job must have been
started with job control enabled if "kill" or "jobs -p" are to be used
on it.

In your case, I recommend getting the PID via $!. This allows 'kill'
without depending on obscure corners of shells.

If your script runs for a long time, use of $! should be paired with
'wait' (either for all $! values obtained or without parameters) so that
the shell can forget about old jobs. Some shells are buggy and remember
the jobs anyway.

-- 
Jilles Tjoelker

Re: jobs in scripts?

[Dan Muresan]

Thanks. Well, I am currently using PIDs, $!, kill $pid and kill --
-$pgrp. However, I noticed that **even if I don't wait** for a
background job, the shell somehow auto-reaps dead children:

$ dash -c 'sleep 1 & echo "PID $!"; sleep 1000' &
[1] 7840
PID 7841
$ ps ax | grep [7]841
$

So, since dead children get reaped (instead of becoming zombies for a
while), their PIDs are not "reserved". After a PID wrap-around at
32767, a different process could get the same PID. That makes PIDs
unreliable. I could end up killing a completely unrelated process,
instead of a (possibly zombified) child.

That's why I thought I'd try to see if "jobs" could work more reliably.

> That much is clear. However, "kill" and "jobs -p" are less clear. Their

I only need plain "jobs"... I used "jobs -l" as a convenience in the
example I gave, but plain "jobs" would be enough.

Unfortunately, it seems the "kill %n" does indeed refer to process
groups. I didn't realize this means the shell is not guaranteed to
support "kill %n" unless "set -m" is in effect (and, again, there are
problems with set -m in dash).


-- Dan