I’m pulling my hair out over here, hoping you guys can offer some guidance. I’m trying to create a script that, on boot up, will reach out to a remote server, download a “config file” of sorts (or any set of commands) and execute them. In order to achieve this, I’m using a fetch, then calling /import on the file. When I run this script via the CLI, it works perfectly. When I let it execute from the scheduler (on boot), it gets as far as the fetch, the file shows up in the filesystem for a brief second, then vanishes and the script stops there.
Running the script with /system script run OnBoot-ConfigFetch works flawlessly. The script does get called successfully via the scheduler, but stops executing after the fetch command.
Also, I am incredibly interested to understand why the behavior of the script / fetch is so negatively affected when run by the scheduler versus being run by hand. That is the bigger concern for me for sure!
I appreciate that the forums are public, and responses may vary.
If nobody is able to comment on this, is there a way for me to pay for support to get an answer?
Or, perhaps someone can suggest another way to achieve what I’m trying to accomplish:
We plug in a brand new mikrotik, and either via netinstall or by simply putting a script.auto.rsc file on there, it kicks off a process to call home to us, ask for a config file, download it and apply it
On subsequent reboots, or forced script execution, also call home and see if there are any changes (and if so, download + execute)
The first part is totally achievable right now, but because fetch is seemingly dying when used on a scheduler set for “startup”, I cant find a way to have a re-check-in happen after a reboot.
Yes, but your script can then be simplified. All you need to do is schedule a single fetch. The scrip will be auto-executed and file will be deleted, until next boot.