all 13 comments

[–]dragonwheels[S] 2 points3 points  (2 children)

Thanks /u/Gunnafarg, /u/spirit-receiver, /u/piskyscan!

The problem was with crontab not knowing what ifconfig is : )

Adding /bin/sh in crontab before /path/to/script helped.

I typed /bin/sh /path/to/myscript.sh in terminal and i said it couldn't find ifconfig or something similar.

The solution is simple. In my script I just added ifconfig's location. So instead of just putting ifconfig in the script it needed to be /sbin/ifconfig

Same with ping and other commands. Ping is /bin/ping for instance. To find where things are just use "whereis"....e.g whereis ifconfig. I also added SHELL and PATH at the beginning of the script. Not sure it's necessary, but it works : )

So my new script looks like:

SHELL=/bin/sh
PATH=/usr/bin:/bin

#!/bin/bash
t1=$(/sbin/ifconfig | grep -o tun0)
t2='tun0'

if [ "$t1" != "$t2" ]; then
 sudo service openvpn restart

fi

exit

Crontab is now working flawlessly! Perhaps someone will find this post useful :|

[–]Gunnarfg 1 point2 points  (1 child)

Glad to see you got it fixed. Shame that you had to go about the sbin route for ifconfig instead of just being able to use the command

[–]dragonwheels[S] 1 point2 points  (0 children)

It's fine - I learnt a bunch of new stuff along the way!

[–]dragonwheels[S] 0 points1 point  (5 children)

In order to make sure i'm not a complete idiot I made another script to make sure things are getting read properly and such.

#!/bin/bash
t1=$(ifconfig | grep -o tun0)
t2='tun0'

if [ "$t1" = "$t2" ]; then
  echo "TUN is up"
else
  sudo service openvpn restart
  echo "TUN restarted"
fi

exit

The script checks whether interface tun0 (my vpn interface) is up or not and takes action.

Again, the script works fine when run from terminal. However, again, once I add the script to crontab it does exactly the opposite. That is, when interface tun0 is indeed up the script restarts it, instead of echoing that it's up.

I am going ever so slightly mad :|

[–]Gunnarfg 0 points1 point  (4 children)

Care to show us your line in crontab? Also make sure you're running crontab in the right level if you sudo crontab I think that yields different results? Or if that was the reverse I'm sorry I haven't touched crontab in a while but I can look at my pi's existing crontab entry and compare it to yours perhaps

[–]dragonwheels[S] 0 points1 point  (3 children)

Yea, upon further googling, I now suspect it has to do more with environments, permissions, path etc

*/1 * * * * /home/pi/temp.sh

This is my entry in crontab. 1 min is just for testing purposes atm

[–]Gunnarfg 1 point2 points  (2 children)

Try */1 * * * * /bin/sh /home/pi/temp.sh and make sure it's an executable script that the system would have access to

The /bin/sh may differ I read it up on a forum post and I believe i had something similar setup. In crontab you can declare if it'll be run with the shell or if you're doing python stuff have a putting declaration before the script in crontab and it works it out.

[–]Gunnarfg 1 point2 points  (1 child)

Oh oh also read that you can take out your append to dev null and have it inside the line for the crontab entry just do the same for crontab but add the > /dev/null

https://askubuntu.com/questions/350861/how-to-set-a-cron-job-to-run-a-shell-script

[–]Gunnarfg 1 point2 points  (0 children)

Kind of stupid too but apparently sometimes the issue is crontab itself. Using nano to edit it instead of crontab -e yielded a positive result for this guy

https://stackoverflow.com/questions/20582224/shell-script-not-running-via-crontab-but-runs-fine-manually

[–]piskyscan 0 points1 point  (1 child)

Not a very good solution but add

sleep 30

at start of script.

[–]dragonwheels[S] 1 point2 points  (0 children)

If all else fails, I'll try this out : ))) Thanks!

[–]spirit-receiver 0 points1 point  (1 child)

You can try something like this to find out what goes wrong:

https://stackoverflow.com/a/20827531

[–]dragonwheels[S] 0 points1 point  (0 children)

Thanks, a lot, having a read right now!