On Wed, Oct 12, 2016 at 05:17:20PM +0200, Nicolas George wrote:
> 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.

OK I added that line near the beginning of my script, after the intial 
comments at the beginning and before it actually does anything.

I also commented out the line that actually invokes Amanda, for testing 
purposes. So I can do all the setup before a backup, and all the 
tear-down afterwards, but not actually do the backup.

I then ran the script by doing systemctl start homebackup (the service 
is called homebackup.service and the timer is called homebackup.timer)

The script definitely ran -- I can tell because one of my Windows VMs is 
running right now and the disklist for Amanda got updated to exclude the 
running VM, the logic to do which is only contained in this script. Both 
VMs were down overnight when he last real backup was performed, so both 
VMs were included in the last backup. Ergo, this run of the script 
changed the amanda disk list. Ergo, it ran.

But there is no my_script.<anything> in /tmp... WhaFu? I copied the line 
you put in your email into my script exactly, and then spent a while 
with the man page so I could understand what it was doing, and I think 
it should have worked... but it didn't.

The script takes a couple of seconds to run (when the call to amdump is 
commented out, it would take a good couple of hours otherwise) so 
further evidence it is doing something...

In the meantime, I have had another idea which I suspect will work... 
I'm proposing to dump my user-local configuration of fetchmail, and copy 
my .fetchmailrc to /etc/fetchmailrc (said file does not currently exist 
on my machine), making sure permissions and ownership are appropriate of 
course, and then modify /etc/default/fetchmail to set START_DAEMON=yes 
instead of no, then add a "set daemon 900" line to the copied 
/etc/fetchmailrc, and let the systemwide fetchmail handle my mail 
fetching. This is already set up as a systemd service and runs 
automatically on boot, so I can then modify my script to do systemctl 
stop fetchmail to stop it and systemctl start fetchmail to start it 
again at the end of my script, just like I am doing with mysql.

Given that mysql is being correctly stopped and started by that approach 
already in the script, I have some confidence that fetchmail will too. 

systemctl stop fetchmail and systemctl start fetchmail correctly stop 
and start it from the command line.

I'd like to know if there is something wrong with that strace command, 
or if there is greater sensitivity than I gave it credit for to where it 
is put in the script, but I suspect this approach of using the 
systemwide fetchmail is going to nail it.


Reply via email to