Nextcloud version: 27.1.1
Operating system and version: Debian
PHP version: 8.2
The issue you are facing:
I have a autoshutdown script which shuts down my server if not in use. One element is checking if disk are in standby. But since a few days my drives are always coming back from standby to active.
I checked with
iotop -bktoqqq -d .5 and can see the following entries always before the drive is awaking again:
rsyslogd -n -iNONE [rs:main Q:Reg]
postgres: 11/main: nextcloud_db_user nextcloud_db ::1(34282) UPDATE
postgres: 11/main: nextcloud_db_user nextcloud_db ::1(34282) SELECT
What could be the reason for these? My postgres database is not located on these 2 hard drives. Only data is.
Additional problem is that I have same or similar entries in my log as well where drives are staying in standby.
You first have the cronjob running on a regular basis. Depending on the usage, you can adjust that a bit especially at night time. Second thing are connected clients that regularly check for changes, you can modify these poll intervals as well: Advanced Usage — Nextcloud Client Manual 3.10.1 documentation
Thanks, I will check the poll intervall. But I’m not really sure if this is the reason as I don’t have any new clients and before is was working for almost years.
Well, if you don’t share this with us, we can’t consider it. If it worked so far, when did it stop to work, a new version of something (NC, OS, …), …
I was not able to identify the reason behind. I now switched back to MariaDB and deinstalled postgresql. Now the drives are staying idle again.
Nextcloud is a php webserver software and only contacts the database e.g. if the Nextcloud is triggerd from Nextcloud GUI, WebDAV, clients, cron, … Normally Nextcloud do nothing. I do not know the intervall of your problem (that would be really interesting) but i think it was only a PostgreSQL-problem without Nextcloud.
I now figured out that I was to fast. The issue is still remaining with MySQL (mariadb). So now from my perspective it has to do with Nextcloud.
My monitor now shows that there is a write on the disk every 5 minutes which is the crontab intervall. But I’m still not able to identify what is written and where. How can I find out?
Again, if I disable mariadb service as well as apache then the writes are gone and server is shutting down automatically if idle.
Old clients also create traffic and request frequently for changes to synchronize data.
My server is local. Only clients are two desktops and two smartphones. During the day when we are working the desktops are not running and the smartphones are not in the WLAN and can not reach the server. But still then the drives are active. Thats the reason why I ruled this option out.
I thought you ruled that out? With the cron still active, it will access the database each time. You need to stretch the cronjobs during time your setup is not active.
Why? The database is not located on the drives which need to be idle to shutdown the server. Only the nextcloud_data folder is. The database is on my OS drive. Even if cron will access the database every 5 minutes this should not trigger any read and write activities. It did not in the past.
A few things I would try that might help narrow down what’s causing the issue:
Confirm that the cronjob is actually responsible for the disk activity by changing the interval to e.g. 10 minutes and then checking whether the disk write intervals have also changed to 10 minutes.
Find out if the issue is caused by a specific app by disabling them one by one, starting with the most recently installed.
Where is the Nextcloud log file located and what log level is set? Perhaps log entries are written every time the cronjob runs…
Sorry, I missed that part.
Just on top of @bb77’s remarks (), you said like it was working before. This might give a hint in case you added something lately, or updated, …
Thanks to @devnull in this thread (Cron job MySQL disk writes - #12 by devnull) I was able ro resolve it.
I confirmed that the cron job is triggering the access to the drive by running it manually
sudo -u www-data php /path/to/nextcloud/cron.php
Then I created a log file with strace during running
sudo -u www-data strace -ytff -o /tmp/log.txt php /path/to/nextcloud/cron.php
I did this a few times and always checked with
grep which files are accessed on my external drives.
Based in the log file I was able to identify that this was related to an issue with the index of the elasticsearch (fulltextsearch) index which was broken and cron always wanted to recreate it.
I deinstalled elasticsearch for now and now everything is normal again. Will try to install it later again.
Thanks for your support.
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.