Gyurci

Not just you... this docker has a very frequent update. The auto updater plugin is your friend in this case, set it and forget it.

There was an update for the container midnight and my server auto updated at 6am without problems, and looks like my dbengine database files are persistent now. So looks like the "delete obsolete charts files = no" setting solved the problem.

Ok, I looked through the global section of the netdata config file and found this: delete obsolete charts files = yes I set this to "no" and restarted the docker. Maybe this prevent the system from deleting the cache files??? Now testing with this until the next update...

@primeval_god After a day of testing this, it is not working as it should. I now have graphs back about 5hours. But I configured the dbengine cache size to 4GB and it runs from about 23hours ago, the cache file size is now about 18MB only. I added a new path to the docker container: /var/cache/netdata (container) -> /mnt/user/appdata/netdata/cache/ (host) It is working correctly, because I can see the generated dbengine files in my appdata/netdata/cache/dbengine folder. But, in the meantime there was an update to the container and I set the docker auto update to run at 6am and my graphs are persistent back exactly to the same time! So I think, when the docker update invoked, it is cleared my dbengine cache completly. How can I resolve this issue? Can I configure the docker somehow for not touching the dbengine cache folder when an update is invoked?

@primeval_god Thanks, thats very good news. I will give it a try again. edit: Looks like it is working perfectly!

Hi! Is there a way to enable the dbengine? I've got the following error, if I trying to enable it: "2019-11-02 11:41:07: netdata FATAL : MAIN :RRD_MEMORY_MODE_DBENGINE is not supported in this platform. # : No such file or directory"

Thanks for the reply, yes I'm using unRaid 6.7.2. I give a chance to the Auto Update Plugin and see if it helps. I do not want to upgrade to 6.8 yet, I will stay in the stable branch.

Looks like most of my problems are gone. I stopped my array and then restarted it for another reason and since then there are no segfault errors in my log. The settings of transmission looks like persistent now. Only one error left: the transmission docker keeps saying that an update is available, but I can live with it... Maybe the next real update will correct this too.

I'm trying to investigate the errors I mentioned earlier. In my syslog, there are these error lines about transmission: Oct 17 09:57:29 NAS kernel: transmission-da[24735]: segfault at 48 ip 000055b839ebe934 sp 00001530e6e90a48 error 4 in transmission-daemon[55b839e96000+4b000] Oct 20 13:23:35 NAS kernel: transmission-da[5810]: segfault at 48 ip 000055987f3e9934 sp 000014e5d87a2a48 error 4 in transmission-daemon[55987f3c1000+4b000] Oct 21 19:06:08 NAS kernel: transmission-da[4383]: segfault at 24000000 ip 0000557c9f39c93f sp 000014ba6191ba48 error 4 in transmission-daemon[557c9f374000+4b000] Oct 23 11:05:07 NAS kernel: transmission-da[13708]: segfault at 48 ip 0000560692121934 sp 0000150fea543a48 error 4 in transmission-daemon[5606920f9000+4b000] Oct 23 13:33:20 NAS kernel: transmission-da[21612]: segfault at 18 ip 000055baf05b4a71 sp 000014a17c8f47f0 error 6 in transmission-daemon[55baf0595000+4b000] Oct 24 08:28:03 NAS kernel: transmission-da[17826]: segfault at 0 ip 0000000000000000 sp 0000151b068b5a58 error 14 in Budapest[151b0686f000+1000] Oct 25 08:54:51 NAS kernel: transmission-da[31340]: segfault at 48 ip 0000561d50782934 sp 00001461a7dd9a48 error 4 in transmission-daemon[561d5075a000+4b000] Are these errors related to the errors I mentioned in the earlier posts in any way, or what is this? Also I created a dedicated watch folder alongside the already existing complete and incomplete folders in my downloads share, because my watch folder was my downloads share earlier. This looks like corrected the "settings reset bug" I think, because those are persistent since then (the settings of my download/upload speed restrictions and scheduling of them, etc).

There is no settings.json file on the flash drive. It is in the appdata/transmission folder, and if I look in that file, my settings are there, for example the ones for throttling download and upload speeds and scheduling them. I think there is not much to edit in the settings.json file, becouse my settings is already in there. And what about the update issue? It is constantly says, there is an update for the container, nevertheless I already applied the update.

I am also having the same issue! And also have another issue: my settings in the transmission ui is not persistent, for example if I set a speed limit schedule, I must re-set every time when I restart the container. Please give us some help about these issues.