Clarify time until Nextcloud's maintenance mode takes effect

[matzzzl]

In the documentation for creating nextcloud backups you suggest to enable the maintenance mode before starting with the backup process to prevent data inconsistencies.

According to my experience activating the maintenance mode does not always have immediate effect. Only after waiting the time configured in the php configuration value opcache.revalidate_freq you can be sure that your nextcloud instance is really running in maintenance mode.

I suggest you should clarify this in the documentation, as automated backups taken by scripts might otherwise not be consistent, if the copying of files or the creation of a database dump is started immediately after enabling Nextcloud's maintenance mode (i.e., before it is effectively enabled). Another solution might be that the php occ maintenance:mode --on command blocks until maintenance mode is effectively enabled.

[gitoffmyln]

sudo -u www-data php occ maintenance:mode (without the --on or --off) will respond one of two ways ...

• Maintenance mode is currently enabled
• Maintenance mode is currently disabled

One option is to adjust your backup script to use this to verify it has occurred.

As an aside, my opcache.revalidate_freq is 20 for both apache2 and cli. [edit: this is in 25.0.3] Yet, changing config.php or running occ maintenance:mode --on has an immediate affect on the other, at least in human reaction time.

[joshtrichards]

Hi @matzzzl - Great suggestion. I've fielded queries from others that have come up against this too. Can you submit a PR?

[MichaIng]

sudo -u www-data php occ maintenance:mode (without the --on or --off) will respond one of two ways ...

• Maintenance mode is currently enabled
• Maintenance mode is currently disabled

One option is to adjust your backup script to use this to verify it has occurred.

This cannot work, as the CLI PHP instance cannot know whether the web OPcache instance has the config.php expired already or not. The command only shows how the CLI PHP instance sees that file, and as every call creates a new PHP process, hence a new OPcache instance, it will simply always show the change immediately effective, regardless of the web status.

As an aside, my opcache.revalidate_freq is 20 for both apache2 and cli. [edit: this is in 25.0.3] Yet, changing config.php or running occ maintenance:mode --on has an immediate affect on the other, at least in human reaction time.

There should be no OPcache enabled at all for CLI, as there is no point to create a 128 MiB (default) cache for a single CLI call. What could be done is reading the value of opcache.revalidate_freq from the PHP config file and sleep for that amount of seconds within your maintenance script(s).

There is actually an OPcache option for defining a blacklist file containing file paths which shall not be cached. Is it probably a generally good idea to blacklist the config.php that way? I think it is not read so often that this has no large impact on performance? https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.blacklist-filename It would be actually nice to only enforce revalidation for certain files, instead of not caching them at all, so not the whole file needs to be read and compiled each time, but only the timestamp checked. But such seems to not exist.