Hi,
I have an RPI plugged into my RB powered via the USB port. I use the following script to manage the RPI in case it locks up The 120 count is to wait long enough just in case the RPI is rebooting itself

However sometimes you can ping the RPI ( 192.168.88.10 ) but you are unable to login so the scripts hangs. Is there a way i can run command and if after X seconds there is no response reboot the router anyway ? the doesn't seem to work ?

I'm not sure if the ConnectTimeout command is supported as there is no mention of it here - https://wiki.mikrotik.com/wiki/Manual:System/SSH_client

However if it is supported, would this work?

the

Code: Select all

/delay 30s

doesn't seem to work ?

/delay 30s

Change it to:

:delay 30s

I'm not sure if the ConnectTimeout command is supported as there is no mention of it here - https://wiki.mikrotik.com/wiki/Manual:System/SSH_client

However if it is supported, would this work?

Code: Select all

/system ssh-exec connecttimeout=20 address=192.168.88.10 user=root command="shutdown now"

This command does not exist in RouterOS: connecttimeout=20 (ChatGPT??)

The only supported commands after "/system ssh-exec" are: address, command, output-to-file, port, src-address, user, vrf

You have to read a lot before scripting.

It's just better to directly ask on form than asking ChatGPT before and pasting here it's answer like it's written by you or some "friend" that needs "minor" corrections.

You can create scheduler that will run asyc shutdown script (only ssh-exec in that script), trigger it from main script, watch in loop from main script job with shutdown script name that is executed from scheduler, if timeout reaches remove that job (it interrupts/terminates script) or if not existing anymore while loop is performing it's executed within time (add some boolean check in loop to break for this). This may help viewtopic.php?t=201132#p1033602

The other concern here is ssh-exec needs a password, but that can't be provided in a script... So an SSH key is needed from RPi for it work in a background script.

The other concern here is ssh-exec needs a password, but that can't be provided in a script... So an SSH key is needed from RPi for it work in a background script.

Already done and is working, as mentioned this script is already in use and works... i just want to add a fail safe if the script hangs due to the RPI not responding

I suppose you can wrap the ssh-exec in do/on-error block, that cover a network failure/timeout (although not 100% it will catch that since didn't test, but should)
You can use also tool netwatch, which handles the ping, etc., see viewtopic.php?t=201346&hilit=netwatch#p1037116

Already done and is working, as mentioned this script is already in use and works... i just want to add a fail safe if the script hangs due to the RPI not responding

My abstract explains how to do it, not sure which is default connection timeout for ssh-exec, but if you want achieve explicit 30s timeout, you need to execute script async that executes ssh-exec and that is possible with scheduler. This means that you need 2 scripts (main and script with ssh-exec) and scheduler that have on-event value of script name with ssh-exec (script name, not ssh-exec command!). Date and time for scheduler triggering must be adjusted to date (current) and time (current + add 2 sec to ensure triggering after adjustment) when main script needs to trigger it (can be disabled after main script is ended and enabled again on next main script run). Some delay (depends on added seconds to current time on scheduler time) on main script can be added after triggering scheduler to ensure that is executed and after that what I explained in prev. post (loop to check if script is running with timeout loop break).

It would be great feature for ROS to have parameter like wait=no on to execute script async and not use scheduler as workaround. This can be useful to some execute parallel script without need to wait end when it's not needed to be handled by caller script (for eg. manually run multiple scripts in batch to distribute load on multiple cores) or to implement some timeout logic that is not handled by commands.