CyaOnDaNet

Unfortunately, I have tried everything I could think of and have no idea how to stop it without forcing an unsafe shutdown. One time it shutdown like it was supposed to (I think because I caught it so fast) but all other times it hung. I close out everything I can, all other dockers and VM's, issue a shutdown and then hold the power button 15 minutes later. You have to do a parity check after this but otherwise I had no noticeable ill effects. I can happily say that I am at 67 days server uptime with no issues. The redis changes seemed to be the last things I needed to make Nextcloud stable again. I have changed so much and its been a while but I will try to list everything I did below so others can hopefully benefit: Starting with docker template changes: Changed Nextcloud appdata app path access mode to "RW/Shared" (I did this originally because my temp folder was in this path but I left it after I moved the temp folder) Changed my '/mnt/user/appdata/nextcloud-temp':'/tmp' path mapping to "RW/Shared" Added "REDIS_HOST", "REDIS_HOST_PORT", and "REDIS_HOST_PASSWORD" variables to point to new redis container In my nextcloud appdata directory under /www/nextcloud/config/config.php I changed/added the following things: 'filesystem_check_changes' => 1, 'memcache.local' => '\\OC\\Memcache\\APCu', 'memcache.distributed' => '\\OC\\Memcache\\Redis', 'memcache.locking' => '\\OC\\Memcache\\Redis', 'redis' => array ( 'host' => 'THE SAME IP USED IN THE CONTAINER FOR REDIS_HOST', 'password' => 'THE SAME PASSWORD USED IN THE CONTAINER FOR REDIS_HOST_PASSWORD', 'port' => THE_SAME_PORT_USED_IN_THE_CONTAINER:REDIS_HOST_PORT, ), 'filelocking.enabled' => 'true', 'datadirectory' => '/data', 'tempdirectory' => '/tmp/nextcloudtemp', In my nextcloud appdata directory under /php/php-local.ini I changed/added the following things: upload_tmp_dir = /tmp/php/ session.save_handler = redis session.save_path = "tcp://SAME_IP_FOR_REDIS_THAT_I_USED_IN_CONTAINER:REDIS_PORT?auth=REDIS_PASSWORD"

Well after 34 days server uptime, it finally happened again. I will try the redis container for Nextcloud cache thing that @jcsnider suggested and report back how it goes. You should hear from me in about 45 days if it seems to be working or earlier if it doesn't work. 🤞

Maybe, I just didn't even think to try that time because the other two times it didn't work. The two main times it has happened to me was about 30 days uptime. The third time I was only at maybe a week uptime but I had the container offline the whole time and only had it started for like the last 5 minutes of uptime. Mine runs once every 8 hours. I noticed the two main times it happened that my mover was stuck. I ran the command mover stop and it did actually stop but that did not help safely shutdown or get the diagnostics data. I have my parity check scheduled monthly on the first and both times I noticed the issue it was November 3rd and December 3rd. I thought that maybe a combination of parity check and mover caused the issue but I have run manual parity checks since then with no issue so that was coincidental. This last time it happened where I could actually shutdown, my mover was not running, it hadn't been triggered yet. Maybe a combination of nextcloud locking up and the mover running prevents safe shutdown (and maybe diagnostics collection too?). On a side note, my nextcloud is still running fine after the changes I made but it hasn't been very long. I will keep updated here on how it goes. If I can make it to 30+ days uptime again then I know the issue is probably solved. Unfortunately, I kind of plan on shutting down soon to adjust some things so it may be a while before I get to 30+ days again.

By the way, I just wanted to confirm that this was true for me. After it locked up, I performed a shutdown and though it took an extra minute or two, it was actually able to safely shutdown. The other 2-3 times this has happened, I could not shutdown because the docker service couldn't stop nextcloud. Maybe because I caught it so fast yesterday it didn't completely lock everything up.

I guess I should have been a bit more specific earlier. I added 'tempdirectory' => '/tmp/nextcloudtemp/', to my config.php in nextcloud and I added upload_tmp_dir = /tmp/php/ to my php-local.ini and then I mapped /tmp --> /mnt/user/appdata/nextcloud/temp which would technically be /data/temp. I was not but after you brought it up, I read about it and it sounds beneficial to our use case. I'm adding it now, did you have this enabled before? @jcsnider I will do that too. Is it still working?

Wow, so I started up my container to get the version info for my previous comment and a couple of minutes later it 504'd. I ran the command and got the following: root@Nighthawk:~# ps axl | awk '$10 ~ /D/' 4 99 6321 14590 20 0 127440 37480 - D ? 0:00 php7 -f /config/www/nextcloud/cron.php 4 99 7676 14590 20 0 127440 39696 - D ? 0:00 php7 -f /config/www/nextcloud/cron.php 5 99 19593 14579 20 0 260996 24004 - D ? 0:00 php-fpm: pool www 5 99 20230 14579 20 0 261060 23412 - D ? 0:00 php-fpm: pool www 4 99 25703 14590 20 0 127440 39340 - D ? 0:00 php7 -f /config/www/nextcloud/cron.php

I am running Unraid v6.8.0-rc7 and Nextcloud 19.0.5 (I know my unraid version is old old but I needed the the linux kernal in this version and they reverted it all v6.8.x after this RC. I will be updating to v6.9-RC1 soon after I read about any potential issues people may be having). Unfortunately, I gave up and performed an unsafe shutdown. My nextcloud docker isn't even running right now because I didn't have time to deal with this if it happened again but I will start it back up later today. Yes, I have a LSI Logic SAS 9207-8i Storage Controller LSI00301. This is interesting, I completely forgot I made changes to my container back in early October. I too had issues with nextcloud filling up my docker image during file upload. I have had nextcloud for a while but never really used it. I started uploading video files and noticed my docker image filling up so I looked into it but didn't find a whole lot of info. I added the docker path /tmp ---> /mnt/user/appdata/nextcloud/temp and that stopped my docker image from filling up. It just points the nextcloud /tmp directory to my cache drive. Has anyone else having this issue made any changes to the /tmp path? What about you @jcsnider?

Did you ever figure this out? I am having a similar issue. I noticed I couldn't log into my nextcloud today and attempted to restart the container in the GUI but it wouldn't stop. I tried the following commands in an ssh console but it just waited without doing anything: docker stop nextcloud docker kill nextcloud docker rm --force nextcloud Trying to download the unraid diagnostics in the webGUI results in endless waiting. Typing "diagnostics" in an ssh console resulted in "Starting diagnostics collection..." for over 12 hours and nothing was created in the /boot/logs folder. Interestingly, on the "/Main" tab in the webGUI, my unassigned devices plugin won't load. I believe this issue may have overlapped with a parity check but I could be mistaken or that could be coincidental. My server won't shutdown because my docker service won't stop. All because I can't stop the nextcloud container.

This is a bug that slipped through the cracks. I believe I have a fix for it that will be implemented in the version 2.0.0 update. It's taken me a little while to get this update done as I have been pretty busy lately. I might just push the update early once I get to a stopping point with the current feature I am working on.

I saw your issue on github, my response is below: To add the `--restart always` flag on unraid, enable advanced view on your container settings, go to the `Extra Parameters:` option and put `--restart always`.

@KINO The intention behind the role mentions is that the channel the notifications feed into is muted and set to notify @mentions only. That way the user is not constantly spammed by all notifications but rather the ones that matter to them. You can manually give shows a role using the bot commands if it didn't auto create it for the desired show. Firing off messages once per day is not currently possible. That gave me the idea of being able to set quiet hours, where the bot caches all messages during the window and sends them out once quiet hours are over. I will look into adding that; it should be possible to have it fire off once a day by just setting the quiet hours to only allow a 1 minute opening. It will be a little while before I can get to that as I need to refactor my code to work with Discord.js 12 first.

@Roken Sorry for such a late response. I'm not sure why this would be an issue. It looks like you have a webroot set to /plog/ on Tautulli. That means when you access the main UI page for tautulli the address is http://192.168.1.73:8181/plog/home. The only other thing I can think of is for you to double check that you api is enabled in Settings > Web Interface > API > Enable API.

@Fiservedpi You don't need to worry about generating images in the sub-folders or anything, Tautulli can provide image URL's. The image URL has to be publicly accessible and is automatically grabbed from Tautulli when the notification is pushed. To use this, enable image hosting in Tautulli. Go to Settings > 3rd Party APIs and select an option from the Image Host drop down. I self host my Tautulli now but in the past I have used Imgur with no problems.

Even if you don't select the movie react roles with `!notifications edit`, the #notifications channel you set up will still receive recently added movie notifications, just with no roles if none are enabled.

@Fiservedpi As of right now it doesn't connect to Radarr. You can have 2 types of movie based notifications though, triggered by the self-generated Tautulli recently added webhook. There is an All Movies react role and a New Movies react role (set if the movie was released within the last 9 months). These can be enabled with `!notifications edit`. I have a few cool ideas brewing that may need a Radarr connection, so that may be a thing in the future.