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

Re: Script vs command line behaviour



On Thu, Oct 13, 2016 at 12:09:12AM +0900, Mark Fletcher wrote:
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?

https://www.freedesktop.org/software/systemd/man/systemd.unit.html says

Conflicts=
A space-separated list of unit names. Configures negative requirement dependencies. If a unit has a Conflicts= setting on another unit, starting the former will stop the latter and vice versa. Note that this setting is independent of and orthogonal to the After= and Before= ordering dependencies.

If a unit A that conflicts with a unit B is scheduled to be started at the same time as B, the transaction will either fail (in case both are required part of the transaction) or be modified to be fixed (in case one or both jobs are not a required part of the transaction). In the latter case, the job that is not the required will be removed, or in case both are not required, the unit that conflicts will be started and the unit that is conflicted is stopped.

So you should, in theory, be able to add "Conflicts=mysql" to your unit and systemd will arrange for it to be stopped before running your unit, and started thereafter.


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


--
For more information, please reread.


Reply to: