[10839] in bugtraq
Re: Weird ps behavior
daemon@ATHENA.MIT.EDU (pedward@WEBCOM.COM)
Wed Jun 16 15:21:42 1999
Content-Type: text
Message-Id: <199906161904.MAA13469@eris.webcom.com>
Date: Wed, 16 Jun 1999 12:04:23 -0700
Reply-To: pedward@WEBCOM.COM
From: pedward@WEBCOM.COM
X-To: alpen@mections.net
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <37655E2B.4B738FAC@mections.net> from "alpen" at Jun 14,
99 03:55:24 pm
This bug is caused by a defective 'ps'. The /proc entries still exists for
the process, 'ps' just fails to list it because there is no corresponding
entry in the passwd file for that UID.
Try ps -aunx, that causes 'ps' not to lookup the user in the passwd file.
RedHat 6.0 ships with procps 2.0.2, this version displays '#UID' in the USER
column, where UID is the numeric UID, when the user isn't found in the passwd
file.
In short, upgrade to 2.0.2, the Documentation/Changes file lists procps 1.2.9
as a required package when changing to 2.2.
--Perry
>
> This bug falls under the category of programs doing the "wrong thing"
> (tm).
>
> Under linux 2.3.5 and procps version 1.2.2:
>
> When a user creates a process and it detaches from the current terminal,
> if the
> account is removed with the deluser,the process(es) stay active but
> disappear from
> the process table that ps (aux) scrolls. I would assume that it could be
> fixed if userdel checked for active processes and terminated them before
> removing the account. My C skills aren't
> good enough to diagnose whether the disappearing processes are is ps or
> a possible poor
> decision in the control of process tables in the kernel.
>
> Feedback?
> -alpen
>
--
Perry Harrington System Architecture zelur xuniL ()
perry@webcom.com and Administration Think Blue. /\
