Restart causes excessive CPU consumption #300
Comments
|
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid. |
|
We don't recommend restarting apps inside the container. If you need to restart, you should restart the container. We have no control over how the apps try to restart themselves. It is often not compatible with our supervisor, S6, as you see in the logs. |
|
Agreed, restarting from within a container is a bad idea. I feel like from an end user perspective is where it may not be clear to a user why they need to initiate a restart using some other method when they get a "helpful" popup indicating they can just hit a button. As a seasoned user I literally thought "Oh this generally doesn't work very well but maybe linux server io has a way to handle it." I paid no attention to it until i noticed the high CPU utilization. In retrospect the settings requiring a restart probably never were applied. |
|
If you have a good solution, we're all ears. It would likely require upstream collaboration and changes for each app. |
|
The issue is that Sonarr is creating it's own process and terminating the original one. When s6 sees that sonarr has terminated its default behavior is to restart the service. The lowest impact option would be to include a finish s6 script that halts the container. Restart would then be handled by the end users container manger. Given that this is the main process of the container I don't think it's inappropriate to also halt the container. Is an s6 finish script for svc-sonarr something that fits both functionally and experience wise with linux server io? |
|
Our containers are designed to be running until stopped. S6 is there to restart the service if there is failure. With the behavior you describe, the user would click on restart in the gui and the container would stop, which is odd behavior in itself. You can't assume the users will set the container to |
|
Sonarr is removing the ability to restart in a container. |
Totally understand, thanks for your help and input. |
Is there an existing issue for this?
Current Behavior
See also #286. Initiating a restart through Sonarr causes excessive CPU usage due to a second sonar process also trying to start and bind to the same address. Observed through top inside the container a second sonarr process starts. It appears this second process tries to run migrations and bind to the address but crashes and gets restarted, causing the excessive cpu consumption. Restarting the pod results in a container with only one sonarr service running.
Expected Behavior
Sonarr restarts and only one service is active.
Steps To Reproduce
On settings > General page:
Environment
CPU architecture
x86-64
Docker creation
apiVersion: apps/v1 kind: Deployment metadata: name: sonarr namespace: default labels: app.kubernetes.io/name: sonarr spec: revisionHistoryLimit: 3 replicas: 1 strategy: type: Recreate selector: matchLabels: app.kubernetes.io/name: sonarr template: metadata: labels: app.kubernetes.io/name: sonarr spec: containers: - name: sonarr image: "quay.io/linuxserver.io/sonarr:4.0.9" imagePullPolicy: Always env: - name: PUID value: "1001" - name: PGID value: "1001" - name: TZ value: "America/Chicago" ports: - name: http containerPort: 8989 protocol: TCP volumeMounts: - name: sonarr-config mountPath: /config subPath: sonarr - name: data mountPath: /data volumes: - name: sonarr-config persistentVolumeClaim: claimName: config-data - name: data persistentVolumeClaim: claimName: media-data --- apiVersion: v1 kind: Service metadata: name: sonarr namespace: default labels: app.kubernetes.io/name: sonarr spec: type: ClusterIP ports: - port: 8989 targetPort: http protocol: TCP name: http selector: app.kubernetes.io/name: sonarrContainer logs
Logs prior to replicating issue on fresh container:
Logs on same container after proceadure:
The text was updated successfully, but these errors were encountered: