[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: pidof misses a pid sometimes
From:       Matthias Andree <mandree () FreeBSD ! org>
Date:       2011-12-27 10:43:30
Message-ID: 4EF9A152.4020806 () FreeBSD ! org
[Download RAW message or body]

Am 26.12.2011 15:32, schrieb Bastian Bittorf:
> dear embedded warriors,
> 
> we use "BusyBox v1.19.3 (2011-11-24 08:39:59 CET)"
> on ar71xx and brcm47xx (mipsel) on openWRT.
> 
> It took us some days to trac down a problem with
> pidof. We have some checker scripts, which regulary
> watch for tasks, if they are running or not using 'pidof'.
> Sometimes we catch an error but in fact everything is ok,
> but pidof returns an empty list.
> 
> The best thing: it's reproduceable (attached and inline):
> 
> #!/bin/sh
> 
> mywget()
> {
>         local url="http://127.0.0.1/favicon.ico"
>         local pidnum pidbackground mycmdline pidbackground pidlist
> 
>         ( wget -qO - "$url" 2>/tmp/error_wget.$$.txt || echo "$?"
>> /tmp/error_wget.$$.rc ) &
>         pidbackground="$!"
>         pidlist="$( pidof wget )"

Whatever you're trying to do here, the pidof is bogus, and the /proc
fiddling is non-portable and time-critical.

Use the shell's wait builtin.

> IMHO the problem is located in libbb/find_pid_by_name.c

The culprit is the non-robust design of your script, not busybox's
implementation.

There is a reason why Unix has concepts like sessions, process groups,
parent-child relationships between processes, and thereabouts, and that
is to make your whole rig reliable.  It's hard to come by all the
details in shell scripts though, so consider using other means that
allow better control over descendant processes.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]