-
Notifications
You must be signed in to change notification settings - Fork 271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nextcloud initializing takes too much time #259
Comments
Finally working, with a proper DNS added and working. Opening a new issue because now Nexcloud asks me if I'm reinstalling, and I'm actually not, right? |
Hey urbaman! Initialization takes a long time and I had similar issues. If you still have probs, try first init with cronjob disabled and set liveness, readiness and startup probes to 'false'. Watch the logs of the nextcloud container for init and install to finish. Adjust your values.yml:
Then try to helm upgrade your installation. If that doesn't work, Helm uninstall an then install again, of course without deleting persistence. Hope that helps. Greetz |
In my case, The fix for me was to set |
The startup probe needs to be enabled by default and modified from using an httpGet to running a command that:
For me the rsync step took 3 minutes 30 seconds. The alternative would just be to keep restarting and restarting the rync over and over again till the rsync has a chance to finally complete. Setting the startup probe with an initial delay of 4 minutes works ... but we don't really want to change that for first run then go back and change it everytime afterwards. Note: 4 minutes worked, but it wasn't enough to complete the initial installation, 4 minutes was enough for the rsync to complete but it crashed and restarted 10 more times before the readiness and liveliness probes were happy ... I'm betting the initialization wasn't complete.) A note in the log that its performing its first time initialization and that it may take a long time, up to 5 minutes, would be good to have in the logs as admins check to see why its taking so long. |
It's not apparent to me, why nextcloud copies application code in the persistent storage location: My current configuration:
|
I'm actually not sure if that's something we're doing in the helm chart or if this is being done by something in the docker container, which would be a nextcloud/docker issue 🤔 I haven't had a moment to check though. |
That's how the docker image works. I also don't like but afaik there is no way around it due to the architecture of Nextcloud (which is not very container friendly) |
The way the chart currently works, thankfully, means that using a properly immutable image is possible. I did fork the nextcloud image and build a POC image which can run and perform basic upgrades without any rsyncing: https://github.com/thefirstofthe300/nextcloud-docker The image isn't fully tested so there's likely some pieces that are broken, but that's mostly a matter of adding things back that I may have not reworked properly after gutting the install/upgrade logic. I welcome testing of the image, but please DON'T use it on production data yet. In the name of testing, I do have a PR open to add removing the The lack of rsyncing almost certainly breaks folks using Docker Compose so submitting the image upstream may not be the easiest. |
Yeah, I'm currently facing this issue, I get "ContainerCreating" for like 30-40 mins and then it work or it doesn't and gets stuck forever, I'm currently using seafile which takes only 5 seconds to start the pod, but from time to time I try nextcloud again to see if this issue is gone, tried several images and NFS options, currently Nextcloud is unusable for my kubernetes environment. |
Hi,
I'm trying to setup nextcloud through the Helm chart, backed by some PVCs on shared glusterfs.
Glusterfs works, as I see all of the paths (nextcloud, mariadb, redis master/replica) getting written.
Thing is that the nextcloud pod's logs keeps staying in the "initializing nextcloud" part for more than 7 minutes, with the probes getting faults and restarting the pod.
Also, if I enable croinjob, it fails with something liek "wrong image" message.
Here's my values.yaml file:
The text was updated successfully, but these errors were encountered: