Scheduled Script Fails; Works on Manual

I have multiple scripts ran by scheduler on all mikrotik items in my scope. I’ll provide an example scheduler and script below.

These scripts historically have not had issue, however after recent updates (not the most recent, unsure how many back) the scripts seem to fail some % of the time when ran from the scheduler. If the script is run manually, it works 100% of the time.

Script:

0 name=Email_Log_VPN owner=obfuscated policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon dont-require-permissions=no last-started=irrelevant run-count=1 source=/log print file=elog.txt; /tool e-mail send to=obfuscated subject=([/system identity get name] . " Log " . [/system clock getdate]) file="elog.txt"; /system logging action set memory memory-lines=1; /system logging action set memory memory-lines=65000;

Scheduler:
0 name=Email_Log start-date=1994-04-12 start-time=06:00:00 interval=1d on-event=Email_Log_VPN owner=obfuscatedpolicy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon run-count=1 next-run=2026-04-25 06:00:0

Errors:
image

This applies to a fleet of routers/access points including the following models:

cAPGi-5HaxD2HaxD
CCR1036-12G-4S
CCR1036-8G-2S+
CCR2116-12G-4S+
CRS112-8G-4S
CRS328-24P-4S+
CRS354-48P-4S+2Q+
nRAYG-60ad
RB4011iGS+5HacQ2HnD
RB5009UPr+S+
RBLHGG-60ad
RBwAPG-5HacD2HnD
wAPG-5HaxD2HaxD
RBD52G-5HacD2HnD
RBD53iG-5HacD2HnD
RBwAPG-5HacD2HnD
RBwAPG-5HacT2HnD

Why use "print"? MUST be used "export"...

Perhaps writing the post more legibly would be more courteous to those trying to help.

As written, it's just full of errors and definitely won't work 100% of the time.

But don't you check what you wrote in the post before sending it?

For example:
Script:

0 name=Email_Log_VPN owner=*obfuscated* policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon
dont-require-permissions=no last-started=*irrelevant* run-count=1
source=
/log print file=elog.txt;
/tool e-mail send to=*obfuscated* subject=([/system identity get name] . " Log " . [/system clock getdate]) file="elog.txt";
/system logging action set memory memory-lines=1;
/system logging action set memory memory-lines=65000;

Scheduler:

0 name=Email_Log start-date=1994-04-12 start-time=06:00:00 interval=1d on-event=Email_Log_VPN owner=*obfuscated*
policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon run-count=1 next-run=2026-04-25 06:00:0

It looks like someone's birth date...
Actually, it definitely is.

it definitely is

If this is your case, then there are at least two Ram (Aries) on the forum...

Back to topic, the line that generates the error is this one:
/tool e-mail send to=*obfuscated* subject=([/system identity get name] . " Log " . [/system clock getdate]) file="elog.txt";

and since the error (vaguely enough) talks of something "missing", the problem must be in one of the "generated on the spot" items.

  1. the address obfuscated is static
  2. [/system identity get name] is dynamic
  3. [/system clock getdate] is dynamic
  4. file="elog.txt" is static BUT there is no check if the file actually exists/can be accessed

So I would exclude #1.

Only thinking aloud, but could it be that at the time the line is parsed some of the other 3 items is not generated or is not accessible?

To try troubleshooting, you could try assigning the [/system identity get name] and [/system clock getdate] to two variables earlier and make a check for the existence/accessibility of the file?

This way all the parameters of the e-mail command are surely valid before the execution of the line (or create a more specific error).

this could be the case -

additional info:
the elog.txt file is never cleaned out so there’s technically always a file by that name in place, however, while reading your message it also occurs to me that since the file is created and then in the next line requested - it could be that the file is still in progress of being created or in some way the object itself is not ready;

to cover for your statements I will

  1. make the dynamic lines static – if resolved I can spend the time to make all of the infrastructure static rather than using the lazy dyn lines if need be in the worst case.
  2. make the script pause for 30s after creating the file to make absolutely sure the object is made in entirety

Yes, I cannot believe that the [/system identity get name] and [/system clock getdate] can be "late", the file is more likely.
You could also add something.
Loosely I would want that - in case the e-mail is sent correctly, no elog.txt file remains, i.e. the file is later renamed to elogold.txt, the "previous run" elogold.txt is removed and only one elogold.txt remains.

I’m going to count it as soft resolved;

I went ahead and changed the script to the following:

/log print file=elog.txt;
/tool e-mail send to=obfuscated subject="Log" file="elog.txt";
#/system logging action set memory memory-lines=1;
#/system logging action set memory memory-lines=65000;

and changed the scheduler to run once a minute;
hasn’t failed once on two systems across 3 hours

going to leave it overnight and push to the fleet if SAT.
thank you sir.

If your RouterOS version is ≥ 7.20, then the proper way to clear the memory buffer content is:

/system logging action clear action=memory

Instead of having to rely on the memory-lines shrinking trick.

When do you realize the command is wrong?
Or some future version of routeros have that command?
I didn't write my first post by chance...

I took it as a copy/paste error.
A non existing command should fail the same way on terminal or in a script.

Problem returned - and for all scripts that email on all equipment irrelevant to changes to script on that equipment or not. Including being unable to run the script manually. ‘something is missing’ is always the error for each, even if those scripts don’t send a file as the one does here. For example, one script sends an email if the log is 10k+ lines.

I believe based off this information that [a variable you all wouldn’t have had access to so I apologize] our external mailing system has a limit on how many emails we can send in X period of time - even though we do not have an agreement to say as such.

I confirm this at least as not a script error - as sending an email via tools>email fails with the same error.

I believe I am just going to be forced to finally bring in all of this data via another source, api/ssh etc. Not looking forward to it but it is certainly overdue.

Thank you all.