In article <tpgi.com.au>,
Stuart J. Browne <com.au> wrote:
Are you 100% sure that the non-os custom ap isn't contributing to
the problem. Some applications have been known to send mail - you
know like LP does when a job is canceled. Sending mail to
an unknown user on the system can cause a lot of 'undelivered
Next time don't reboot the machine but kill sendmail. The go
look at the messages in the queue. What does the ouptut of
'mailq' tell you. Look at the headers and see if you can spot the
If it cures everytime you restart and don't find the problem before
you restart you are going to be having this until you determine
what is causing it.
So what does 'ls' give you. If it's too slow you probably have
thousands in the queue and sorting them is going to take time so
just type echo *. Output will be a mass all on one line, but
pipe it through wc and you'll get an idea.
Why do you think upgrading witll cure this if you haven't found
the problem? I'm not being facetious. You say the only change
was a non-os application. If everthing was find until then it
surely points a finger at that application. Of course if many
people have root access anything could be wrong. And an upgrade
instead of a complete reinstall could carry the problem forward.
I also doubt that is a problem.
You are looking at the wrong logs. Look at the sendmail logs.
Your clue should be there.
And what 'bare directory' did you make?
Unix systems DO NOT need to be rebooted in my experience unless
it's something that has to do with a kernel related problem. That's
based on 20 years with *n*x systems.
I've used sendmail as the MTA for two ISPs and it just doesn't
problems as you have described. I really bet it is NOT sendmail
acting funny but something else causing it to aculate tonnes of
Bill Vermillion - bv wjv . com