/ip proxy set enable=no
:delay 10s
/ip proxy clear-cache
If I run this script in certains ways I obtain different results.
If I use the “scheduled” mode with the winbox open, then the proxy cache disk (sata in secondary disk) becomes to 0 Kb. This is ok.
If I run manually the script from winbox, then the proxy cache disk (sata in secondary disk) becomes to 0 Kb. This is ok.
If I want to use the scheduled function with the winbox closed, the script runs, BUT the cache disk NOT erase any data, and follows with her previous size.
I want to clear the cache disk for better performance after 7 days in automatic way, but in the scheduled mode the data over the disk follows after the scripts runs at the indicate date.
I revised the permissions and all looks ok… but in scheduled mode with the winbox closed, the sata disk NOT erase the data.
/system scheduler
set ClearCache policy=ftp,local,password,policy,read,reboot,sensitive,sniff,ssh,telnet,test,web,winbox,write
/system script
set ClearCache policy=ftp,local,password,policy,read,reboot,sensitive,sniff,ssh,telnet,test,web,winbox,write
That gives both the script and scheduler FULL policy rights. If that makes it work correctly, then you should be able to remove some of the rights one at a time to see which rights are minimum requirements. Note that there are several policy options available in CLI that are NOT configurable in Winbox. These include:
ftp
local
ssh
telnet
web
winbox
Just adjust the above policy configurations via the CLI until you get the right set of rights.
This solution (set full policy rights) has not work. Same results.
This issue really seems a bug. I think.
The script ONLY works ok by run manually within winbox or in CLI. In scheduled run, ONLY works with the winbox session opened with MY EYES put on her.
BUT If I go sleep (or anything else ) in scheduled mode with the winbox session CLOSED it doesnt works at all and the size of data in SATA disk is equal to the size previous script run, and after all they follows increase as normal run of the proxy.
That would be the problem. As far as I know, there’s no way to automatically answer prompts in scripts. Maybe put in a feature request that adds an optional parameter to the command to circumvent the prompt in scripts? Kinda like “/noconfirm” on interactive Cisco IOS commands.
I thought there may be another method to do this, but it is not possible. Every option I have tried will run into at least one prompt to confirm an action.