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 really correct? 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): mkinitrd-5.0.32-1 How reproducible: every time
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. Maybe timing? 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 Fedora 8?
> 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.