Bug 200920

Summary: shutting down sm-client fails
Product: Red Hat Enterprise Linux 4 Reporter: Thomas Woerner <twoerner>
Component: sendmailAssignee: Thomas Woerner <twoerner>
Status: CLOSED ERRATA QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: 13640887, twoerner, warek
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHSA-2007-0252 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-05-01 17:12:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 119429    
Bug Blocks:    

Description Thomas Woerner 2006-08-01 16:16:38 UTC
+++ This bug was initially created as a clone of Bug #119429 +++

Description of problem:

When sendmail is shutdown (manually or at reboot/shutdown), a message
is issued that shutting down sm-client FAILED

-- Additional comment from 13640887.za on 2004-04-05 13:50 EST --
This seems to be SELinux related.

With my default install (i.e. all packages, selected all the default
options regarding SELinux when installing), I get the following in
/var/log/maillog when starting up sendmail and sm-client after logging
in as root (using the root:sysadm_r:sysadm_t context):

Apr  5 19:53:28 asok sm-msp-queue[28799]: unable to write
/var/run/sm-client.pid: Permission denied

Thus, sm-client doesn't start, but you still receive the OK message
(not good). So when you shut down sm-client, the FAILED message appears.

With setenforce 0, sm-client starts up and shuts down without problems.

-- Additional comment from czar on 2004-04-05 13:57 EST --
Good point.  This was submoitted before I realized that a lot of these
really needed to be reported against the policy package.

-- Additional comment from dwalsh on 2004-04-08 09:41 EST --
fixed in sendmail-8.12.11-4.5

-- Additional comment from czar on 2004-04-12 10:48 EST --
Installed the update sendmail.  Shutdown for sm-client still fails.

-- Additional comment from adam on 2004-05-10 11:12 EST --
commenting out these 2 lines in the sendmail init.d script fixed the 
problem for me:

       touch /var/run/sm-client.pid
       chown smmsp:smmsp /var/run/sm-client.pid

sendmail will not write to the sm-client.pid file if it already 
exists (touched & chowned), even if the permissions are correct, 
unless the file is world writeable (strange indeed).

if the file does not exist, sendmail will create it:

-rw-------    1 root     smmsp          49 May 10 08:18 sm-client.pid

this fixed the unable to write maillog error on my system, and fixed 
the script itself (--check and killproc were not functioning 
correctly due to the pid file not being written)

i'm using sendmail-8.12.8-9.80


-- Additional comment from dwalsh on 2004-06-23 15:30 EST --
Does this fix look ok to you Thomas?

Dan

-- Additional comment from sean on 2004-10-23 22:08 EST --
If it's helpful/related, I've just upgraded to BIND 8.13.1 on RH9 and 
sm-client also FAILED on "stop" directive to the /etc/init.d/sendmail 
rc script. I've found that if I wait a few seconds, it does indeed 
stop OK if I run the stop script again. It seems like the program has 
some sort of internal cleanup tht takes longer than is required for 
this OK/FAILED check on exit. (?) I was also having problems when old 
sendmail processes were still running. I had to killall sendmail at 
one point to get them to go away, possibly from all the stop 
failures, but start successes I'd been getting.


-- Additional comment from warek on 2005-02-04 07:10 EST --
The problem exist also in Fedora Core 3. If we look at
/etc/init.d/sendmail starting script we see:

...
        if test -f /var/run/sm-client.pid ; then
                echo -n $"Shutting down sm-client: "
                killproc sm-client
                RETVAL=$?
                echo
                [ $RETVAL -eq 0 ] && rm -f /var/run/sm-client.pid
                [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sm-client
        fi
        return $RETVAL
}
...

So it basically checks wheather /var/run/sm-client.pid exist na if it
does it
executes:

killproc sm-client (notice that /var/run/sm-client.pid is empty)

killproc checks whether /var/run/sm-client.pid is empty an then tries
to find out pid of the process:
...
     if [ -z "$pid" ]; then
                pid=`pidof -o $$ -o $PPID -o %PPID -x $1 || \
                        pidof -o $$ -o $PPID -o %PPID -x $base`
        fi
...

unfortunately $1 = $base = sm-client and process name is in fact
sendmail that's why it doesn't kill the second process. Quick patch to
make it working:

--- sendmail.orig       2005-02-04 13:05:11.725648784 +0100
+++ sendmail    2005-02-04 13:04:57.837760064 +0100
@@ -108,7 +108,7 @@
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sendmail
        if test -f /var/run/sm-client.pid ; then
                echo -n $"Shutting down sm-client: "
-               killproc sm-client 
+               killproc sendmail 
                RETVAL=$?
                echo
                [ $RETVAL -eq 0 ] && rm -f /var/run/sm-client.pid

-- Additional comment from twoerner on 2006-07-19 06:08 EST --
Fixed in rawhide in package sendmail-8.13.7-3 or newer.

Comment 1 RHEL Program Management 2006-08-18 14:51:34 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 5 Red Hat Bugzilla 2007-05-01 17:12:24 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2007-0252.html