-
|
Ever since about a month ago, all of my Quadlet services except one have been timing out and failing when my server reboots. They launch fine when I restart them though. All of them are dependent on another Quadlet service (my reverse proxy), and that one doesn't time out. Here is the log for one of them: This is the service file for my reverse proxy:
Here's the service file for one of my services that is timing out:
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 19 replies
-
|
Have you tried to extend the start up time of the service. I would bet that Podman is attempting to update the container/image within the Kubernetes yaml, and systemd gives a service only 90 seconds by default to start. If pulling the updated images takes more then 90 seconds, you could have a problem. |
Beta Was this translation helpful? Give feedback.
-
|
I upped all of my service timeouts to 180, and that seemed to work after I rebooted, for all but one service. I upped that to 260, rebooted, and now my reverse proxy is failing: I deleted the Edit: Fixed that with |
Beta Was this translation helpful? Give feedback.
-
|
In case @rhatdan's suggestion doesn't work, please share the output of |
Beta Was this translation helpful? Give feedback.
-
|
I upped the timeout, and that seems to fix it. My images aren't being pulled though, so I think my computer is just slow. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think this is quite fixed. The services are still taking a ridiculously long time to start, even with a new, much faster CPU. They're not even pulling anything. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think so? It's pretty standard stuff. apiVersion: v1
kind: Pod
metadata:
labels:
app: authelia-pod
name: authelia-pod
spec:
hostname: authelia-pod
securityContext:
seLinuxOptions:
type: spc_t
containers:
- name: authelia
image: ghcr.io/authelia/authelia:latest
imagePullPolicy: Never
#args:
#- --config
#- /config/configuration.yml
env:
- name: AUTHELIA_JWT_SECRET
value: REDACTED
- name: AUTHELIA_STORAGE_ENCRYPTION_KEY
value: REDACTED
- name: AUTHELIA_NOTIFIER_SMTP_PASSWORD
value: REDACTED
- name: AUTHELIA_IDENTITY_PROVIDERS_OIDC_HMAC_SECRET
value: REDACTED
- name: AUTHELIA_IDENTITY_PROVIDERS_OIDC_ISSUER_PRIVATE_KEY
value: REDACTED
- name: AUTHELIA_SESSION_SECRET
value: REDACTED
volumeMounts:
- mountPath: /config
name: authelia-config
- name: redis
image: docker.io/library/redis:latest
#args:
#- redis-server
volumeMounts:
- mountPath: /data
name: redis-data
volumes:
- name: redis-data
persistentVolumeClaim:
claimName: redis
- hostPath:
path: /home/cassidy/.config/containers/systemd/services/authelia/authelia
type: Directory
name: authelia-config |
Beta Was this translation helpful? Give feedback.
-
|
Is |
Beta Was this translation helpful? Give feedback.
-
|
Isn't this because it doesn't have permission to access the container? I should also mention that this wasn't happening some months ago. They all just started timing out at once, seemingly randomly. Maybe it was an update that caused it. I even updated my CPU, and it's still happening. |
Beta Was this translation helpful? Give feedback.
-
|
Yes as a confined process it will not be allowed to use /data. Are these directories Could this be some kind of chowning? Just for kicks could you boot the system with "enforcing=0" to see if this is something SELinux is doing. |
Beta Was this translation helpful? Give feedback.
-
This is weird, I can't seem to find
I tried that, and for the first two reboots it seemed like it had worked, but then I rebooted for a third time and Authelia had timed out again. It seems pretty random whether or not a service will timeout. |
Beta Was this translation helpful? Give feedback.
Have you tried to extend the start up time of the service. I would bet that Podman is attempting to update the container/image within the Kubernetes yaml, and systemd gives a service only 90 seconds by default to start. If pulling the updated images takes more then 90 seconds, you could have a problem.