How to run sh or php script for filer or cron

wakson005

@stephenw10 Sound good. Is there a easy way to monitor the script for comments output to know what is occurring?

Been using package filer to add my script and run all my script in cmd prompt for testing and its working great. Is there a better way to monitor script than just output below as I will only know it stop not why it stopped. I assume there might be a kill switch for the for or while loop for some reason...

// Start off the comments with overwrite
echo "# This is a comment" > /path/to/taperrorlog.txt
// then use below to append to current file
echo "# This is a comment" >> /path/to/taperrorlog.txt

Hopefully this gives me more idea. From my rudimentary understand .sh script under "/usr/local/etc/rc.d/" directory will run automatically. But not sure how it handle a script with a while/for loop that never ends. There is possibility a kill switch to prevent infinitely loops. I think i need this approach to keep it running forever base on what I have seen:

#!/bin/sh
# PROVIDE: autostartopenvpntap
# AFTER: NETWORKING
# KEYWORD: shutdown

. /etc/rc.subr

name="autostartopenvpntap"
desc="Auto Start OpenVPN TAP Connections"
rcvar="${name}_enable"

start_cmd="${name}_start"
stop_cmd="${name}_stop"

autostartopenvpntap_start() {
    # Add your script execution command here
#    while true; do
        # .sh script below has local variable being stored for comparison check later
        # So this needs to be fixed if not it wont work. Easiest solution is to move
        # openvpn_server_client_tap_auto_failover.sh into this script I think...
        /usr/local/bin/openvpn_server_client_tap_auto_failover.sh
		echo "Start Script: /usr/local/bin/openvpn_server_client_tap_auto_failover.sh from autostartopenvpntap" >> /usr/local/bin/tapErrorLog.txt
#    done
}

autostartopenvpntap_stop() {
    # Add the command to stop your script here
    pkill -f /usr/local/bin/openvpn_server_client_tap_auto_failover.sh
}

load_rc_config $name
run_rc_command "$@"

## Set the script to start on boot by adding the following line to /etc/rc.conf.local:
## autostartopenvpntap_enable="YES"
## Reboot the system or start the script manually using the following command:
## /usr/local/etc/rc.d/autostartopenvpntap.sh start
#############################################################
## File:
##   /usr/local/etc/rc.d/autostartopenvpntap.sh
## Permissions:
##   755
## Script/Command:
##   N/A
#############################################################

wakson005

@stephenw10 Ok i found out why after outputting echo to a text file. So it turns out the script run bunch of time and does an infinitely reset loop so that's why I see it goes up and then goes back down instantly... so saving files in this location "/etc/local/etc/rc.d" run the script repeatively??? lol... Still trying to figure that out.

Best way is to save data to temporary file and load it during each loop as i think the local variable is reset each time. If it was the same script running in a loop the local variable data is maintain but it seem like it load a new script to run each time so local data won't be maintained.

Start Script: /usr/local/bin/openvpn_server_client_tap_auto_failover.sh from autostartopenvpntap Time: 12:05:28
Start Script: /usr/local/bin/openvpn_server_client_tap_auto_failover.sh Time: 12:05:28
Start Script: /usr/local/bin/enable_bridge_tap.sh Time: 12:05:28
Start Script: /usr/local/bin/disable_bridge_tap.sh Time: 12:05:28

Start Script: /usr/local/bin/openvpn_server_client_tap_auto_failover.sh from autostartopenvpntap Time: 12:06:22
Start Script: /usr/local/bin/openvpn_server_client_tap_auto_failover.sh Time: 12:06:22
Start Script: /usr/local/bin/enable_bridge_tap.sh Time: 12:06:22
Start Script: /usr/local/bin/disable_bridge_tap.sh Time: 12:06:23

Start Script: /usr/local/bin/openvpn_server_client_tap_auto_failover.sh from autostartopenvpntap Time: 12:07:33
Start Script: /usr/local/bin/openvpn_server_client_tap_auto_failover.sh Time: 12:07:33
Start Script: /usr/local/bin/enable_bridge_tap.sh Time: 12:07:33
Start Script: /usr/local/bin/disable_bridge_tap.sh Time: 12:07:33

stephenw10

Hmm, if it's really an rc script like that it will get triggered by package/service restarts etc which could explain the multiple instances.

The only time I've dealt with this was with the lcdproc package. We had to add a line to kill any existing instances before starting a new process.

I would have expected it to run fine as a shellcmd to be honest.

wakson005

@stephenw10 Yea its really weird guess my best option is to move it completely out of that location. If you said it is trigger by package/service restarts there are too many things going on that could trigger it then. I will move it to "/usr/local/bin/" and use a cron to trigger my script in an infinite loop. Its the next best solution really lol. Not the best way but its what I have I guess.

As my script work when i trigger it through shellcmd manually during the failover but doesn't work when there is all this other stuff triggering it in a infinitely loop.

stephenw10

Yup try moving it somewhere else. I usually just put scripts like that in /root. Makes them clearly not part of the default system.

wakson005

@stephenw10
Really appreciate all the help Stephen. Everything is resolved now. Failover working flawlessly in 1 minute interval due to cron (but can easily change this later for shorter time as needed).

Issue turn out to be a file permission issue:

"Filer" and cron saving data to same file using echo was probably causing permission issues to the files. Weird thing is even if the file being written is given 777 using filer to allow everyone to read, write, and execute that still didn't work. So I end up using filer to create file and write to it in script directly and same script to access it.
everything was moved out of rc.d as well. Though will probably go back just to try it again as curious.

wakson005

@wakson005 Yep rewrote a different script to check every sec for failover and now the failover start within 1sec and takes overall about 20-30 for tap failover to occur but vpn re-established almost within 5-10 sec. Works just as good or better than the TUN failover now :) thanks!!!

stephenw10

Nice.