Bug 200920 - shutting down sm-client fails
shutting down sm-client fails
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: sendmail (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
David Lawrence
Depends On: 119429
  Show dependency treegraph
Reported: 2006-08-01 12:16 EDT by Thomas Woerner
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHSA-2007-0252
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-01 13:12:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Thomas Woerner 2006-08-01 12:16:38 EDT
+++ 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@sun.ac.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@acm.org 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@redhat.com on 2004-04-08 09:41 EST --
fixed in sendmail-8.12.11-4.5

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

-- Additional comment from adam@axisproductions.com 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@redhat.com on 2004-06-23 15:30 EST --
Does this fix look ok to you Thomas?


-- Additional comment from sean@inreview.com 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@poczta.fm 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 -eq 0 ] && rm -f /var/run/sm-client.pid
                [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sm-client
        return $RETVAL

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

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`

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 -eq 0 ] && rm -f /var/run/sm-client.pid

-- Additional comment from twoerner@redhat.com on 2006-07-19 06:08 EST --
Fixed in rawhide in package sendmail-8.13.7-3 or newer.
Comment 1 RHEL Product and Program Management 2006-08-18 10:51:34 EDT
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
Comment 5 Red Hat Bugzilla 2007-05-01 13:12:24 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.