1

I am working with Debian distro. I have wrote a backup bash script that implements snapshot rotation, it works like a charm when calling it interactively from shell but fails when invoked from cron job(of root user). In few places, in the script, I generate the target paths strings in this way, examples:

btrfs subvolume snapshot "$1/current" "$BASENAME-1"

or 

btrfs subvolume delete "$BASENAME-$NUM_BAK"

In the first case I create the first daily snapshot and in the second case I delete the last snapshot, which number is stored in the NUM_BAK var. The script file, as usual, starts with:

#!/bin/bash

But I have noticed that when invoked interactively the "$BASENAME-1", when $BASENAME is "/mnt/backup/daily", the final string become /mnt/backup/daily-1, when executed in cron the generated string becomes /mnt/backup/daily- with no final number.

The crontab line is:

52 1 0 * * * /root/backup-script/backupscipt.sh oneparam 2>&1 1>/mnt/logstuff/lastrun.log

I have tried different solutions.

1) Changin' crontab entry to: 

52 1 0 * * * /bin/bash /root/backup-script/backup.sh oneparam 2>&1 1>/mnt/logstuff/lastrun.log

2) Adding in crontab, first than the cron entry, this ones (as suggested here):

BASH_ENV="/root/.bashrc"
SHELL=/bin/bash

I'm not a shell expert and first to change all this bash script to a more 'deterministic' python script I like to understand where the problem is.

EDIT (Thanks for suggestions): I created a pruned version of my backup script that focuses on the string substitution. But the problem has disappeared.. I have to track down the problem to mysterious interactions. I'll update this question when I have more proofs.

#!/bin/bash

#Configurations:
BACKUP_PATH='/mnt/backup'
NUM_DAYS=5; #number of total days

backup (){
    BASENAME="$1/$2"
    NUM_BAK=$3

    #Clean older backup-snapshot
    echo "basename for backup is $BASENAME"
    echo "expect to delete: daily-5"
    echo "to delete: $BASENAME-$NUM_BAK"
    #real operation omitted

    for i in $(seq $(($NUM_BAK-1)) -1 1); do
    #Shift backups 2->3 1->2 and so on
      #with + works as expected
      echo "Shifting $BASENAME $i to $i+1"
    done

    #I expect .../daily-1 from the following:
    echo "expecting snapshot name daily-1"        
    echo "creating the snapshot $BASENAME-1"      
}

echo "Synching remote folder to current"

#rsync part omitted...
#...
#end rsync part

echo "Daily backup rotation started"
backup $BACKUP_PATH "daily" $NUM_DAYS
DevSolar
  • 67,862
  • 21
  • 134
  • 209
Fabiano Tarlao
  • 3,024
  • 33
  • 40
  • 2
    Generic shell scripting advice -- always enclose variables in curly braces, e.g. `${BASENAME}-1`. No ad-hoc idea what exacly your problem is or if this tip will do anything for you at this point, but it eliminates one common error source _and_ improves readability. – DevSolar Jun 19 '17 at 10:50
  • Is that all that is in the script? As there is no reason the number should disappear just for cron since it doesn't depend on any environment setup. – 123 Jun 19 '17 at 10:55
  • @DevSolar Thanks for the tip, I code bash scripts one time in a year and I forgot about this :-) – Fabiano Tarlao Jun 19 '17 at 10:55
  • @123 yes there are lot of commands and a function, I have focused on the lines where the problem emerges.. If the problem does not emerge from these I'll post the full code in a while. – Fabiano Tarlao Jun 19 '17 at 10:57
  • Try setting up a [mcve]. It doesn't need to do what your actual script / cronjob does, it just has to exhibit the same problem. (Some `echo` printing the variable to file should do it.) – DevSolar Jun 19 '17 at 11:03
  • @DevSolar, I added a pruned version of my script, the core is the backup function that implements the rotation. – Fabiano Tarlao Jun 19 '17 at 11:59
  • 2
    @FabianoTarlao: You misunderstood. Your problem is with the variable substitution. Not with `btrfs`, not with the surrounding logic. In searching for the cause of your problem, all that is just noise. Something along the lines of `echo "$BASENAME-1"` *should* suffice for the scope of this question. (Checking that it does is a debugging step that you should have done before even posting here, and it makes it easy for everyone to reproduce your problem locally. I, for example, don't have `btrfs` installed, so the script will fail for completely different reasons... – DevSolar Jun 19 '17 at 12:03
  • 1
    @DevSolar thanks for your suggestion, I have tested with a script focused on string concatenation and the problem has vanished, thanks for your tip, I'll look for what is triggering this behaviour (looking from exotic interactions), I'll update the question as fast as possible. – Fabiano Tarlao Jun 19 '17 at 12:57

0 Answers0