.22: attempt to write a readonly database

Help
2011-11-06
2013-05-29
  • Jan Niggemann

    Jan Niggemann - 2011-11-06

    I updated from .18 to .22 this evening and the logfile always shows this error.
    Starting .22 results in 3 processes, while starting .18 just started a singe process.
    Might this be a bug?

     
  • Justin Maggard

    Justin Maggard - 2011-11-08

    Are you using the static binary?  Are you perhaps starting minidlna as a different user now?  Can you run okay as root?

     
  • Jan Niggemann

    Jan Niggemann - 2011-11-09

    Hi Justin,

    thisI'm using the static binary from SF.net. I'm using the same config file that already worked in .18 and I run it as the same user. As root, the behaviour is the same. I'd happily help with debugging, just let me know what you'd like me to do.

     
  • Justin Maggard

    Justin Maggard - 2011-11-09

    Can you post the exact log message?  Are you using the db_dir setting?

     
  • Jan Niggemann

    Jan Niggemann - 2011-11-10

    AFAIR I don't use the db_dir setting, but I'll check and report back. I'll also post the log message and my config once I'm home from work…

     
  • Jan Niggemann

    Jan Niggemann - 2011-11-11

    My config file is here: http://pastebin.com/fbAx7qYV
    Starting minidlna writes these loglines:

    [2011/11/11 07:52:04] minidlna.c:153: warn: received signal 15, good-bye
    [2011/11/11 07:52:05] sql.c:41: error: SQL ERROR 8 [attempt to write a readonly database]
    UPDATE SETTINGS set UPDATE_ID = 10
    [2011/11/11 07:52:07] minidlna.c:899: warn: Starting MiniDLNA version 1.0.22 [SQLite 3.5.9].
    [2011/11/11 07:52:07] sql.c:41: error: SQL ERROR 8 [attempt to write a readonly database]
    pragma default_cache_size = 8192;
    [2011/11/11 07:52:07] minidlna.c:991: warn: HTTP listening on port 8200
    
     
  • Justin Maggard

    Justin Maggard - 2011-11-11

    Does it work if you force a rescan (start minidlna with the -R option)?

     
  • Jan Niggemann

    Jan Niggemann - 2011-11-12

    # minidlna  -f /etc/minidlna.conf -R
    # ps aux|grep minidlna
    root      2424  0.0  0.0  12748  1148 pts/0    S+   15:36   0:00 /usr/sbin/minidlna  -f /etc/minidlna.conf -R
    root      2426  0.0  0.0  12748  1148 pts/0    S+   15:36   0:00 /usr/sbin/minidlna  -f /etc/minidlna.conf -R
    root      2431  0.0  0.0  12748  1148 pts/0    SN+  15:36   0:00 /usr/sbin/minidlna -f /etc/minidlna.conf -R

    The same happens if I use the db_dir setting btw…

     
  • Jan Niggemann

    Jan Niggemann - 2011-11-16

    Anything else I can try? Ideas?

     
  • Justin Maggard

    Justin Maggard - 2011-11-16

    What distro are you running?  Maybe your filesystem is read-only?  What if you do something like this:
    # mkdir /var/cache/minidlna
    # chmod 777 /var/cache/minidlna
    # echo db_dir=/var/cache/minidlna >> /etc/minidlna.conf
    # /usr/sbin/minidlna -R -d

     
  • Jan Niggemann

    Jan Niggemann - 2011-11-17

    I'm running Debian squeeze. I just double-checked: that the FS really is rw: it is.
    I already tried setting db_dir in the config file, I created /tmp/db_dir and used that in the config file.

    Nothing changes though, there are still 3 processes running when starting minidlna…

     
  • Justin Maggard

    Justin Maggard - 2011-11-17

    The three processes are fine, so you can safely ignore that.  That difference is due to linking with a different C library.  I have both i386 and x86_64 squeeze machines, and they both work just fine with the static 1.0.22 binary.

    What's happening is that the sqlite3 library simply can't write to your database file.  So there really aren't a whole lot of potential causes, provided you're running as root.  It's either (1) the filesystem that holds the database file is read-only, (2) there is an existing database file (/tmp/minidlna/files.db by default) that is marked immutable - lsattr would show "i" - , or (3) you have some sort of filesystem corruption that is preventing writes to that file.  I can't think of any other possibilities.

     
  • Jan Niggemann

    Jan Niggemann - 2011-11-17

    … or (4) PEBCAK, which obviously is why it didn't work on my system ;-)

    I really can't tell why it didn't work before, because as you point out, there's not a whole lot that can be the cause… I tried with db_dir set to /tmp/test_db_dir and that didn't work, but well - it works now with the db_dir set to /var/cache/minidlna.
    Thank you!

     
  • Justin Maggard

    Justin Maggard - 2011-11-17

    Ah yes, I forgot about option 4. ;)  At any rate, I'm glad to hear it's working now.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks