Bug 119429

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.

Good point.  This was submoitted before I realized that a lot of these
really needed to be reported against the policy package.

fixed in sendmail-8.12.11-4.5

Installed the update sendmail.  Shutdown for sm-client still fails.

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

Does this fix look ok to you Thomas?

Dan

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.

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

Fixed in rawhide in package sendmail-8.13.7-3 or newer.