Description of problem: When sendmail is shutdown (manually or at reboot/shutdown), a message is issued that shutting down sm-client FAILED
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.