Re: Script vs command line behaviour
On Wed, Oct 12, 2016 at 04:29:01PM +0200, Nicolas George wrote:
> Le primidi 21 vendémiaire, an CCXXV, Mark Fletcher a écrit :
> > 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.
>
> Maybe it is. Unlike SysV init and the other legacy tools, systemd keeps
> tracks of the processes it starts, grouping them as "units" using pgroups.
> Your script tries to start fetchmail in background, using the -d option
> (which, by the way, is not present in the man page for the testing version,
> unless I have trouble reading); that would allow it to escape SysV init and
> cron, for example, but not systemd.
>
I don't know about testing, but in Jessie, the description starts at
line 1236 of the man page.
Also, I'm sorry, I suspect you may be right at the crux of the issue,
but I don't completely understand what you mean. Are you saying that,
even though the command to start fetchmail is not an invokation of a
systemd unit, the fact that it is happening from inside a script that is
run by a systemd unit somehow allows systemd to capture the PID for
fetchmail, and that that in turn is having a bearing on my being able to
restart it? If so, I don't understand the mechanism at work here, and
I'm lost as to what to do about it.
My next step is to try your other suggestions re searching for log files
and increasing logging in the script; will report back on what that
finds.
Stupid question -- if I comment out the actual backup command from the
script, can I then run the script at will in the same environment it
would be kicked off by the timer by using systemctl start <servicename>?
The _timer_ is enabled (linked to multi-user.wants) so it starts at
boot, would starting the _service_ have the effect of running
immediately and would that have any nasty side effects? I'm looking for
a way to not have to wait until the next backup run to test the
suggestions that have been made.
Mark
Reply to: