<div dir="ltr">To summarise the thread for posterity (and my own reference):<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 20, 2015 at 11:28 PM, UB40D <span dir="ltr"><<a href="mailto:ub40dd@googlemail.com" target="_blank">ub40dd@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>There was a power cut at home while I was at work. I came back, restarted the myth box and the frontend showed a white screen. Attempting to restart frontend and/or backend didn't work. Neither did rebooting the machine again. So I decided to restore the latest backup (I have a daily backup from a cron job.) However, when I run the restore command, it gets stuck at "dropping database", which shouldn't be the most time-consuming action.<br><br></div>What should I do?<br></div>I have tried running the below both before and after a <br>  sudo service mythtv-backend stop<br></div>but it made no difference.<br><div><div><div><br><a href="http://mythconverg_restore.pl" target="_blank">mythconverg_restore.pl</a> --drop_database --create_database --verbose --filename  mythconverg-1317-20150220033002.sql.gz </div></div></div></div></blockquote><div><br></div><div>If <a href="http://mythconverg_restore.pl">mythconverg_restore.pl</a> weren't written in Perl, I'd update it myself to do more explicit and useful error reporting by replacing "drop database" with</div><div><br></div><div>try:</div><div>    drop database</div><div>catch (error 17 cannot rmdir ./mythconverg):</div><div>    absPath = absolute path version of the thing you say you can't rmdir</div><div>    if absPath exists:</div><div>        print error: absPath exists but I can't delete it --- have a look</div><div>    else:</div><div>        print error: trying to delete absPath but it doesn't exist</div><div><br></div><div>If the script doesn't do that, I should do it myself. To find absPath,</div><div><br></div><div>sudo find / -name mythconverg -print</div><div><br></div><div>with the sudo because the dir isn't visible by the mere mortal account. For mythbuntu the answer should be /var/lib/mysql/mythconverg.</div><div><br></div><div>The reason it got stuck in my case was for the presence of an extra file that had been left there after attempting to repair a physically damaged (unreadable sectors) file.</div><div><br></div><div>One thing I can't fully understand is why "drop database" could not delete that file. If "drop database", when invoked from mythconverg_restore, runs as the unprivileged user, how could it even access the mysql directory which the unprivileged user can't even ls? If, as seems more plausible, it runs as mysql with setuid, then why couldn't it delete my spurious file? Even if the file had been owned by root, if the process owned the parent directory it should have been able to delete everything anyway. Maybe it just didn't want to rm -f for fear of messing up unknown things--but then it would have been helpful of it to say that that's why it was getting stuck.</div></div></div></div>