+++ This bug was initially created as a clone of Bug #243707 +++ Description of problem: The rstatd and rusersd init scripts return wrong error codes. There are also constructions in these scripts that prevent correct status command call, for example: if [ ${NETWORKING} = "no" ] then exit 0 fi Version-Release number of selected component (if applicable): all How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: When fixing this bug, please obbey our init script guidelines and be sure that status command is run correctly. Our guidelines are on following two pages: http://intranet.corp.redhat.com/ic/intranet/InitscriptsSpec.html http://intranet.corp.redhat.com/ic/intranet/InitscriptGuidelines.html For an example of the script that returns the error codes correctly and always runs status see: http://devserv.devel.redhat.com/~mmarcini/amd This bug is tracked by 237789.
As RHEL-4.9 is last update for RHEL-4 and it is not suitable for new features and should address only security, performance and critical issues, I'm moving the bugzilla to RHEL-5. Init script was fixed in RHEL-6.
Created attachment 505075 [details] proposed patch for rusersd.init and rstatd.init This patch fixes rusersd.init and rstatd.init using the following changes: * fixes a return code when networking isn't up in rusersd.init and this test is moved to start/stop actions * tries to start portmap if stopped in rstatd.init (the same behavior as it already is in rusers.init) * checks if binding to portmap was successful in both init scripts (this is a simple way how to find out if a child has been initiated correctly, while the parent process always returns "0" right after fork) Any comments to this patch are welcome.
This bug has been fixed in RHEL-6 and there is no chance to fix this in RHEL-5 any more, since RHEL 5.10 is going to include only serious fixes.