Re: Script vs command line behaviour
On Wed, Oct 12, 2016 at 10:36:40AM -0400, Gene Heskett wrote:
> On Wednesday 12 October 2016 09:40:57 Mark Fletcher wrote:
>
> > On Wed, Oct 12, 2016 at 08:40:12AM -0400, Greg Wooledge wrote:
> > > On Wed, Oct 12, 2016 at 09:34:22PM +0900, Mark Fletcher wrote:
> > > > # The systemctl stop for svnserve may not work as I haven't got
> > > > around to # making a stop script for it.
> > > > # So kill the process the old fashioned way
> > > > ps -ef | grep svnserve | grep -v grep | awk '{print $2}' | xargs
> > > > kill -9
> > >
> > > Please consider replacing this with some variant of:
> > >
> > > pkill svnserve
> > >
> > > And stop using -9 (SIGKILL). Forever. Pretend it never existed.
> >
> > ...Any thoughts on what is preventing the restart of fetchmail from
> > working?
> >
> > Mark
>
> My best guess is a stale lock file, leftover because you used the brute
> force kill, so it did not exit gracefully, cleaning up after itself. My
Uh no I didn't, not for fetchmail. It was svnserve I brute force killed.
And svnserve starts again just fine. Greg's led you down the garden path
by zeroing in on what is evidently a pet peeve of his but actually has
nothing to do with the problem.
I shut down fetchmail with fetchmail -q which is how the man page says
to do it.
>
> # and restore fetchmail but let the disks synch first
> sleep 6
> fetchmail -d 180 --fetchmailrc /home/gene/.fetchmailrc
>
> This has not failed in many years.
I wonder if passing the --fetchmailrc option will work. The systemd
journal snippet I included in my original post shows that fetchmail is
getting started successfully -- but by the morning it's not running.
Now, clearly nothing gets past me, but that means it's terminating.
Which suggests it doesn't know what it is supposed to do once it is
started. Which suggests maybe it's not finding the fetchmailrc file?
I'm going to try specifying where .fetchmailrc is for tonight's run and
see what happens.
Will report back in the morning. If this nails it, it suggests that
something is screwy about the environment when run from a systemd script
(that's only ever been root) compared to running it from a root terminal
(which was logged in as mark, then su'd to root)
Mark
Reply to: