github-actions[bot]
commented
2 weeks ago Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
Closed CactusCollider closed 2 weeks ago
github-actions[bot]
commented
2 weeks ago Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
aptalca
commented
2 weeks ago 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.
CactusCollider
commented
2 weeks ago 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.
aptalca
commented
2 weeks ago If you have a good solution, we're all ears.
It would likely require upstream collaboration and changes for each app.
CactusCollider
commented
2 weeks ago 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?
aptalca
commented
2 weeks ago 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 restart=always.
Roxedus
commented
2 weeks ago Sonarr is removing the ability to restart in a container. https://github.com/Sonarr/Sonarr/pull/7136
CactusCollider
commented
2 weeks ago 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
restart=always.
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
Container logs
Logs prior to replicating issue on fresh container:
Logs on same container after proceadure: