Stop a script running from the scheduler

DyadyaGenya · Thu Nov 02, 2023 12:56 am

I made a script with an infinite loop. It doesn't matter what it does, what matters is that the cycle is endless. It’s easy to stop it in the terminal (Cntrl+C), but I decided to put it in the scheduler so that it starts when Mikrotik is rebooted. And set the interval to 1 minute. As a result, a bunch of versions of the script were launched. If I understand correctly, they hang in “Jobs”. Disabling the script in the scheduler does not help. Apparently those hanging in JOBS are executed. If I remove it by hand in JOBS one by one, it will be removed. If I try like this:

/system script job remove script_name

then he swears:

no such item

From here I wanted to understand:
1. How to extinguish all versions of a running script?
2. How can I write in the scheduler so that the script runs only once at startup?

mkx · Thu Nov 02, 2023 3:18 pm

It seems that you can't stop those scripts.

But reconsider the strategy of your script ... or implement some checks. If it's run every minute, does it have to run in endless loop? Perhaps you could drop the loop and rely on scheduler to run it frequently. Or add ability to detect already running script to your script (I don't know if/how this can be done though). Or actually run the script only once on startup (use start-time=startup as per ROS scheduler manual).

DyadyaGenya · Thu Nov 02, 2023 10:33 pm

Or actually run the script only once on startup (use start-time=startup as per ROS scheduler manual).

Thanks, my second problem is solved thanks to your link. Before this, I almost never used the scheduler, and did not know that an interval equal to zero means launching only once.

If it's run every minute, does it have to run in endless loop?

Just the opposite. I don't want the script to run every minute. I'd like to leave an infinite loop. It is written to test the connection. Thanks to your tip, I can now run it only once in the scheduler. BUT I would like to understand just in case for future experiments. Is there anyway to stop the script or the loop in it using some command in the terminal or an additional script if my main script is launched through the scheduler.

Amm0 · Thu Nov 02, 2023 10:56 pm

If the goal is to test a connection... maybe netwatch would solve. The newer "icmp" check is pretty robust likely more than a script. Or perhaps using BFD might be a better approach than script.

Jotne · Thu Nov 02, 2023 11:05 pm

You can make a loop script that test i a variable is true.
Then you can just change the variable from 1 to 0 and the script stops.

DyadyaGenya · Thu Nov 02, 2023 11:38 pm

If the goal is to test a connection... maybe netwatch would solve. The newer "icmp" check is pretty robust likely more than a script. Or perhaps using BFD might be a better approach than script.

Thanks for the suggested option. I'll see if I can use it.
But in any case, there is a desire to delete all entries in JOBS. Do I understand correctly that all script runs that the scheduler managed to make are displayed in JOBS?

DyadyaGenya · Thu Nov 02, 2023 11:41 pm

You can make a loop script that test i a variable is true.
Then you can just change the variable from 1 to 0 and the script stops.

Are you suggesting I make a global variable? This is probably one of the options, to make some kind of flag (variable). But I still wanted to understand JOBS.
The fact is that I have not yet removed the ones hanging there. I understand that you can remove each one manually or restart Mikrotik, but since such a situation happened, I wanted to experiment. I tried to do something like:
/system script job remove
But then, if I sort through the possible commands with a tab, it only offers the JOBS number.

optio · Fri Nov 03, 2023 12:18 am

You can create script in /system/script with script code that needs to be triggered in scheduler on event, then put just name of that script into scheduler on-event.
It's documented here:

on-event (name) - name of the script to execute. It must be presented at /system script

It's not complete description, because on-event can contain script code, not just script name. Maybe this is changed through ROS versions but not updated in doc.

Example: scheduler with name tst runs script with same name (not mandatory to be same name as scheduler, just valid script name), when scheduled event is executed script name is assigned to executed job in list, can be identified by that name and removed.

/system/script> export
...
add dont-require-permissions=no name=tst owner=admin policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=":delay 10"

/system/scheduler> export
...
add interval=30s name=tst on-event=tst policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-date=2023-11-02 start-time=\
    23:01:30

/system/script/job> print
Columns: SCRIPT, OWNER, STARTED
#  SCRIPT  OWNER  STARTED            
0          admin  2023-11-02 23:02:12
1  tst     admin  2023-11-02 23:12:00
2          admin  2023-11-02 23:12:00

/system/script/job> remove [find where script="tst"]

DyadyaGenya · Fri Nov 03, 2023 12:40 am

/system/script/job> print
Columns: SCRIPT, OWNER, STARTED
#  SCRIPT  OWNER  STARTED            
0          admin  2023-11-02 23:02:12
1  tst     admin  2023-11-02 23:12:00
2          admin  2023-11-02 23:12:00

/system/script/job> remove [find where script="tst"]

That's what I need. I didn't even have to create a script with a loop to iterate through all the names I needed.
The only thing that, to my shame, I still don’t know is how to immediately go along the path:

/system/script/job>

I have to move gradually:

/system/

then

/system>script/

then

/system/script/job>

And I still don’t understand why in this situation find is written without a colon

optio · Fri Nov 03, 2023 1:11 am

You can execute command with full or relative path from other path, example executing print on different paths from /system/script path:

/system/script
job/print
../scheduler/print
/interface/print

Commands with colon prefix are global commands mostly used for scripting, others can be different per section context (path).
See https://wiki.mikrotik.com/wiki/Manual:S ... g#Commands

Jotne · Fri Nov 03, 2023 7:31 am

Are you suggesting I make a global variable? This is probably one of the options, to make some kind of flag (variable). But I still wanted to understand JOBS.

Yes, it can be used to control the running state of the script.

Amm0 · Fri Nov 03, 2023 8:45 am

I have no idea of the internal implementation, but it still Linux under-the-covers. I'd imagine scripts are processes (or pthreads) at some point, similar to other shells. And, all processes have some "parent" process. So when you run a schedule script, it's not shown as "job" because it "parent" is a cron-like process. While when you invoke a /system/script, that what tracks in /system/script/jobs . Conversely at the CLI, the "parent" process is a terminal window, and thus also not tracked as "job" since it was not invoked by the /system/script/run.

Your infinite loop's "lifetime" depends on if it's parent is still alive, since child process are "kill"-ed (terminated) if the parent terminates. So running in a infinite loop at the terminal window will terminate the loop if the window closes. While the /system/script/run doesn't go away since it's a top-level process.

Personally, I'd avoid having an infinite loop (or even one stoppable with a ":while (shouldStop != true)") since the loop will chew up CPU resources. Even if there are some ":delay XX" in your code, that still uses some CPU. Why avoiding a long-running loop is likely a better plan.

But basically the /system/script/jobs only tracks what was called by /system/script/run. If the action the /system/scheduler is a script name, as @optio suggests above, that still run/"invokes" the /system/script so that's why it's tracked in jobs.

rextended · Fri Nov 03, 2023 11:19 am

Or add ability to detect already running script to your script (I don't know if/how this can be done though).

viewtopic.php?t=197314#p1009493

DyadyaGenya · Sat Nov 04, 2023 10:30 pm

If the goal is to test a connection... maybe netwatch would solve. The newer "icmp" check is pretty robust likely more than a script. Or perhaps using BFD might be a better approach than script.

I tried netwatch. Interesting thing. But:
1. I didn’t notice much difference in the processor load if you use an endless pinging cycle in the script.
2. At the moment I can’t figure out how to send to telegram from netwatch. Of course, if I understand correctly, then in netwatch you can run your script separately, removing the ping loop from it, and then you can send a message to Telegram. But in my opinion this would not be true.

DyadyaGenya · Sat Nov 04, 2023 10:36 pm

But basically the /system/script/jobs only tracks what was called by /system/script/run. If the action the /system/scheduler is a script name, as @optio suggests above, that still run/"invokes" the /system/script so that's why it's tracked in jobs.

In principle, this is enough to interrupt the execution of a script launched from the scheduler.

DyadyaGenya · Sat Nov 04, 2023 10:40 pm

viewtopic.php?t=197314#p1009493

If I understand correctly, then this is a type of flag that was proposed to be made above. This is suitable if you are making a new script. But I was interested in stopping a script that does not have such a flag.

Amm0 · Sat Nov 04, 2023 10:48 pm

But basically the /system/script/jobs only tracks what was called by /system/script/run. If the action the /system/scheduler is a script name, as @optio suggests above, that still run/"invokes" the /system/script so that's why it's tracked in jobs.
In principle, this is enough to interrupt the execution of a script launched from the scheduler.

Yeah this approach seem to be what your looking for.

There was a longer discussion about script vs schedule here: viewtopic.php?t=191165

DyadyaGenya · Sun Nov 05, 2023 12:12 am

If the goal is to test a connection... maybe netwatch would solve. The newer "icmp" check is pretty robust likely more than a script. Or perhaps using BFD might be a better approach than script.

I almost figured out sending messages to Netwatch, but I noticed that checking and restoring the link is slower than in my script, where there is an endless ping.

Stop a script running from the scheduler [SOLVED]

Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler [SOLVED]

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Re: Stop a script running from the scheduler

Who is online