[BUG] Curl stuck at 100% usage on a core #276

arkangelll13 · 2024-01-03T10:32:59Z

Is there an existing issue for this?

I have searched the existing issues

Current Behavior

Happy new year everyone!

Since the latest update to version 4.0.0.748 (1st of January) I'm seeing a curl process being stuck using 100% of a single core on my Synology NAS.
If I kill the process, it comes back, so something is obviously restarting it. This is the most I could gather about it.

    |-containerd-shim-+-s6-svscan-+-rc.init---s6-rc---s6-svlisten1---s6-ftrigrd
    |                 |           |-s6-notifyonchec-+-check---check-+-curl
    |                 |           |                 |               `-jq
    |                 |           |                 `-s6-ftrigrd
    |                 |           |-s6-supervise---s6-linux-init-s
    |                 |           |-s6-supervise---s6-ipcserverd
    |                 |           |-s6-supervise
    |                 |           |-s6-supervise---busybox
    |                 |           `-s6-supervise---Sonarr---26*[{Sonarr}]

Here is a picture of the container creation, since it was done on the GUI.

Could you please advise if I should go to Sonarr developers directly or you can look into it? Thank you.

Expected Behavior

Not running the core to 100%

Steps To Reproduce

Starting the Sonarr container. (Tested with a separate, completely new installation as well)

Environment

- OS: (Synology) DSM 7.2.1-69057 Update 3
- How docker service was installed: Built-in package manager ("Container Manager")
- Docker: 20.10.23-1437

CPU architecture

x86-64

Docker creation

---
version: "2.1"
services:
  sonarr:
    image: lscr.io/linuxserver/sonarr
    container_name: sonarr
    environment:
      - PUID=1030
      - PGID=100
      - TZ=Europe/Budapest
    volumes:
      - /volume1/docker/Sonarr:/config
      - /volume1/Videos/Series:/series
      - /volume1/Videos/Animated_Series:/animated
      - /volume1/Downloads/Sonarr:/downloads
    ports:
      - 8999:8989
    restart: unless-stopped

(Stole from another bug report and filled with my own variables, but I've also attached a screenshot)

Container logs

sonarr
date,stream,content
2024/01/03 11:15:00,stdout,crond[145]: USER root pid 403 cmd run-parts /etc/periodic/15min

2024/01/03 11:00:00,stdout,crond[145]: USER root pid 321 cmd run-parts /etc/periodic/hourly

2024/01/03 11:00:00,stdout,�[39;49mcrond[145]: USER root pid 320 cmd run-parts /etc/periodic/15min

2024/01/03 10:57:36,stdout,"�[39;49m�[39;49m�[37m[Info] RssSyncService: RSS Sync Completed. Reports found: 197, Reports grabbed: 0 
"
2024/01/03 10:57:34,stdout,�[39;49m�[39;49m�[37m[Info] DownloadDecisionMaker: Processing 197 releases 

2024/01/03 10:57:34,stdout,�[39;49m�[39;49m�[35m[Warn] Torznab: Indexer The Pirate Bay (Prowlarr) rss sync didn't cover the period between 1/3/2024 8:42:47AM and 1/3/2024 8:53:16AM UTC. Search may be required. 

2024/01/03 10:57:32,stdout,�[39;49m�[37m[Info] RssSyncService: Starting RSS Sync 

2024/01/03 10:45:00,stdout,�[39;49mcrond[145]: USER root pid 234 cmd run-parts /etc/periodic/15min

2024/01/03 10:36:31,stdout,�[39;49m�[39;49m�[37m[Info] Microsoft.Hosting.Lifetime: Content root path: /app/sonarr/bin 

2024/01/03 10:36:31,stdout,�[39;49m�[39;49m�[37m[Info] Microsoft.Hosting.Lifetime: Hosting environment: Production 

2024/01/03 10:36:31,stdout,�[39;49m�[39;49m�[37m[Info] Microsoft.Hosting.Lifetime: Application started. Press Ctrl+C to shut down. 

2024/01/03 10:36:27,stdout,�[39;49m�[39;49m�[37m[Info] Microsoft.Hosting.Lifetime: Now listening on: http://[::]:8989 

2024/01/03 10:36:25,stdout,�[39;49m�[39;49m�[37m[Info] MigrationController: *** Migrating data source=/config/logs.db;cache size=-20000;datetimekind=Utc;journal mode=Wal;pooling=True;version=3;busytimeout=100 *** 

2024/01/03 10:36:25,stdout,�[39;49m�[39;49m�[37m[Debug] Microsoft.Extensions.Hosting.Internal.Host: Hosting starting 

2024/01/03 10:36:25,stdout,�[39;49m�[39;49m�[37m[Debug] MigrationController: Took: 00:00:00.6874819 

2024/01/03 10:36:24,stdout,�[39;49m�[39;49m�[37m[Info] MigrationController: *** Migrating data source=/config/sonarr.db;cache size=-20000;datetimekind=Utc;journal mode=Wal;pooling=True;version=3;busytimeout=100 *** 

2024/01/03 10:36:24,stdout,�[39;49m�[39;49m�[37m[Info] AppFolderInfo: Data directory is being overridden to [/config] 

2024/01/03 10:36:23,stdout,�[39;49m�[39;49m�[37m[Info] AppFolderInfo: Data directory is being overridden to [/config] 

2024/01/03 10:36:23,stdout,�[39;49m�[39;49m�[37m[Debug] Bootstrap: Console selected 

2024/01/03 10:36:23,stdout,�[39;49m�[39;49m�[37m[Info] AppFolderInfo: Data directory is being overridden to [/config] 

2024/01/03 10:36:23,stdout,�[?1h�=�[39;49m�[37m[Info] Bootstrap: Starting Sonarr - /app/sonarr/bin/Sonarr - Version 4.0.0.748 

2024/01/03 10:36:21,stdout,"crond[145]: crond (busybox 1.36.1) started, log level 5
"
2024/01/03 10:36:21,stdout,"[custom-init] No custom files found, skipping...
"
2024/01/03 10:36:21,stdout,

2024/01/03 10:36:21,stdout,───────────────────────────────────────

2024/01/03 10:36:21,stdout,User GID:    100

2024/01/03 10:36:21,stdout,User UID:    1030

2024/01/03 10:36:21,stdout,

2024/01/03 10:36:21,stdout,───────────────────────────────────────

2024/01/03 10:36:21,stdout,GID/UID

2024/01/03 10:36:21,stdout,───────────────────────────────────────

2024/01/03 10:36:21,stdout,

2024/01/03 10:36:21,stdout,https://www.linuxserver.io/donate/

2024/01/03 10:36:21,stdout,To support LSIO projects visit:

2024/01/03 10:36:21,stdout,

2024/01/03 10:36:21,stdout,Sonarr: https://sonarr.tv/donate

2024/01/03 10:36:21,stdout,To support the app dev(s) visit:

2024/01/03 10:36:21,stdout,

2024/01/03 10:36:21,stdout,───────────────────────────────────────

2024/01/03 10:36:21,stdout,   Brought to you by linuxserver.io

2024/01/03 10:36:21,stdout,

2024/01/03 10:36:21,stdout,      ╚══════╝╚══════╝╚═╝ ╚═════╝ 

2024/01/03 10:36:21,stdout,      ███████╗███████║██║╚██████╔╝

2024/01/03 10:36:21,stdout,      ██║     ╚════██║██║██║   ██║

2024/01/03 10:36:21,stdout,      ██║     ███████╗██║██║   ██║

2024/01/03 10:36:21,stdout,      ██║     ██╔════╝██║██╔═══██╗

2024/01/03 10:36:21,stdout,      ██╗     ███████╗██╗ ██████╗ 

2024/01/03 10:36:21,stdout,

2024/01/03 10:36:21,stdout,───────────────────────────────────────

2024/01/03 10:36:21,stdout,usermod: no changes

2024/01/03 10:36:21,stdout,[migrations] no migrations found

2024/01/03 10:36:21,stdout,[migrations] started

The text was updated successfully, but these errors were encountered:

github-actions · 2024-01-03T10:33:23Z

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

Roxedus · 2024-01-03T10:34:25Z

known issue with EOL kernels. https://info.linuxserver.io/issues/2023-12-30-synology/

wegenmic · 2024-01-03T20:06:52Z

While searching for this issue, I found alpinelinux/docker-alpine#366
I'm not 100% sure about the root cause, so it might be a different issue, but the suggested change (updating to c-ares 1.24.0-r0) solved my problem.

My problems started with the change from https://github.com/linuxserver/docker-sonarr/pull/272/commits and match the description above. So what I did was log into the docker container in question
docker exec -ti <container_id> sh
Because Alpine 3.19 is using c-ares 1.22.1-r0, I referenced Alpine edge, which is already using c-ares 1.24.0-r0
apk add c-ares=1.24.0-r0 --repository=http://dl-cdn.alpinelinux.org/alpine/edge/main
apk upgrade
With curl --version you should see, that it's using c-ares/1.24.0
After that I simply restarted the docker container.

Everything went back to normal. Didn't notice any negative side effects so far.
Maybe this can be an alternative workaround to https://info.linuxserver.io/issues/2023-12-30-synology/
There might be some use cases where an older tag is simply not working. For example, does a Sonarr V4 database work when rolling back to v3?

aptalca · 2024-01-03T20:22:16Z

This should fix it:
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58154

arkangelll13 · 2024-01-03T21:09:36Z

While searching for this issue, I found alpinelinux/docker-alpine#366 I'm not 100% sure about the root cause, so it might be a different issue, but the suggested change (updating to c-ares 1.24.0-r0) solved my problem.

My problems started with the change from https://github.com/linuxserver/docker-sonarr/pull/272/commits and match the description above. So what I did was log into the docker container in question docker exec -ti <container_id> sh Because Alpine 3.19 is using c-ares 1.22.1-r0, I referenced Alpine edge, which is already using c-ares 1.24.0-r0 apk add c-ares=1.24.0-r0 --repository=http://dl-cdn.alpinelinux.org/alpine/edge/main apk upgrade With curl --version you should see, that it's using c-ares/1.24.0 After that I simply restarted the docker container.

Everything went back to normal. Didn't notice any negative side effects so far. Maybe this can be an alternative workaround to https://info.linuxserver.io/issues/2023-12-30-synology/ There might be some use cases where an older tag is simply not working. For example, does a Sonar V4 database work when rolling back to v3?

That actually solved the issue right away, just like you said after restarting the container the curl loop was no more. Thanks a lot man, I haven't had clue of apk, would've never figured it out! :)

EpicLPer · 2024-01-08T11:03:03Z

While searching for this issue, I found alpinelinux/docker-alpine#366 I'm not 100% sure about the root cause, so it might be a different issue, but the suggested change (updating to c-ares 1.24.0-r0) solved my problem.

My problems started with the change from https://github.com/linuxserver/docker-sonarr/pull/272/commits and match the description above. So what I did was log into the docker container in question docker exec -ti <container_id> sh Because Alpine 3.19 is using c-ares 1.22.1-r0, I referenced Alpine edge, which is already using c-ares 1.24.0-r0 apk add c-ares=1.24.0-r0 --repository=http://dl-cdn.alpinelinux.org/alpine/edge/main apk upgrade With curl --version you should see, that it's using c-ares/1.24.0 After that I simply restarted the docker container.

Everything went back to normal. Didn't notice any negative side effects so far. Maybe this can be an alternative workaround to https://info.linuxserver.io/issues/2023-12-30-synology/ There might be some use cases where an older tag is simply not working. For example, does a Sonarr V4 database work when rolling back to v3?

I tried this but sadly it didn't change anything for me, curl is still running in an endless loop.

arkangelll13 · 2024-01-08T12:31:44Z

While searching for this issue, I found alpinelinux/docker-alpine#366 I'm not 100% sure about the root cause, so it might be a different issue, but the suggested change (updating to c-ares 1.24.0-r0) solved my problem.
My problems started with the change from https://github.com/linuxserver/docker-sonarr/pull/272/commits and match the description above. So what I did was log into the docker container in question docker exec -ti <container_id> sh Because Alpine 3.19 is using c-ares 1.22.1-r0, I referenced Alpine edge, which is already using c-ares 1.24.0-r0 apk add c-ares=1.24.0-r0 --repository=http://dl-cdn.alpinelinux.org/alpine/edge/main apk upgrade With curl --version you should see, that it's using c-ares/1.24.0 After that I simply restarted the docker container.
Everything went back to normal. Didn't notice any negative side effects so far. Maybe this can be an alternative workaround to https://info.linuxserver.io/issues/2023-12-30-synology/ There might be some use cases where an older tag is simply not working. For example, does a Sonarr V4 database work when rolling back to v3?

I tried this but sadly it didn't change anything for me, curl is still running in an endless loop.

Have you confirmed the c-ares version after the upgrade?

AndreasWelch · 2024-01-08T19:53:06Z

My problems started with the change from https://github.com/linuxserver/docker-sonarr/pull/272/commits and match the description above. So what I did was log into the docker container in question docker exec -ti <container_id> sh Because Alpine 3.19 is using c-ares 1.22.1-r0, I referenced Alpine edge, which is already using c-ares 1.24.0-r0 apk add c-ares=1.24.0-r0 --repository=http://dl-cdn.alpinelinux.org/alpine/edge/main apk upgrade With curl --version you should see, that it's using c-ares/1.24.0 After that I simply restarted the docker container.

Unfortunately, when trying this, I get:

root@linuxserver-sonarr1:/# apk add c-ares=1.24.0-r0 --repository=http://dl-cdn.a
lpinelinux.org/alpine/edge/main
ERROR: unable to select packages:
c-ares-1.22.1-r0:
breaks: world[c-ares=1.24.0-r0]
satisfies: libcurl-8.5.0-r0[so:libcares.so.2]

wegenmic · 2024-01-08T20:01:47Z

@AndreasWelch it seems c-ares was updated to 1.25.0-r0 on edge 1 day ago.

EpicLPer · 2024-01-09T04:54:25Z

Have you confirmed the c-ares version after the upgrade?

Heya, sorry I wasn't able to properly test this yesterday.
It seems I'm getting the same error as @AndreasWelch is getting here:

ERROR: unable to select packages:
  c-ares-1.22.1-r0:
    breaks: world[c-ares=1.24.0-r0]
    satisfies: libcurl-8.5.0-r0[so:libcares.so.2

Tho, honestly, I'm really thinking of just ditching Synology's Docker implementation and setting up (yet another) Docker host for those. I've ran into quite a few outdated/incompatibility issues already which are annoying me, Synology really needs to step up their kernel game ;)

AndreasWelch · 2024-01-09T16:51:23Z

Thanks @wegenmic . Swapping to 1.25 for the command did it. I killed the curl process and now we're perfect.

Roxedus closed this as completed Jan 3, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG] Curl stuck at 100% usage on a core #276

[BUG] Curl stuck at 100% usage on a core #276

arkangelll13 commented Jan 3, 2024

github-actions bot commented Jan 3, 2024

Roxedus commented Jan 3, 2024

wegenmic commented Jan 3, 2024 •

edited

aptalca commented Jan 3, 2024

arkangelll13 commented Jan 3, 2024

EpicLPer commented Jan 8, 2024

arkangelll13 commented Jan 8, 2024

AndreasWelch commented Jan 8, 2024

wegenmic commented Jan 8, 2024

EpicLPer commented Jan 9, 2024

AndreasWelch commented Jan 9, 2024

[BUG] Curl stuck at 100% usage on a core #276

[BUG] Curl stuck at 100% usage on a core #276

Comments

arkangelll13 commented Jan 3, 2024

Is there an existing issue for this?

Current Behavior

Expected Behavior

Steps To Reproduce

Environment

CPU architecture

Docker creation

Container logs

github-actions bot commented Jan 3, 2024

Roxedus commented Jan 3, 2024

wegenmic commented Jan 3, 2024 • edited

aptalca commented Jan 3, 2024

arkangelll13 commented Jan 3, 2024

EpicLPer commented Jan 8, 2024

arkangelll13 commented Jan 8, 2024

AndreasWelch commented Jan 8, 2024

wegenmic commented Jan 8, 2024

EpicLPer commented Jan 9, 2024

AndreasWelch commented Jan 9, 2024

wegenmic commented Jan 3, 2024 •

edited