[mythtv-users] cannot restore database

[UB40D]

To summarise the thread for posterity (and my own reference):

On Fri, Feb 20, 2015 at 11:28 PM, UB40D <ub40dd at googlemail.com> wrote:

> 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.
>
> What should I do?
> I have tried running the below both before and after a
>   sudo service mythtv-backend stop
> but it made no difference.
>
> mythconverg_restore.pl --drop_database --create_database --verbose
> --filename  mythconverg-1317-20150220033002.sql.gz
>

If mythconverg_restore.pl weren't written in Perl, I'd update it myself to
do more explicit and useful error reporting by replacing "drop database"
with

try:
    drop database
catch (error 17 cannot rmdir ./mythconverg):
    absPath = absolute path version of the thing you say you can't rmdir
    if absPath exists:
        print error: absPath exists but I can't delete it --- have a look
    else:
        print error: trying to delete absPath but it doesn't exist

If the script doesn't do that, I should do it myself. To find absPath,

sudo find / -name mythconverg -print

with the sudo because the dir isn't visible by the mere mortal account. For
mythbuntu the answer should be /var/lib/mysql/mythconverg.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20150222/e8b97398/attachment.html>