Database persistency issues
francispeixoto opened this issue · comments
Full disclosure, I might not be technical enough to properly describe what's going on. This is my perception of the effects of what I believe to be a bug.
It seems that the database isn't properly persisted when the container image is updated. I have Watchtower maintaining my image versions, and as long as it doesn't update Ubooquity, the database is properly maintained, with recent additions being tracked incrementally as expected. But as soon as the image gets updated, the scan scan starts other from scratch, as if the database hadn't existed before.
Post the compose file or the run command you used to deploy the container.
this is what I have in my composer file:
ubooquity:
image: linuxserver/ubooquity
container_name: ubooquity
environment:
- PUID=1000
- PGID=1000
- TZ=${TZ}
- MAXMEM=
volumes:
- ${USERDIR}/docker/ubooquity:/config
- /media/data/books:/books
- /media/data/comics:/comics
- /media/data:/files
ports:
- 2202:2202
- 2203:2203
restart: unless-stopped
this is the latest image that watchtower grabbed:
time="2019-05-06T04:00:33Z" level=info msg="Found new linuxserver/ubooquity:latest image (sha256:b920a33730212dc4f23dc32154e6a8bb4273982d47a6dc33ca83d7d64ab689bb)"
Try to not use the variable for user dir and instead use the full path.
Try to not use the variable for user dir and instead use the full path.
thanks, I'll try that. Any idea how I could force the issue to trigger, or do I have to wait until a new image is generated?
Just delete the container and image, but not the folder you use for the /config mount.
linuxserver/ubooquity@sha256:b920a33730212dc4f23dc32154e6a8bb4273982d47a6dc33ca83d7d64ab689bb came out and I recreated the container, the indexing restarted from zero rather than appending to existing db.
Just reporting in that the issue is still happening since new images came out
/config mounted on a remote or local file system?
All my storage is local to the host
And just to confirm, you can see files getting generated in the host folder you mounted to /config?
The container was recreated 3 days ago and has been up 12 hours (my server crashed). When I came back from the crash, Ubooquity started a new db instead of updating the existing one
But to answer your question, yes I see the relevant files on the host folder
Run a ls -al in the /config folder inside the container and on the host and post the output.
root@e0076e503925:/config# ls -la
total 123288
drwxr-xr-x+ 6 abc users 4096 Apr 14 14:14 .
drwxr-xr-x 1 root root 4096 May 7 21:28 ..
-rw-rw-r--+ 1 abc users 19236447 Apr 14 14:14 Ubooquity-2.1.1.zip
-rw-r--r--+ 1 abc users 19243985 Apr 14 14:14 Ubooquity-2.1.2.zip
-rw-rw-r--+ 1 abc users 19243825 Apr 14 14:14 Ubooquity.jar
drwxrwxr-x+ 4 abc users 4096 Apr 13 23:46 cache
drwxrwxr-x+ 2 abc users 4096 Apr 13 23:46 fonts
drwxrwxr-x+ 2 abc users 4096 May 11 08:27 logs
-rw-rw-r--+ 1 abc users 1850 May 10 20:27 preferences.json
drwxrwxr-x+ 3 abc users 4096 Apr 14 14:14 themes
-rw-rw-r--+ 1 abc users 68444160 May 11 10:57 ubooquity-5.mv.db
-rw-r--r--+ 1 abc users 25441 Apr 25 20:50 ubooquity-5.trace.db
-rw-rw-r--+ 1 abc users 64 Apr 14 14:14 webadmin.cred
root@e0076e503925:/config#
Please post everything I asked for.
Permissions should be abc:abc inside the container though.
What is the host OS?
Sorry I missed the second part I was on my phone
Host is Ubuntu 18.04
fpeixoto@home:~/docker/ubooquity$ ls -la
total 124644
drwxr-xr-x+ 6 fpeixoto fpeixoto 4096 Apr 14 14:14 .
drwxrwxr-x+ 22 fpeixoto fpeixoto 4096 May 6 10:34 ..
drwxrwxr-x+ 4 fpeixoto fpeixoto 4096 Apr 13 23:46 cache
drwxrwxr-x+ 2 fpeixoto fpeixoto 4096 Apr 13 23:46 fonts
drwxrwxr-x+ 2 fpeixoto fpeixoto 4096 May 11 08:27 logs
-rw-rw-r--+ 1 fpeixoto fpeixoto 1850 May 10 20:27 preferences.json
drwxrwxr-x+ 3 fpeixoto fpeixoto 4096 Apr 14 14:14 themes
-rw-rw-r--+ 1 fpeixoto fpeixoto 19236447 Apr 14 14:14 Ubooquity-2.1.1.zip
-rw-r--r--+ 1 fpeixoto fpeixoto 19243985 Apr 14 14:14 Ubooquity-2.1.2.zip
-rw-rw-r--+ 1 fpeixoto fpeixoto 69832704 May 11 12:42 ubooquity-5.mv.db
-rw-r--r--+ 1 fpeixoto fpeixoto 25441 Apr 25 20:50 ubooquity-5.trace.db
-rw-rw-r--+ 1 fpeixoto fpeixoto 19243825 Apr 14 14:14 Ubooquity.jar
-rw-rw-r--+ 1 fpeixoto fpeixoto 64 Apr 14 14:14 webadmin.cred
fpeixoto@home:~/docker/ubooquity$
Just chiming in to advise that this is still an issue today. I've taken steps to exclude Ubooquity from Watchtower, but from a security perspective, this isn't making me comfortable, especially with all the latest news relating to Docker threats
This has nothing to do with recent docker security issues.....
I don't understand how you even think that's relevant?
Or how this can remotely be a security issue....
I'm just confused all round by that last post.
I'm not saying this is a security issue. I'm saying the workaround (excluding it from watchtowers radar) could become a security issue, since it wouldn't be kept updated anymore unless I do it manually
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.