Re: Script vs command line behaviour

[Greg Wooledge <wooledg@eeg.ccf.org>]

On Wed, Oct 12, 2016 at 10:40:57PM +0900, Mark Fletcher wrote:
> ...Any thoughts on what is preventing the restart of fetchmail from 
> working?

Nothing in particular.  I haven't used fetchmail in many years, and
never as a "service" at the system level.  So, just general thoughts:

1) Use "systemctl status fetchmail" to see what the operating system
   thinks is happening.  Are the service process(es) still running, or
   did they terminate?  Are there informative messages?  How long did
   they run before terminating, if they did terminate?

2) Look for fetchmail-specific logs.  If you've defined a logfile location,
   look there.  Otherwise, figure out how fetchmail normally logs, and
   look where it does that.  Maybe it logs through syslog(), in which
   case you'd look for some file in /var/log, unless you've changed
   the syslog configuration to send those somewhere else.  Or maybe it
   has its own default logging location outside of the syslog()
   infrastructure.

3) If the current logs are not detailed enough, look for fetchmail-specific
   options to increase logging verbosity.

4) Log what your backup script does.  Since it's a shell script, this is
   generally done with something like:

#!/bin/sh
exec >> /var/tmp/mylog 2>&1
echo "==== New backup started: $(date)"
set -x

Adjust to suit your needs.  This isn't *likely* to uncover the problem,
unless you get something blazingly obvious like:

Failed to start ftechmail.service: Unit ftechmail.service failed to load: No such file or directory.

But as I said, these are just general thoughts about how to approach
this *kind* of problem.  And hey, you never know....