Skip to content
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

Enabling .persistence.enabled leads to /var/www/html/lib and probably other files not being created #583

Closed
v1nsai opened this issue Jun 18, 2024 · 5 comments
Labels
NFS to group together all NFS related issues Persistence Anything to do with external storage or persistence. This is also where we triage things like NFS.

Comments

@v1nsai
Copy link

v1nsai commented Jun 18, 2024

Describe your Issue

Whenever persistence is enabled, /var/www/html/lib and probably other files are not created. This leads to crashing and errors. I'm using NFS on all the volumes which could be making it slower and losing a data race somewhere.

Logs and Errors

Warning: require_once(/var/www/html/lib/versioncheck.php): Failed to open stream: No such file or directory in /var/www/html/cron.php on line 4
0

Fatal error: Uncaught Error: Failed opening required '/var/www/html/lib/versioncheck.php' (include_path='.:/usr/local/lib/php') in /var/www/htm
l/cron.php:40
Stack trace:
#0 {main}
  thrown in /var/www/html/cron.php on line 40

Describe your Environment

  • Kubernetes distribution: self hosted MicroK8s v1.28.9 revision 6750

  • Helm Version (or App that manages helm): helm v3.15.1

  • Helm Chart Version: 5.0.0

  • values.yaml:

cronjob:
  enabled: true
  # lifecycle:
  #   postStartCommand: ["chown -R www-data:www-data /var/www/html"]
  # securityContext:
  #   runAsNonRoot: false
externalDatabase:
  enabled: true
  existingSecret:
    enabled: true
    passwordKey: mariadb-password
    secretName: mariadb-passwords
    usernameKey: mariadb-username
internalDatabase:
  enabled: false
mariadb:
  auth:
    existingSecret: mariadb-passwords
  enabled: true
  primary:
    persistence:
      enabled: true
nextcloud:
  configs:
    # add k8s pod namespace to trusted proxies, set phone region and maintenance window start time to 1am
    mycustom.config.php: |
      <?php
      $CONFIG = array(
        'trusted_proxies' => array('10.0.0.0/8'),
        'default_phone_region' => 'US',
        'maintenance_window_start' => 1,
        );
  existingSecret:
    secretName: nextcloud-admin
persistence:
  enabled: true # disabling this allows all files to be created and container boots successfully
  # existingClaim: nextcloud-data
  nextcloudData:
    enabled: true
redis:
  auth:
    enabled: false
    existingSecret: redis-password
    existingSecretKey: redis-password
  enabled: true
service:
  type: LoadBalancer
image:
  pullPolicy: Always
  tag: stable-fpm```

## Additional context, if any
<!-- Also note any additional relevant info about your environment. -->
<!-- example: If your issue is related to persistent volumes, let us know you're using NFS or EFS, for instance. -->
@tvories
Copy link
Collaborator

tvories commented Jun 18, 2024

I think I'm having this issue as well. Whenever I try to do an upgrade, my occ binary doesn't always update to the latest file

@provokateurin
Copy link
Member

#584 this issue just got transferred here, maybe it is related?

@luna-xenia
Copy link

Same issue here, meaning I cannot access the nextcloud instance at all as the pod goes into a CrashLoopBackOff status

@v1nsai
Copy link
Author

v1nsai commented Jun 22, 2024

In my case I'm pretty sure its my NFS StorageClass that is at fault here. I'm getting abysmally slow read times (but not write) for some reason that I cannot replicate outside the container. Doing ps -aux | grep entrypoint.sh inside the nextcloud container shows that the entrypoint script is running, but getting interrupted when the container crashes due to the liveness probe.

I was able let the entrypoint script finish running by creating another Nextcloud container without the liveness probes to prevent timing out before (eventually) finishing. There were a lot of volume mounts, so I just pulled the generated Deployment yaml from my helm install using helm install nextcloud nextcloud/nextcloud --dry-run --debug -f values.yaml and removed the liveness probes to prevent it from crashing. I deployed it after deploying the nextcloud helm chart and left it for a few hours. When I came back everything was up.

EDIT:
There are switches to disable the probes already available in values.yaml 💀

@v1nsai
Copy link
Author

v1nsai commented Jun 23, 2024

Adding the following to my values.yaml allowed everything to boot normally (eventually), so if your StorageClass is too slow to let the entrypoint.sh script complete before crashing, try this:

livenessProbe:
  initialDelaySeconds: 7200
readinessProbe:
  initialDelaySeconds: 7200
startupProbe:
  initialDelaySeconds: 7200

@v1nsai v1nsai closed this as completed Jun 23, 2024
@jessebot jessebot added NFS to group together all NFS related issues Persistence Anything to do with external storage or persistence. This is also where we triage things like NFS. labels Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NFS to group together all NFS related issues Persistence Anything to do with external storage or persistence. This is also where we triage things like NFS.
Projects
None yet
Development

No branches or pull requests

5 participants