Le duodi 22 vendémiaire, an CCXXV, Mark Fletcher a écrit :
> 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?

This is exactly the correct way of proceeding: with systemctl start, you are
not directly starting the service (like you did with /etc/init.d/something
start, with all the drawbacks it implies, like user environment bleeding
into the service); instead, you are sending a message to systemd to tell it
to start the service.

From your point of view, it does not change anything, but as a design, it is
much cleaner.

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

It IS controlled by systemd, everything is. But you neglected to inform
systemd there was something special about it.

You can debug what happens to your script by adding this line near the

strace -f -e execve -s 10000 -o /tmp/my_script.$$.$(date +%Y%m%d%H%M%S) &

Tomorrow, the file in /tmp will tell you what happened.

Note that the idea of the stale PID file is worth checking still.


  Nicolas George

Attachment: signature.asc
Description: Digital signature

Reply via email to