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.
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.
the address obfuscated is static
[/system identity get name] is dynamic
[/system clock getdate] is dynamic
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).
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
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.
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.
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.