According to John Nemeth:
>
>c) just rm the file (and the corresponding qf file); sendmail won't care,
>   at worst, you'll get a message in your syslog
>

OK - you are dodging the issue ;-)  Think of something that will need
restarting and then tell me you would rather talk someone through
working out which PID to zot instead of running a script....

>
>     When I was still doing PC support for machines running MS-DOS, I
>often had to tell people the difference between a semi-colon and a
>colon.  I felt like asking them if they had passed Grade 5 (it's
>amazing the number of people that don't know basic punctuation).
>

Exactly - I have had the same experience myself.

>
>     Actually, it would be TERM followed by KILL, and if it doesn't
>take kindly, then it is broken!  In fact, there is no guarantee of a
>chance to do a clean shutdown due to things like (sudden power failure,
>hardware failure, kernel panic, idiotic kernel which oversubscribes
>swap killing processes at random, sysadmin doing 'kill -9' on wrong
>process, etc.).

some of these can be helped but others cannot but it is no excuse for
not shutting things down correctly if you get the chance.  Do you just
pull the plug on your machine when you want to power it off or perform
an orderly shutdown?

>  In otherwords, it better be prepared to go down
>without notice and have some way of coming up cleanly.  Anything less
>is a major design flaw.  There is no excuse for not shutting down
>properly upon receipt of TERM.
>

Ahem - do you propose to tell Oracle (just an example) that?  What
about ufs? squid?  Lots of things keep state in memory.  As someone
else has rightly pointed out, sending a TERM to a lot of processes is
going to create a "thundering herd" syndrome where a lot of processes
are competing for limited resources.  Sending TERM also opens you to
races where some service may get hung up because the thing it is
depending on dies faster, with the K scripts you can order the
shutdown to avoid the races.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================