[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Script vs command line behaviour



On Wed, Oct 12, 2016 at 09:56:06AM -0400, Greg Wooledge wrote:
> 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?
> 

Fetchmail isn't set up as a service through systemd, although mysql and 
svnserve are. fetchmail is just started from this script (or supposed to 
be!) and launched by hand from the command line when that fails.

So at least systemd isn't complicating the issue. I'll want to get a 
service wrapped around fetchmail _eventually_ so it starts automatically 
on boot, but I haven't gotten around to that yet. Once I do, then I'll 
have to replace the command in this script with a systemctl start 
command, but I don't want to just cut to that without understanding what 
is going on here.

> 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....
> 

Yeah, I think I'll have to try some combination of these ideas. In a 
strange way I'm encouraged actually, I was half-cringing expecting 
someone to go "Mark, you idiot, you've done XYZ stupid thing, duh!"

Mark


Reply to: