Hide Forgot
Description of problem: The /etc/init.d/sendmail status command will return a message that sendmail is running even if all that is running is someone running sendmail as an MUA - for instance, a long running cron job piping it's input into sendmail. root@narfle:~# service sendmail status sendmail (pid 1098) is running... root@narfle:~# ps -ef |grep sendmail joeuser 1098 1075 0 08:14 ? 00:00:00 /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t This stems from relying on the status function provided by /etc/init.d/functions, __pids_pidof, and the pidof command. Is there any way this could have a bit more intelligence? Or at least have pidof look for "sendmail:"? I get the same behavior with RedHat 5.6 as well. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Shut down the sendmail daemon to simulate a failure/misconfig 1. Make a long-running cron job with output 2. Check the service status while the cron job runs Actual results: service sendmail status says sendmail is running, returns the pid of the cron job sendmail. service sendmail stop kills the sendmail process that cron is using. Expected results: service sendmail status should say that sendmail is stopped/broken/whatever. service sendmail stop shouldn't kill other processes that happen to be named sendmail.
AFAIK pidof cannot be used this way (i.e. with sendmail:), but we could use the pid files as in RHEL-6.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Red Hat Enterprise Linux 5 entered Production 2 phase. The focus for minor releases during this phase lies on resolving urgent or high priority bugs. For more details see https://access.redhat.com/support/policy/updates/errata/. As this bug is not qualified as urgent or high priority it is closed with resolution WONTFIX. This issue is already fixed in Red Hat Enterprise Linux 6. If this issue is critical for your business you can escalate it through the support channel (http://www.redhat.com/support/).