SQLite problem after install - Attempt to write a readonly database

[Rasmus7700]

Hello Guys.
I'm having some problems with the SQLite plugin, after done a complete reinstall on ubuntu.

What is causing this? Is it some files with insufficient permissions?
I'm getting following error when running in debug:
2015-09-06 09:54:10,235 WARNING SQLite dump SQLite: problem updating env.core.threads: attempt to write a readonly database -- __init__.py:_dump:173
2015-09-06 09:54:10,236 WARNING SQLite dump SQLite: problem updating env.core.memory: attempt to write a readonly database -- __init__.py:_dump:173
2015-09-06 09:54:10,236 WARNING SQLite dump SQLite: problem updating env.core.garbage: attempt to write a readonly database -- __init__.py:_dump:173
2015-09-06 09:54:10,237 WARNING SQLite dump SQLite: problem updating env.system.load: attempt to write a readonly database -- __init__.py:_dump:173

[Marcov]

Did you stop (smarthome.py -s) the instance before running the debug instance? Otherwise you have two instances running and so the database is locked by the first instance.

[Rasmus7700]

Yes, the program is terminated and don't run any more.
Then i start with -d and get the error....

Can the database be locked from a fault previous?

I've tried to delete the .db file, change permissions ti 775, but still no success - the database is locked

[Rasmus7700]

No one has a solution for this? I can't figure this out

[bmx]

try first

 ps ax | grep smarthome.py

to ensure no instance is running prior to start smarthome.py with option -d .

Then firgure out permissions on the sqlite database:

cd /usr/local/smarthome/var/db
ls -la

Which user does run the smarthome.py? How many different users do you have?

[Rasmus7700]

Okay... i've tested it.. First when sh.py is running:

rasmus@Ubuntu:/usr/local/smarthome/bin$ ps ax | grep smarthome.py
35769 ?        Sl     0:00 python3 ./smarthome.py
35786 pts/0    S+     0:00 grep --color=auto smarthome.py
rasmus@Ubuntu:/usr/local/smarthome/bin$

Then killing the process:

rasmus@Ubuntu:/usr/local/smarthome/bin$ ./smarthome.py -s
rasmus@Ubuntu:/usr/local/smarthome/bin$ ps ax | grep smarthome.py
35790 pts/0    S+     0:00 grep --color=auto smarthome.py
rasmus@Ubuntu:/usr/local/smarthome/bin$

So the smarthome-py is only running once....

Checking permissions on the DB:

rasmus@Ubuntu:/usr/local/smarthome/var/db$ ls -la
totalt 24
drwxr-xr-x 2 smarthome smarthome  4096 sep  6 17:36 .
drwxr-xr-x 6 smarthome smarthome  4096 jul 31 17:15 ..
-rw-r--r-- 1 smarthome smarthome    54 jul 31 17:15 .gitignore
-rw-r--r-- 1 smarthome smarthome 11264 sep  6 17:36 smarthome.db
rasmus@Ubuntu:/usr/local/smarthome/var/db$

When starting the sh.py from SSH i do it with the "Rasmus" user i log in with - but as i can see it's the smarthome user owning all of it....

I've followed this guide:
https://github.com/mknx/smarthome/wi...ibd-und-1-Wire
When installing it - and there's created a script in the init.d folder to start the sh.py on boot....

When starting the sh.py normally i also get an error that it can't create the logfile....

Error creating logfile /usr/local/smarthome/var/log/smarthome.log: [Errno 13] Adgang nægtet: '/usr/local/smarthome/var/log/smarthome.log'

Any clues?

---Seems like if i start it as root, and in debug mode, there's no problems with the SQLite.... so it must be something according to permissions....
But as who does the script from the guide start the sh.py?:

# Required-Start:    $syslog $network
# Required-Stop:     $syslog $network
# Should-Start:      eibd owserver
# Should-Stop:       eibd owserver
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start SmartHome.py
### END INIT INFO

DESC="SmartHome.py"
NAME=smarthome.py
SH_ARGS="-q"
SH_UID='smarthome'

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin
DIR=/usr/local/smarthome/bin
DAEMON=$DIR/$NAME
SCRIPTNAME=/etc/init.d/$NAME
PIDFILE=/var/run/$NAME.pid

[ -x "$DAEMON" ] || exit 0
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

DAEMON_ARGS="$SH_ARGS"

do_start()
{
        touch $PIDFILE
    chown $SH_UID:$SH_UID $PIDFILE
    start-stop-daemon --start --user $SH_UID --group $SH_UID --chuid $SH_UID --pidfile $PIDFILE --startas $DAEMON --test > /dev/null || return 1
    start-stop-daemon --start --user $SH_UID --group $SH_UID --chuid $SH_UID --pidfile $PIDFILE --startas $DAEMON -- $DAEMON_ARGS || return 2
        ps ax | grep $DAEMON | grep -v grep | awk '{print $1}' > $PIDFILE
}

do_stop()
{
    start-stop-daemon --stop --retry=TERM/30/KILL/5 --pidfile $PIDFILE
    RETVAL="$?"
    [ "$RETVAL" = 2 ] && return 2
    start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
    [ "$?" = 2 ] && return 2
    rm -f $PIDFILE 2> /dev/null
    return "$RETVAL"
}

do_reload() {
    start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
    return 0
}

case "$1" in
    start)
        do_start
        ;;
    stop)
        do_stop
        ;;
    restart)
        echo "Restarting $DESC" "$NAME"
        do_stop
        sleep 1
        do_start
        ;;
    *)
        echo "Usage: $SCRIPTNAME {start|stop|restart}" >&2
        exit 3
        ;;

esac

[Rasmus7700]

Seems like when starting the Sh.py with the script, it does write something in the DB file, but when sh.py is running - the modified date doesn't change when doing:

root@Ubuntu:/usr/local/smarthome/var/db# ls -la
totalt 192
drwxr-xr-x 2 smarthome smarthome   4096 sep 14 12:46 .
drwxr-xr-x 6 smarthome smarthome   4096 jul 31 17:15 ..
-rw-r--r-- 1 smarthome smarthome     54 jul 31 17:15 .gitignore
-rw-r--r-- 1 smarthome smarthome 178176 sep 14 12:46 smarthome.db
root@Ubuntu:/usr/local/smarthome/var/db#

Should the SQLite not write to the DB every time a new value is updated?

[bmx]

Well if you got a user rasmus it surely does not have the same permissions als the user smarthome. So why don't you try first a "su smarthome" prior to start the debugging with "./smarthome.py -d"?

When installing according to the guide in the wiki, one should probably install it as the user smarthome...

[Rasmus7700]

Yes - sorry, i've tested that - and seems to work then....