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 do not know the exact rules systemd applies to the processes started by a
> timer, but it is entirely possible this is the source of your problem.
> Remember when all the systemd haters started shouting "systemd broke screen
> and tmux" because the option to clean up the processes in finished user
> sessions had been activated by default.
>
You bring up a good point, actually. I'm calling systemctl stop and
systemctl start to stop and start mysql -- and I'm doing that in a
script that is itself being called by a systemd unit (the one triggered
by the timer). I wonder if that is in some way naughty and contributing
to the problem? Hmmm, is there a better way to ensure these services are
stopped before the backup starts and started again afterwards?
Although that said, MySQL and SVNServe (which are started by systemd) go
down and come back up fine, it is the one that ISN'T currently
controlled by systemd that I am having problems with.
Hmmm, interesting, although I'm not sure quite what to do with that...
Mark
Reply to: