MikroTik

My latest observations leads me to the actual conclusion that in case of this error it is enough just to restart the dude. As soon as possible in order to gat the smallest gap in recorded data. Finally I have created and regularly scheduled this script that checks the status "running" an in any other case it logs the situation and restarts the dude. It also maintains the counter of restarts, last date and time of restart and the last unwanted dude status. There is no need to make any exclusion, even when the database backup is in progress.

Fell free to use/modify according to your needs and in case of modification / improvement, share here for others.

For ease of use just paste it into the terminal:

Code: Select all

/system scheduler
add interval=5m name=DudeCheck on-event=DudeCheck policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup
/system script
add dont-require-permissions=no name=DudeCheck policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=":global DudeA [/ dude get status];\r\
    \n:global DudeW running;\r\
    \n:global DudeLR;\r\
    \n:global DudeR;\r\
    \n:global DudeT;\r\
    \n\r\
    \n:if (\$DudeA != \$DudeW)  do={\r\
    \n:log info \"Dude status: \$dDudeA.\";\r\
    \n:set DudeT [/system clock get date];\r\
    \n:set DudeT (\$DudeT . \" \".  [/system clock get time] );\r\
    \n:set DudeLR [/ dude get status];\r\
    \n:set DudeR (\$DudeR + 1);\r\
    \n:log info \"Dude is not running, Make automatic restart.\";\r\
    \n/dude set enabled=no;\r\
    \n:delay 5s;\r\
    \n/dude set enabled=yes\r\
    \n}"

This article helps me. Thanks author! CHR 6.43.4, 240 objects in DUDE.
http://www.abit.ie/how_to_solve_dude_is ... _database/

Thanks for hint, I will need to try this procedure also. Is there any long-term experience with this "solution"? Did it help for good or the error comes back after a while again?

dump file into new database takes ages...

Finally the dude works again. Just for one hour so far, but even this is much longer than usual two minutes before...

The dump import took around 10 hours. It was running on i7/SSD, not taking more than 2% of single cpu core. Really "effective" . Final db file is 0,25GB comparing to 1GB of original. The graphs are displaying much faster and the client seems not to be locking itself like during last several years.

Hope it will keep working for some time now.

Mikrotik should include the sqlite3 core and provide the db corrective application or involve the corrective function in the dude package so everyone should be able to run the corrective procedure by single command from CLI. At least. Despite they resigned to develop the dude furthermore.

Does this method applicable for >6.41 dude CHR-installations ?

Yes. The dude was not subject to change for few years and it seems mikrotik is not going to change anything on it in near future.

Lucky you. May happen that problems are linked with usb / mSD storage type on routerboards while on CHR this does not apply.

At least you can simply replace it in case it breaks