Any know how to retain variables’s values after reboot the MT, saving this values to disk ?
-Roddy
Just an (untested) idea:
In your script create another script that is setting the (global) variable you want to retain to its’ current value. Then create a scheduler entry to execute this script only once at startup (which should be working now?!).
Every time your variable does change remove the “I recreate the variable”-script and re-create it so that it sets the variable to the new value.
By the way: It would be nice to have a console command to write something arbitrary to a file (like the :log command, just with an additional “file” parameter and the ability to choose between append and overwrite mode).
Best regards,
Christian Meis
I found a new solution using firewall chains
Replace variable_name with the true name of your variable, and variable_value with his value
To create a new variable:
/ip firewall filter add chain=variables comment=variable_name content=variable_value
To read the variable value:
:put [/ip firewall filter get [find chain=variables comment=variable_name] content]
To update the variable value:
/ip firewall filter set [find chain=variables comment=variable_name] content new_value
To remove the variable:
/ip firewall filter remove [find chain=variables comment=variable_name]
The chain “variables” is never ejecuted, avoid cpu load
-RoddyZ
Nice one, too 
Best regards,
Christian Meis
cmit:
Thinking in your script idea, i create the follow script to recreate all global variables in the startup, with a autoexec scheduler (like: http://forum.mikrotik.com//viewtopic.php?t=1611&highlight=autoexec).
:foreach i in=[/ip firewall filter find chain=variables] do={
:log info ( "Loading variables: " . [/ip firewall filter get $i comment] . “=” . [/ip firewall filter get $i content] )
:global [/ip firewall filter get $i comment] [/ip firewall filter get $i content]
}
But, is better to have a more efective way to retain variables, MT team, please take note …
-RoddyZ
i’d use [/ip firewall layer7-protocol] instead of [/ip firewall filter], since it’s safer and will not accidentally disturb the filter rules, also the regexp can store more data.
13 years later. Well, I wrote a function that reads and writes persistent variables as layer7-protocols.
:global persist do={
:local varName $1
:local varValue $2
:local varID [/ip firewall layer7-protocol find name="$varName"]
:if ([:typeof $varValue] = "nothing") do={
:if ($varID != "") do={
:set $varValue [/ip firewall layer7-protocol get $varID value-name=regexp]
}
} else={
:if ($varID = "") do={
/ip firewall layer7-protocol add name="$varName" regexp="$varValue"
} else={
/ip firewall layer7-protocol set $varID regexp="$varValue"
}
}
return $varValue
}
Usage examples: (name = variable name, value = variable value)
- $persist name = Read persistent variable
- $persist name value = Write persistent variable
- :global name [$persist name] = Read persistent variable and write it to a global variable
- :global name [$persist name value] = Write data into a global variable and into a persistent variable at the same time
Notes:
- The function uses layer7-protocols to store persistent data.
- All data read from persistent storage will be strings.
- The function always returns a value.
Did not see that before.
Why in the earth does not the RuterOS retains the global variable after reboot.
This should be a simple ting for MT to implement???
So MT consider this as a request.
sometimes you need some variables that stay even after a reboot
For example:
A script that reboots if the internet connection is down or a certain type of attack is detected.
You need to keep track of your number of reboots until a script has to stop rebooting itself.
Write variables in scheduler startup script is a better option than writing variables in l7 rules and other crazy stuff.
How com storing a variable inn to the script section is less crazy than storing it in a l7 rule?
Could you post an example?
Why not just retain variable after reboot when its stored as a global variable?
:persistent variable
or…
:global::persistent variable
I am sorry to say but half of the forum is using L7 as variables.
If there is a better way then please post example.
AND, having LTE traffic counter as such variable should be built into ROS…
mrz
- But… what with rapid power-off… data will be lost !
L7 stay with latest one value ever reboot. - But… scheduler will be create GLOBAL variable to other scripts can use it.
Better is we stay with local and not use to many global.
Each script can create local or global when he start, we not want a variable without latest value from before reboot. - But… from scripting level we cannot edit the variable=value in some one line of scheduler on-event code!
We cannot do export from only one scheduler to file,
We cannot edit it via sed&awk - not work here… we not have proper workaround…
Layer7 is best option.
Scheduler StartUp for creating global variables who will be reading latest variable from NAND ? This is even worst then L7.
Of course we can do more crazy idea 
like creating new bridge-variable1, Value in commend but still, L7 is better.
Future Suggestion:
Can we have a scheduler restart/shutdown then?
Why in the earth does not the RuterOS retains the global variable after reboot.
Can you show any other scripting language or programming language where defined variables magically restores their values from previous script instance, without saving data to file, registry or database? If you want to save something handle it in your code.
- But… what with rapid power-off… data will be lost !
L7 stay with latest one value ever reboot.
With L7 is the same as with scheduler configuration you have to write changes. If you do not write latest changes to scheduler or even your used L7 then of course nothing is saved.
Benefit of using startup scheduler is that you do not need to read and parse variables, they are just loaded at startup automatically.
Local variables are local to the scope, saving them does not make any sense. There is nowhere to restore them because local scope does not exist anymore when script is finished.
This can be adapted to write global variables to a file: http://forum.mikrotik.com/t/script-dont-create-file/143788/3
I advise to only do variables and not scripts due to the 4096 bytes limitation. If you mark functions with the wordpart func in the name and those variables that not should be saves with nosafe
Example:
:foreach in environment do
:if variablename ~ “(func|nosafe)” do{} else{safe to file by using append}
}
Then use scheduler on startup to read back the variables into environment by using :global
With L7 is the same as with scheduler configuration you have to write changes. If you do not write latest changes to scheduler or even your used L7 then of course nothing is saved.
Benefit of using startup scheduler is that you do not need to read and parse variables, they are just loaded at startup automatically.
I understand you, what ever it’s stored, persistent env are know stuff and we can use them like setx /M path "%path%;C:\your\path\here\"
Scheduler way must do
- scheduler-env-startup - he create a global with default value
- scheduler-run-own-finall-app - this will be change our global
- scheduler-env-udpate - every x time it grab all global and replace data in scheduler-env-startup
better way is store that variable at /flash/env.txt and load/update them from schedulers because editing body of other script/scheduler is not easy at ros without sed&awk.
Still Layer7 works so perfect and we use that thank by just 1 line of code, we can stay with local, what means this is almost perfect.
In reality… many times a workaround life longer then solution
That is not important. From my time with MT Router this has been something that many of us like to have. Yes there are several workaround File/Script/L7 etc, but why not implement it? Should be easy to do. Look at Larsas post above..
See this post as an formal request for presistant variables.
Automatic persistent variables is a piece of cake using for example Javascript, TCL, Python, Powershell, Apple Automator, etc. But since the RoS script engine is a crippled TCL look-alike which lacks a working storage engine we probably won’t be blessed with that kind a functionality in the near future. 