Disc access every 5 seconds

Plex Media Server
1

my setup:

docker compose running on debian bookworm.

# https://github.com/plexinc/pms-docker
services:
  plex:
    container_name: plex
    image: plexinc/pms-docker
    restart: unless-stopped
    environment:
      - TZ=Europe/Berlin
      - PLEX_CLAIM=xxxxxx
    network_mode: host
    volumes:
      - ./config:/config
      - ./transcode:/transcode
      - /mnt/zData/media:/data

My problem:

Every 5 seconds plex is accessing the disc. I see log entries in the console which corrspond to the disc usage:

Mar 18, 2025 18:28:39.335 [140522778487608] Debug — Request: [127.0.0.1:39744 (Loopback)] GET /identity (7 live) #dff Signed-in
Mar 18, 2025 18:28:39.335 [140522867743544] Debug — Completed: [127.0.0.1:39744] 200 GET /identity (7 live) #dff 0ms 417 bytes (pipelined: 1)
Mar 18, 2025 18:28:44.399 [140522778487608] Debug — Request: [127.0.0.1:39756 (Loopback)] GET /identity (7 live) #e09 Signed-in
Mar 18, 2025 18:28:44.399 [140522869852984] Debug — Completed: [127.0.0.1:39756] 200 GET /identity (7 live) #e09 0ms 417 bytes (pipelined: 1)
Mar 18, 2025 18:28:49.468 [140522778487608] Debug — Request: [127.0.0.1:59034 (Loopback)] GET /identity (7 live) #e10 Signed-in
Mar 18, 2025 18:28:49.468 [140522869852984] Debug — Completed: [127.0.0.1:59034] 200 GET /identity (7 live) #e10 0ms 417 bytes (pipelined: 1)
Mar 18, 2025 18:28:54.536 [140522778487608] Debug — Request: [127.0.0.1:59040 (Loopback)] GET /identity (4 live) #e17 Signed-in
Mar 18, 2025 18:28:54.536 [140522869852984] Debug — Completed: [127.0.0.1:59040] 200 GET /identity (4 live) #e17 0ms 417 bytes (pipelined: 1)
Mar 18, 2025 18:28:59.620 [140522778487608] Debug — Request: [127.0.0.1:39766 (Loopback)] GET /identity (4 live) #e21 Signed-in
Mar 18, 2025 18:28:59.620 [140522867743544] Debug — Completed: [127.0.0.1:39766] 200 GET /identity (4 live) #e21 0ms 417 bytes (pipelined: 1)
Mar 18, 2025 18:29:04.707 [140522778487608] Debug — Request: [127.0.0.1:39774 (Loopback)] GET /identity (4 live) #e28 Signed-in
Mar 18, 2025 18:29:04.707 [140522867743544] Debug — Completed: [127.0.0.1:39774] 200 GET /identity (4 live) #e28 0ms 417 bytes (pipelined: 1)
Mar 18, 2025 18:29:09.788 [140522778487608] Debug — Request: [127.0.0.1:47042 (Loopback)] GET /identity (4 live) #e2f Signed-in
Mar 18, 2025 18:29:09.788 [140522867743544] Debug — Completed: [127.0.0.1:47042] 200 GET /identity (4 live) #e2f 0ms 417 bytes (pipelined: 1)

I have disabled DEBUG output but this is still coming. What is this? How can I stop this?

2

Are you running Tautulli or some other tool?

What you’re showing is something hitting the API to see if the server is claimed.

3

I have nothing like this running. The debian server is running also a docker nextcloud image but that is it.

I have restarted the plex docker image. It now seems to honor the “no debug” setting and I dont see the HD LED going on every 5 seconds. I also do not see the messages in the log anymore.

Nevertheless, these request

 Request: [127.0.0.1:59034 (Loopback)] GET /identity

are still there I would assume. They are just invisible now.

What kind of port ist that?

39744, 39756, 47042 ,59034, 59040, ...

How can I stop this?

4

That’s expected. The restart to lower the logging level was implemented a couple of years ago as a security precaution. The idea being that you wouldn’t’ want someone gaining admin access to your server and you not knowing about because they lowered the logging level.

Those are the source ports. Those log messages all indicate that the requests are coming from localhost, with the specified source ports (which will always be a high, random one.

So you either have a client application running on the same host (unlikely) or one of the components of PMS itself is communicating with another (or the same one). PMS isn’t a single, monolithic application. It’s a collection of component apps and they communicate with each other using TCP/IP (using localhost).

One example of this is the Plex Transcoder. When in use, it and the main server binary will communicate status (and data?) via localhost. (That’s just an example, the transcoder wouldn’t be involved in your situation).

5

These requests are coming from the docker image healthcheck. You can override the healthcheck in your compose file and that’ll stop these requests. Docker records the outcome of the healthcheck which is likely the reason for the disk access (aside from the logging you disabled).

6

Yes, that was it.

I added this to the docker compose file:

healthcheck:
      test: [NONE]

That eliminates the log entries even with DEBUG enabled. Thank you!

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.