Re: Script vs command line behaviour
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.
Mark
Reply to: