90787dbe89
Closes #169733 The issue is that Nextcloud fails to start up after a GC because the symlink from `override.config.php` is stale. I'm relatively certain that this is not a bug in the Nix GC - that would've popped up somewhere else already in the past years - and one of the reporters seems to confirm that: when they restarted `nextcloud-setup.service` after the issue appeared, an `override.config.php` pointing to a different hash was there. This hints that on a deploy `nextcloud-setup` wasn't restarted properly and thus replacing the symlink update was missed. This is relatively hard to trigger due to the nature of the bug unfortunately (you usually keep system generations for a few weeks and you'll need to change the configuration - or stdenv - to get a different `override.config.php`), so getting pointers from folks who are affected is rather complicated. So I decided to work around this by using systemd-tmpfiles which a lot of other modules already utilize for this use-case. Now, `override.config.php` and the directory structure aren't created by `nextcloud-setup`, but by `systemd-tmpfiles`. With that, the structure is guaranteed to exist * on boot, since tmpfiles are always created/applied then * on config activation, since this is done before services are (re)started which covers the case for new installations and existing ones. Also, the recursive `chgrp` was used as transition tool when we switched from `nginx` as owning group to a dedicated `nextcloud` group[1][2], but this was several releases ago, so I don't consider this relevant anymore. [1] |
||
|---|---|---|
| .. | ||
| config | ||
| hardware | ||
| i18n/input-method | ||
| image | ||
| installer | ||
| misc | ||
| profiles | ||
| programs | ||
| security | ||
| services | ||
| system | ||
| tasks | ||
| testing | ||
| virtualisation | ||
| module-list.nix | ||
| rename.nix | ||