Date: Wed, 12 Oct 2016 08:34:22
From: Mark Fletcher <mark27q1@gmail.com>
To: debian-user@lists.debian.org
Subject: Script vs command line behaviour
Resent-Date: Wed, 12 Oct 2016 12:34:43 +0000 (UTC)
Resent-From: debian-user@lists.debian.org
Greetings
I am observing a strange behaviour and I am wondering what stupid thing
I have done that is causing it. A shell command that is supposed to
start fetchmail running every 15 minutes works fine run from the command
line, but has no effect when run from inside a script. I am running
Jessie upgraded many times from an original install from etch, I think
it was. Or squeeze. Whichever of those two it was that came first.
I recently took the plunge and installed Amanda to get my backups
organised. At the moment I am only backing up the one machine but will
expand it later to other machines on my network.
Automating the Amanda backup once I was happy with the configuration
prompted me to write a small bash shell script, reproduced below. It
expects to run as root. It stops the svnserve instance running on my
machine and a mysql instance, and also stops the fetchmail daemon. Then
it starts with a basic amanda config and, if my Windows VMs are not
running, adds their disks and config directories to the stuff that is in
scope for backup. If they are running it refrains from including them.
Then, it kicks off the backup, running as the backup user. Finally, it
restarts the services it stopped.
Then I have created a systemd service to run this script, and set up a
systemd timer to kick off the pocess at 01:30 local time every day.
It runs fine, at the right time, except for one thing. When I get up in
the morning and come to my computer, I find that the backup report is
sitting in my email reporting success, SVNServe is running as it should
be, mysql is running as it should be -- but fetchmail has not been
restarted.
If I do sudo journalctl -b | grep fetchmail and look at this morning's
entries, I see the following:
Oct 12 01:30:02 kazuki sudo[2197]: root : TTY=unknown ; PWD=/ ;
USER=mark ; COMMAND=/usr/bin/fetchmail -q Oct 12 01:30:02 kazuki
homebackup.sh[2154]: fetchmail: background fetchmail at 31717 killed.
Oct 12 04:19:04 kazuki sudo[3582]: root : TTY=unknown ; PWD=/ ;
USER=mark ; COMMAND=/usr/bin/fetchmail -d 900
[lines justified to be easier to read]
The first of those lines indicates the script successfully stopped
fetchmail at 01:30 before starting the backup.
The second would appear to indicate at least that it correctly attempted
to start fetchmail again, as my non-privileged user mark, at 04:19 when
the backup finished. But, when I came to my computer at about 07:30 this
morning, fetchmail was not running and all the mails to this list from
you lovely people were backed up at my email provider waiting to be
downloaded.
I started fetchmail by hand from the command line, and came home this
evening to find it still running sweetly. And it'll continue to do so
until tonight's backup run kills it, at which point I'll get up tomorrow
morning to find it is not running again, if the experience of the last
few days is anything to go by.
If I copy and paste the line that is supposed to restart fetchmail from
the script (reproduced below) to a root shell, with PWD=/, and run the
command, it works, correctly. I am stumped why it is not working from
the script. Anyone see what I have missed? I wondered if it was paths
not being set right, but from the above journal log you can see it
correctly mapped the fetchmail instance to /usr/bin/fetchmail.
/etc/systemd/scripts/homebackup.sh:
#! /bin/bash
# THIS ASSUMES MYSQL AND SVNSERVE ARE RUNNING, AND WE WANT THEM RUNNING
# AGAIN ONCE DONE
# stop a couple of services we don't want running while doing backups
systemctl stop mysql
systemctl stop svnserve
# The systemctl stop for svnserve may not work as I haven't got around to
# making a stop script for it.
# So kill the process the old fashioned way
ps -ef | grep svnserve | grep -v grep | awk '{print $2}' | xargs kill -9
# And kill fetchmail so it doesn't update the mail while we are backing up
sudo -u mark fetchmail -q
# Start with the base disklist
cp /etc/amanda/RealBackup/disklist.stem /etc/amanda/RealBackup/disklist
# If the two VirtualBox VMs are NOT running, add them to the disk list
sudo -u mark vboxmanage showvminfo "TRADER2" | grep -q "running (since" || echo localhost /opt/vms/TRADER2 comp-user-tar >> /etc/amanda/RealBackup/disklist
sudo -u mark vboxmanage showvminfo "TRADER2" | grep -q "running (since" || echo "localhost "\""/home/mark/VirtualBox VMs/TRADER2"\"" comp-user-tar" >> /etc/amanda/RealBackup/disklist
sudo -u mark vboxmanage showvminfo "TRADER3" | grep -q "running (since" || echo localhost /opt/vms/TRADER3 comp-user-tar >> /etc/amanda/RealBackup/disklist
sudo -u mark vboxmanage showvminfo "TRADER3" | grep -q "running (since" || echo "localhost "\""/home/mark/VirtualBox VMs/TRADER3"\"" comp-user-tar" >> /etc/amanda/RealBackup/disklist
# Now actually run the backup
sudo -u backup amdump RealBackup
# and restart the services we stopped
systemctl start svnserve
systemctl start mysql
sudo -u mark fetchmail -d 900
Mark