This morning I was greeted with this error message and my Dude is not running. Database was around 30MB.
I’ve found on Wiki manual for db repair, but there is a warning: Works only on db versions up to v6.37 software builds.
So since i have 6.40.8, repair from wiki won’t work for me.
I did try vacuum-db and it does the same as restarting Mikrotik, Dude starts working for minute or so and error appears again.
Any help on how to proceed?
Delete the dude storage and import older dude backup.
Have you got enough storage space for the database?
When this happens to me, it usually means I’ve forgotten to increase the disk space on the CHR VM.
I imported older backup of dude but I’m concerned that this will happen again.
I have enough storage available.
Yes. It will happen again. Sooner or later it will for sure.
No. Mikrotik does not do anything in order to correct it. Schedule often backups and restore it when necessary. There is no other solution for now.
Do you (or anyone else) know what is causing it?
None knows. Even mikrotik didn’t say anything more than that they noted that for the further correction while they resurrect the dude development in the future. The dude is on hold again, like usually.
FWIW
I updated Dude with every release, running 6.43.2 now.
Dude runs on a CHR vm over here.
Running for more than a year without problems.
Creating daily backups but never needed to restore
Lucky you. May happen that problems are linked with usb / mSD storage type on routerboards while on CHR this does not apply.
My Dude dB also runs from sdcard. I’m considering to swap micro SD card for USB to sata connector and connect small ssd for database.
I’ve tried connecting hard disk over USB-to-SATA connector, hard disk is detected, I got it formatted but when I try to write data to it Mikrotik restarts, I’m guessing it’s because it doesn’t have enough power to run hdd over USB, so I may try to find powered USB to sata adapter or maybe ssd because I’m hoping router will have enough power to run it.
My rb750gr3 started to report disk i/o errors on microSD card. I pulled it out, formatted in pc, tested few times with no errors, put back to rb750gr3, reformat to ext3, let the dude run on it and guess what? Again dtb corruption reported, followed by i/o error again. Made tests once more - no problems at all. I moved the dude back to chr but ir has its own problems too (switching off the cpu so the hypervisor decides to stop the virtual machine). At least it means that the rb750gr3 is not able to run dude on microSD card reliably.
Dude in CHR 6.43.2 does the same too. Mikrotik was officially informed.
There is opened ticket for this problem [Ticket#2017090222000354] by me and as you can see, it celebrated 1st year anniversary few days ago. Stll no positive answer, no hope…
vmware workstation 12. Maybe it is not linked to storage or to architecture, it may be common dude server application programming error which is there since the era of dude 4b3, maybe longer, according to the old forum topics.
Last error was overcome by stopping and starting dude again. Question how long it will last.
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:
/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}"
Are you talking about my problem with disk image malformed? I’ve tried restarting dude and it would start working for minute or two and after that same error happens.
That was similar in my case or rb750gr3 /microSD. Now when I gave up running the dude on it and moved it to CHR, the simple restart solves the situation for days without any other noticeable side effects. So far… I suggest you to follow. The client behavior is also much smoother with server in CHR than in rb750gr3. My DB file size is 300MB, backup tgz file has 115MB.
I’ve found SSD and connected it over USB-to-SATA connector and for now dude is working over it. I will leave it for the night and see how it behaves.
Running 6.42.7 and this started (Oct 14 2018) dude,critical db failure: database disk image is malformed.
It is one hosted on a 750G r3 Hex with a 30gb sd
Going to move to a VM
Thanks for suggestions.
Bill
I have not seen this problem in CHR during last two weeks. Really strange.
Hello,
Start mongod with --repair . To repair the data files, start the mongod instance with the --repair option. If the mongod instance uses MMAPv1 Storage Engine, you can include the --repairpath option to specify a temporary directory used during repair. For details, see --repairpath .
Thanks…