Description of problem: Running '/sbin/service NetworkManager status' as an unprivileged user reports that NetworkManager is dead, even if it's alive and well. I blame this for many an unnecessary 'sudo /sbin/service NetworkManager restart'. Version-Release number of selected component (if applicable): 0.5.1-12.cvs20060213 How reproducible: Always Steps to Reproduce: 1. Run '/sbin/service NetworkManager status' as an unprivileged user. Actual results: NetworkManager dead but pid file exists Expected results: NetworkManager (pid XXX) is running... Additional info: There are at least two things going on here. The call to the 'status' function in the init script hasn't been modified to pass the new location of the pidfile (after bug #179903 was fixed) (quick fix: change 'status $processname' to 'status -p $pidfile $processname'). The 'status' function itself passes the -c flag to 'pidof', which due to a permissions problem, can't determine which root directory NetworkManager is using, and omits the right PID from its output. I don't really know how to get around this one. Maybe it should be calling pidofproc() instead of __pids_pidof()?
Ok, #1 fixed in CVS... #2 is cute, even the manpage of pidof says "This option does not make sense for non-root users". Hopefully this can get pushed to rawhide soon.
Created attachment 125353 [details] Use the pid file in status() Removing the -c can generate false positives in chroots. This patch is another way to add false positives :) by checking the pid file; if the daemon is killed and the PID is reused, status () may report a false positive. Note that this doesn't help when unprivileged users don't have the right to read the pid file (e.g. sendmail, {sys,k}logd).
That's a patch to initscripts. If work needs to happen there, it should go to notting.