Red Hat Bugzilla – Bug 185429
"Stray" processes after a bootup
Last modified: 2008-03-10 22:17:45 EDT
Description of problem:
Even after a boot to a single-user mode, or any other level, one can see
in a process table:
root 159 0.0 0.0 0 0 ? S 11:42 0:00 [kswapd0]
root 313 0.0 0.1 2044 688 ? Ss 11:42 0:00 /bin/nash /init 1
root 391 0.0 0.0 0 0 ? S 11:42 0:00 [kjournald]
root 455 0.4 0.1 8608 952 ? S<s 11:42 0:00 /sbin/udevd -d
'/sbin/udevd -d' is likely what we want but '/bin/nash' should be gone by
now. Is this a problem of a stuck nash or 'init' script on initrd is not
Maybe 'nash' should know how to "exec"? It does not seem to have that
capability. Or it should terminate anyway but it is not doing it?
Version-Release number of selected component (if applicable):
One, rather unclean, way to deal with that would be to put
'pkill nash' somwhere in startup scripts after file systems got
mounted (it is /usr/bin/pkill or use /bin/kill with /sbin/pidof
but then an output of pidof needs to be checked).
Otherwise we are still mapping deleted executables.
Try 'cat /proc/$(pgrep nash)/maps' to see.
What version of initscripts do you have installed? They should be doing:
killall nash-hotplug >/dev/null 2>&1
just before starting udev, and that should kill this process. (nash-hotplug is
the name, but ps displays argv rather than the actual process name)
> What version of initscripts do you have installed?
initscripts-8.31-1. This is the current version available.
> They should be doing ...
Well, yes, they do on line 168 of /etc/rc.d/rc.sysinit
but clearly this is not terminating that process.
Oh, I see. 'killall' is /usr/bin/killall and /usr is mounted later.
If you want that at this point then you need something like
nashpid=$(/sbin/pidof nash); [ "$nashpid" ] && /bin/kill $nashpid
This works. 'pidof nash-hotplug' is empty. Otherwise that killall
can be used further down.
So this looks like initscripts problem.
This bug is still present in FC5 with all updates available 2006-05-08
Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 7 or
> Is this bug still present in Fedora 7 or Fedora 8?
Hm, let's have a look (which surely you could do equally well
yourself). Tap, tap, tap .... No, apparently not. At least
in an updated Fedora 7 because, IIRC, it was still present just
after a 7 release - although I would not swear that at this moment.