an alternative to fuser in progress_bar.sh

George Boudreau georgeb at linuxfromscratch.org
Fri Jun 30 13:45:41 PDT 2006



Dan Nicholson wrote:
> On 6/28/06, George Boudreau <georgeb at linuxfromscratch.org> wrote:
>>
>> Dan Nicholson wrote:
>> > On 6/28/06, George Boudreau <georgeb at linuxfromscratch.org> wrote:
>> >>
>> >>   # note.. DO NOT try and trace the variable makePID..
>> >>   # it changes the fuser text
>> >> makePID=$(fuser -v . 2>&1 | grep make)
>> >> makePID=$(echo $makePID | cut -d" " -f2)
>> >>
>> >> write_or_exit() {
>> >>
>> >>      # make has been killed or failed or run to completion, leave
>> >>    [[ ! -e /proc/$makePID ]] && echo -n "${CURSOR_ON}" && exit
>> >>
>> >>      # Target build complete, leave.
>> >>    [[ -f ${TARGET} ]] && echo -n "${CURSOR_ON}" && exit
>> >>
>> >>      # It is safe to write to the screen
>> >>    echo -n "$1"
>> >> }
> 
> I see you already checked this in, but I just wanted to confirm that
> it works for me in the normal use case (root running ./lfs or make).
> 
>> > Yes!  Why didn't I think of that before?  It's a little bit of a hack
>> > since that pid could be reused, but the chances of that happening in
>> > between write_or_exit pollings is obviously miniscule.  Way better.
>>    Actually the pid of make cannot be reused until 'make' terminates at
>> which point the progress_bar script dies of loneliness (no one to play
>> with). The progress_bar script normally exits when a target is
>> successfully built and the makefile touches nnn-target. The other test
>> is there to catch target build failures or makefile abnormal termination.
> 
> What I was thinking was this situation (and all its unlikeliness).
> During the .12 seconds between invoking write_or_exit(), make has been
> interrupted and another process has started and grabbed the same pid.
> If progress_bar.sh is still running in the background, it passes both
> of the tests on the next call of write_or_exit().  The ${makePID}
> exists and $(TARGET) doesn't exist.  It's a very minor race condition.
>
   My kernel work is a bit rusty but I believe PID's are sequentially 
allocated. To reuse a pid you have to cycle through 2^15 numbers (minus 
the ones already in use.) I will concede the point about the PID reuse, 
but it is as unlikely to occur as it is to come across an honest 
politician. I have a way to handle to former but won't hold my breath 
waiting for the latter.

   [[ ! $(cat /proc/$makePID/cmdline 2>/dev/null) = "make" ]] &&
        echo -n "progress bar dies:${CURSOR_ON}" && exit

   IF the process reusing the PID is also 'make' I will eat my monitor.( 
with a salsa)

> -- 
> Dan



More information about the alfs-discuss mailing list