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 beginning: 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. Regards, -- Nicolas George
Attachment:
signature.asc
Description: Digital signature