Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Jan 2002 20:36:14 +0100
From:      Stefan Esser <se@freebsd.org>
To:        Michael Scheidell <scheidell@secnap.net>
Cc:        hackers@FreeBSD.org, deraison@cvs.nessus.org, Stefan Esser <se@freebsd.org>
Subject:   Re: Re: Re: userland program panics freebsd 4.3
Message-ID:  <20020101203614.A11265@StefanEsser.FreeBSD.org>
In-Reply-To: <200112311631.fBVGVtZ45017@scanner.secnap.net>
References:  <20011231165828.D2301@StefanEsser.FreeBSD.org> <200112311631.fBVGVtZ45017@scanner.secnap.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-12-31 11:31 -0500, Michael Scheidell <scheidell@secnap.net> wrote:
> > (The second method, used only if there is no PROCFS, is to call
> > kill(PID, 0), which will check if a signal could be delivered.
> > That method should probably be prefered to the reading of procfs
> > anyway, since the latter takes 5 system calls instead of a single
> > one in the case of kill() ...)
> 
> would this patch fix it on the nessus side?, and it SEEMS to be faster.
> also, several 'core dumps' listed on nessusd.messages werein fact programs
> that also were listed as finished.

> @@ -898,6 +898,9 @@
>   if(!pid)
>     return 0;
> 
> +#ifndef FREEBSD
> +## panics FREEBSD 4.3 and 4.4, might be fixed in FREEBSD 4.5
> +
>   /*
>    * First method : attempt to open /proc/<pid>
>    * (we first check that we can open /proc/ourpid because
> @@ -917,6 +920,7 @@
>   else return 0;
>   }
> 
> +#endif

Yes, this will fix the port. But I'm not sure, whether the code that
will be used instead of reading /proc/<pid> could not be improved:

  /*
   * Second method, we attempt to use kill. But first, we
   * wait() for the process, just in case it's a zombie.
   */
  for(i=0,ret=1;(i<100) && (ret > 0);i++)
    ret = waitpid(pid, NULL, WNOHANG);

  return kill(pid, 0) == 0;

Instead of the for loop, I'd rather have:

  while(waitpid(pid, NULL, WNOHANG) == EINTR)
    /* do nothing */;

  return kill(pid, 0) == 0;

That way only a return code of EINTR will casue a retry of waitpid(),
while all other values rather indicate that waitpid() can not succeed,
no matter it is called with the same parameter set.

In fact, I'm not sure that the waitpid() call is required at all, since
there are places where children are being waited for ...

(And, looking at uses of waitpid(), I think some other loops should also
be changed as shown above, see for example wait_for_children() in file
nessusd/pluginlaunch.c).

My suggested patch to nessusd/utils.c (combining the #ifndef __FreeBSD__
and my change to the waitpid() loop, diff against nessus-1.1.11):

--- nessusd/utils.c~	Mon Dec 17 16:11:42 2001
+++ nessusd/utils.c	Tue Jan  1 19:48:27 2002
@@ -887,10 +887,10 @@
 process_alive(pid)
  pid_t pid;
 {
+#ifndef __FreeBSD__
  char procname[255];
  DIR * dir;
- int ret;
- int i;
+#endif
 
  /*
   * Invalid argument
@@ -898,6 +898,7 @@
  if(!pid)
    return 0;
 
+#ifndef __FreeBSD__
  /*
   * First method : attempt to open /proc/<pid>
   * (we first check that we can open /proc/ourpid because
@@ -916,13 +917,14 @@
 	}
  else return 0;
  }
+#endif 
  
   /*
    * Second method, we attempt to use kill. But first, we
    * wait() for the process, just in case it's a zombie.
    */
-  for(i=0,ret=1;(i<100) && (ret > 0);i++)
-    ret = waitpid(pid, NULL, WNOHANG);
+  while(waitpid(pid, NULL, WNOHANG) == EINTR)
+    /* do nothing */;
     
   return kill(pid, 0) == 0;
 }

(Note: This code has not been tested in a large network, but just in my
home LAN consisting of two machines ...)

Regards, STefan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020101203614.A11265>