Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 16
I use my Raspberry Pi with 2 USB HDDs as a backup for 2 PCs. Raspbian is installed. I send data from the 2 PCs using a program called AllwaySync ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Dec 2013
    Posts
    12

    Why does my error trap not work from a scipt at boot time?


    I use my Raspberry Pi with 2 USB HDDs as a backup for 2 PCs. Raspbian is installed. I send data from the 2 PCs using a program called AllwaySync to 1 HD, daily and overnight I use a bash script to copy that data to the other HDD unattended. The script runs at boot time and the boot is initiated by a timer switch.

    The script I use is in /usr/local/bin/ and is called from rc.local. This works perfectly, sending me emails each time it boots for whatever reason.

    I decided I should add an error trap which I tested from a terminal and it worked perfectly, sending me the error information by email.

    I added the trap into the top of the working backup script but now find that although the script completes as it did previously, if I create a deliberate error, it is not trapped and the script still completes.

    Why does the trap work from a terminal but not at boot time?

    Code:
    #!/bin/bash
    
    # error trap follows
    f () {
        errcode=$? # save the exit code as the first thing done in the trap function
    
    v1="Error "
    v2=$errcode
    v3=" the command executing at the time of the error was " 
    v4=$BASH_COMMAND
    v5=" on line "
    v6=${BASH_LINENO[0]}
    v7="$v1 $v2 $v3 $v4 $v5 $v6"
    
        echo "$v7" | mail -s "Error" makemATmyhome.co.uk
        exit $errcode  # or use some other value or do return instead
    }
    trap f SIGHUP SIGINT SIGTERM SIGSTOP SIGURG  ERR
    
    # backup follows
    
    begin=$(date --date="19:00" +%s)
    end=$(date --date="21:00" +%s)
    now=$(date +%s)
    
    if [ "$begin" -le "$now" -a "$now" -le "$end" ]; then
    
    
            echo "/sbin/shutdown -h 15" | sudo at 20:40
            echo "AllwaySync will backup the PC to HDD1 then I will shut down afterwards" | mail -s "AllwaySync time" makemATmyhome.co.uk
    
    else
    
            begin=$(date --date="3:00" +%s)
            end=$(date --date="6:00" +%s)
            now=$(date +%s)
    
    if [ "$begin" -le "$now" -a "$now" -le "$end" ]; then
    
            /usr/bin/rsync -avx --delete /media/HDD1/shares/myprofile /media/HDD2/shares/
            /usr/bin/rsync -avx --delete /media/HDD1/shares/hanprofile /media/HDD2/shares/
            /usr/bin/rsync -avx --delete /media/HDD1/shares/mailwasher /media/HDD2/shares/>>/media/HDD1/shares/rsync_log 2>&1
            /usr/bin/rsync -avx --delete /media/HDD1/shares/archive /media/HDD2/shares/
    
            date >>/media/HDD1/shares/rsync_log 2>&1
    
            echo "Success" | mail -s "Backup Completed" makemATmyhome.co.uk
    
            /sbin/shutdown -h 25
    
    else
    
            echo "Playtime but don't forget to shut me down!" | mail -s "rsyncs not being done" makemATmyhome.co.uk
    
            fi
    
    fi

  2. #2
    Linux Engineer
    Join Date
    Jul 2003
    Location
    Stockholm, Sweden
    Posts
    1,296
    I can hazard a couple of guesses, check the environment your script is running under by adding this to the script at the top:

    env > /tmp/scriptenv

    Then check the contents of that file after bootup. Is your /bin/sh a symlink to /bin/bash? If the script is called by /bin/sh even if it's a symlink to bash, bash will run in compatibility mode, from the man page:

    If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. When invoked as an interactive login shell, or a non-interactive shell with the --login option, it first attempts to read and execute commands from /etc/profile and ~/.profile, in that order.
    I imagine that might well be the case, check the output of the script after appending the env line I suggested!

  3. #3
    Just Joined!
    Join Date
    Dec 2013
    Posts
    12
    Quote Originally Posted by variant View Post
    I can hazard a couple of guesses, check the environment your script is running under by adding this to the script at the top:

    env > /tmp/scriptenv

    Then check the contents of that file after bootup. Is your /bin/sh a symlink to /bin/bash? If the script is called by /bin/sh even if it's a symlink to bash, bash will run in compatibility mode, from the man page:



    I imagine that might well be the case, check the output of the script after appending the env line I suggested!
    The output of the file /tmp/scriptenv is:

    CONSOLE=/dev/console
    HOME=/
    runlevel=2
    INIT_VERSION=sysvinit-2.88
    TERM=linux
    COLUMNS=228
    PATH=/sbin:/usr/sbin:/bin:/usr/bin
    RUNLEVEL=2
    PREVLEVEL=N
    SHELL=/bin/sh
    kgdboc=ttyAMA0,115200
    PWD=/
    previous=N
    LINES=61
    VERBOSE=yes

    The file in rc.local is named /usr/local/bin/shutauto. That file is the backup script.

    I don't understand what you mean by "called by bin/sh" although I do see the SHELL=/bin/sh so I presume that it is being called by /bin/sh, however what other way could it be called?

    EDIT: I was just thinking that any path in rc.local was followed and the script to which it was pointing was acted upon by the system at boot. I never thought of this as a symbolic link. This is what happens when you jump in as a newbie without study I am afraid.

    I see the first line of rc.local is !/bin/sh -e
    Last edited by makem; 12-01-2013 at 04:06 PM.

  4. #4
    Linux Engineer
    Join Date
    Jul 2003
    Location
    Stockholm, Sweden
    Posts
    1,296
    I mean that you are specifying att the top with the hashbang that it is a "bash" script but it is being run by /bin/sh which on raspian is probably actually /bin/dash.

    You should edit the rc.local file and run your script so:

    /bin/bash /usr/local/bin/shutauto

    Also, you properly use the full path in most of your script but not for the sudo command "sudo at .. ". Anyway, the user which executes stuff in rc.local should be root anyway right?

  5. #5
    Linux Engineer
    Join Date
    Jul 2003
    Location
    Stockholm, Sweden
    Posts
    1,296
    A better alternative might be creating a simple init script and adding it to the default runlevel?

  6. #6
    Just Joined!
    Join Date
    Dec 2013
    Posts
    12
    Quote Originally Posted by variant View Post
    A better alternative might be creating a simple init script and adding it to the default runlevel?
    Thank you for the pointers. I will look into the better alternative.

    Two things I will need to find, what to 'init' and where is the default runlevel. Learning, learning bit by bit rather than starting at the beginning is not a good idea. But at least you do learn.

  7. #7
    Linux Engineer
    Join Date
    Jul 2003
    Location
    Stockholm, Sweden
    Posts
    1,296
    well if you are already writing such scripts then you are getting pretty advanced as it is , wikipedia can explain runlevels better than I can (note the distro specific differences):

    Runlevel - Wikipedia, the free encyclopedia

  8. #8
    Just Joined!
    Join Date
    Dec 2013
    Posts
    12
    Thought it best to first start by using your first suggestion: /bin/bash /usr/local/bin/shutauto

    The trap worked but produced:

    Error 129 the command executing at the time of the error was v4=$BASH_COMMAND on line 1

    The script exited.

    I will not investigate that further until I check out your better second suggestion.

  9. #9
    Just Joined!
    Join Date
    Dec 2013
    Posts
    12
    I have been reading: unix.stackexchange.com/questions/44836/when-sh-is-a-symlink-to-bash-or-dash-bash-limits-itself-to-posix-compliance-so

    and: network-theory.co.uk/docs/bashref/BashPOSIXMode.html

    and will check the url you suggest.

  10. #10
    Just Joined!
    Join Date
    Dec 2013
    Posts
    12
    The secrets are here

    gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4

Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •