Re: AW: Re: enbd 2.4.32/kernel 2.6.12.3 pid file problem

"Also sprach u.schmeling:"
> >Very strange - any progress on identifying the process that has its pid
> >in the lock file?


> The pid is the pid of the enbd shell script

Then it would appear that that shell script writes the pid file ...

#########################################################################
# look at a given pidfile. Return OK if nonexistent or stale and
# put our pid in the pidfile.
# Return BAD if it contains a pid of a running process,
#
 try_lock() {
   local pidfile="$1"
   if [ -s "$pidfile" ] ; then

      local pid="`head -1 $pidfile`"

      # grrr ... tr is not always available at boot, so can't trim
      # easily

      for p in $pid ""; do
        pid=$p ; break
      done

      case $pid in
        *[^0-9]*) echo bad pid $pid read from $pidfile && return 1 ;;
      esac

      if [ -n "$pid" ] && [ "$pid" -gt 0 ] ; then
        kill -0 "$pid" 2>&1 >/dev/null && return 1
      fi
   fi
   rm -f $1
   local mytmp="`mydirname $pidfile`/.try_lock_`mybasename $pidfile`.$$"
   touch $mytmp || return 1
   if ! echo $$ >> $mytmp ; then
     rm -f $mytmp
     return 1
   fi
   if ! ln $mytmp $pidfile; then
     rm -f $mytmp
     return 1
   fi
   rm -f $mytmp
   return 0
 }

 ...
 start_client() {
    local id=$1
    echo -n starting $CLIENTNAME $id
    shift
    try_lock /var/run/${CLIENTNAME}-$id.pid || return
    ...


Uh huhhhhh. It looks like my diagnosis was correct, but the criminal
was not who I expected it to be!

Now I wonder what one should do about that! It's amusing. 

The problem is that the launch script needs to know there is only one
copy of itself running. Ahem. I really guess it should use a different
name for the pidfile them. Maybe ...

   try_lock /var/run/launch-${CLIENTNAME}-$id.pid || return


Other suggestions? (Apart from "don't do that then" :-).





Peter