What happens at 6:30 am (besides that fetchmail seems to crash)?

[Tom Metro]

Laura Conrad wrote:
> ...the fetchmail log stuff is written to both mail.log and syslog. 
> ... I have not figured out what rotates mail.log.

As Dan Ritter mentioned, I think you'll find that mail.log is being 
written to by sysklogd, and you'll probably want to tweak 
/etc/syslog.conf to eliminate the redundancy, if it bothers you. (I find 
that most distributions have default /etc/syslog.conf configurations 
that need tweaking.)


> For last night, I put "set no syslog" into /etc/fetchmailrc, and 
> fetchmail seemed to still be running at 7...

Now that you've established that fetchmail is logging through syslog, 
and thus logrotate should have no reason to be killing and restarting 
fetchmail, that reduces, but doesn't eliminate logrotate as the culprit. 
I wouldn't expect changing how fetchmail writes its logs to have any 
effect on whether it doesn't get restarted. It's the logrotate side of 
things where you want to take a closer look.

Given that fetchmail can potentially write directly to its own logs, 
there may be a script in /etc/logrotate.d/ for fetchmail. This script 
may be unnecessarily restarting fetchmail, even if the 
fetchmail-specific log file isn't present. If you find a fetchmail 
script in that directory, try moving it elsewhere. (I use a DISABLED/ 
subdirectory for that purpose. logrotate will ignore scripts in 
subdirectories.)


> ...but I couldn't find a log file anywhere...
> I can't figure out how to make fetchmail write to a log other than 
> syslog (and mail.log).  I have tried "set logfile
> /var/log/fetchmail", and that doesn't seem to do anything.

I'm not sure how you specify a log file in the conf file either, but 
this FAQ entry:

http://fetchmail.berlios.de/fetchmail-FAQ.html#O1

mentions a --logfile command line option. More importantly, it explains 
that fetchmail will only write to the file if it already exists. So what 
you tried may have worked if you had 'touch'ed the file prior to 
restarting fetchmail.

Unless you prefer to have fetchmail log to its own file, you might as 
well stick with using syslog, as either way it won't help your restart 
problem.


> As far as what cron says about what it's doing when, it does send a 
> mail, but only when there are errors.  So this morning at 6:30, I had
> one mail from man-db saying that a man page had a dangling link, but
> nothing from logrotate or sysklogd.

logrotate is notorious for providing poor diagnostics (see the string of 
bug reports in the Debian bug tracker). It can be tough to diagnose 
intermittent problems that occur in scripts ran by logrotate. Sometimes 
you can find them by running logrotate directly, optionally with the 
--debug switch.

One of the complications is that the logrotate scripts often redirect 
errors to /dev/null to prevent generating clutter from routine status 
messages. So you'll want to examine any suspect logrotate scripts and 
remove such redirection temporarily.

Also, on Debian systems, you'll find that some daemons are restarted in 
logrotate scripts by directly invoking the binary or directly invoking 
the init script, but they ought to be restarted using invoke-rc.d(8). It 
provides a --quiet option, to suppress error text, but still returns 
status codes. Eventually the logrotate scripts will get updated, but you 
might want to update the script yourself.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.