Hello managers,
many thanks to those who answered:
Gerhard Nolte <gnolte_at_gwdg.de>
Lucio Chiappetti <lucio_at_ifctr.mi.cnr.it>
Dejan Muhamedagic <dejan_at_yunix.co.yu>
"Charles M. Richmond" <cmr_at_iisc.com>
All of them directed me to look at /var/run, and here is really found the
sendmail.pid file I missed before! Its contents:
8554
/usr/sbin/sendmail -bd -q15m
Both the date of its creation and pid match the last starting time of
sendmail and current sendmail process.
Gerhard Nolte sent an excellent sendmail script which is included beneath in
the message. My special greeting to you, Gerhard!
So, what remains without possible explanation is that IN MY SYSTEM the ps
command output (both /bin/ps and simply ps, with different flags!) has the
"command" field trancated... :
>/bin/ps auxww|grep sendmail
root 8554 0.0 0.4 2.10M 248K ?? S Oct 29 0:25.00 sendmail:
accepting connectio
>ps -e|grep sendmail
8554 ?? I 0:25.00 sendmail: accepting connectio
(:-0 must be some Hallowe'en consequence... or may be it's due to a high
inflation...)
Lucio Chiappetti running also 8.9.1 notes:
>Funny.
>I've noticed that sometimes the output of "ps" (in one of its many flavours)
>gets truncated according to the characteristics of the TERMINAL WINDOW it's
>running in !
>
>In my case however I also checked that the output of /bin/ps -e | grep
>sendmail is :
>
> 159 ?? I 0:00.02 sendmail: accepting connections o
>
>and the place where it truncates seems independent on the width of the
>terminal window I am running in.
The remark by Charles M. Richmond:
>Of more interest is the shortness of the ps -e output.
>Sendmail 8.9.0 gives:
>sendmail: accepting connections o
>While your output is:
>sendmail: accepting connectio
>Presumably this bug can be fixed in the 8.9.1 source.
Comment:
But Lucio Chiappetti also runs 8.9.1...
Following are the script sent by Gerhard Nolte and my original posting.
Thanks again,
Irene
*************************************************************************
* *
* Irene A. Shilikhina e-mail: irene_at_alpha.iae.nsk.su *
* System administrator, *
* Institute of Automation & Electrometry, *
* Siberian Branch of Russian Academy of Sciences, *
* Novosibirsk, Russia *
*
http://www.iae.nsk.su/~irene *
*************************************************************************
* * *
* Good intentions pave a path to * Every cloud has a silver lining. *
* the hell. * *
* * *
*************************************************************************
8< ---------------- cut here -------------------- >8
#!/sbin/sh
PATH=/sbin:/usr/sbin:/usr/bin
export PATH
MQUEUE=/var/spool/mqueue
#
# Number of days before pruning out dead files.
#
# TIMEOUT_QUEUERUN should be set to the number of days before a mail
# message is rejected, with RFC 1123 recommending a minimum of 4-5 days.
# This value should correspond (or be greater than) the value in the
# sendmail.cf file. By default, sendmail V8 uses 5 (O Timeout.queuerun=5d),
# while other sendmail pkgs typically used 3 (OT3d).
# CLEAN_MISC is used to clean out other queuefile cruft, while
# CLEAN_DEAD is used to clean out dead letters and core files.
#
# Note: find actually adds a day to these numbers, so if you specify
# 5, it will clean out files >= 6 days old.
#
TIMEOUT_QUEUERUN=5
CLEAN_MISC=2
CLEAN_DEAD=7
cleanqueue() {
# Cleans out any old files from the Queue directory.
#
# If you wish to save any file, rename it or put it in a subdirectory,
# e.g. $MQUEUE/save.d/core
# Find all the old files
find $MQUEUE \( \( -name '[xtlnQT]f*' -mtime +$CLEAN_MISC \) -o \
\( \( -name core -o -name dead.letter \) -mtime +$CLEAN_DEAD \) -o \
\( -name '[dq]f*' -mtime +$TIMEOUT_QUEUERUN \) \) -print |
while read name; do
# Remove *only* the files directly in $MQUEUE
if [ `dirname $name` = $MQUEUE ]; then
rm -f $name
fi
done
}
case "$1" in
'start')
if [ -f /usr/sbin/sendmail ]; then
# cleanqueue
/usr/sbin/sendmail -bi
# Use rcmgr to modify the command line args;
# if multiple "-q" args are given, the last one wins
/usr/sbin/sendmail -bd -q15m &
echo "SMTP Mail Service started"
else
echo "Unable to start SMTP Mail Service, No /usr/sbin/sendmail"
exit 1
fi
;;
'stop')
pid=`/usr/bin/head -n 1 /usr/var/run/sendmail.pid`
if [ "X$pid" != "X" ]; then
/bin/kill $pid
else
echo "No pid for SMTP Mail Service found"
exit 1
fi
;;
'restart')
/sbin/init.d/sendmail stop
if [ $? -ne 0 ]; then
echo " -- Could not find running sendmail - attempting to restart..."
fi
/sbin/init.d/sendmail start | sed -e 's/start/restart/'
;;
clean)
cleanqueue
;;
*)
echo "usage: $0 {start|stop|restart|clean}"
;;
esac
8< ---------------- cut here ------------------- >8
****************************************************************************
On Wed, 4 Nov 1998, Irene A. Shilikhina wrote:
>
> Hello managers,
>
> I'm not satisfied with my sendamail script in /sbin/init.d . Though in the
> documentation on sendmail 8.9.1 there is a sketch of a startup script it
> doesn't include those parts which stop and restart the sendmail daemon.
> At the same time, I've noticed some inadequacy in the concerned parts of
> the old sendmail script.
>
> The matter is that when having run "S40sendmail stop" the script prints
> the message "No pid for SMTP Mail Service found". Indeed, the script searches
> a process with a "command" field containing the word "connection" whereas
> ps command for this process gives only "sendmail: accepting connectio". (It
> seems that the string which argv[0] points to one character shorter than
> expected). I wouldn't like simply to delete one character from the command
> line in the script. I think startup script should be less dependent on a
> currently used version of sendmail program (actually, I don't remember
> whether this command line worked correctly with 5.65 version).
> In general, I wonder why it doesn't use a way of saving the Pid when calling
> the program as other scripts do. Is there something preventing from that
> in this case?
>
> If someone has got a script proved to be rather good for 8.9.1 could you
> please share it?
>
> Thanks,
> Irene
>
> P.S. About a circumstance when I had to restart sendmail daemon: because of
> problems with a communication channel I had to do it for moving the queue
> to a temporary place because it had become enormous.
Received on Thu Nov 05 1998 - 05:02:16 NZDT