Plex PMS Container creates constant disk access load

I'm using OMV, Portainer and the PMS Plex:latest image.

Now I'm observing constant disk writes by this container. Every 2s approx. 300kb are written to the disk. I can not find out why, I have disabled logging already but still the behaviour persists.

Two questions here:

1. has anyone observed the same behaviour? Apparently it is not an issue with other docker images.

2. Some in the internet say it is because of of docker healthcheck and it can be disabled by using --no-healthcheck as extra args. Call me stupid but I have failed to find where to add any extra arguments in portainer? Isnt there a way?

Thank you and best regards

I think i found the root cause. In the PMS docker file the healthcheck does run every 5s.

HEALTHCHECK --interval=5s --timeout=2s --retries=20 CMD /healthcheck.sh exit 1

And healthcheck.sh performs a curl which writes to the local disk. This is exactly what I’m seeing, only writes every 5s and everytime the same size.

#!/bin/sh -e

TARGET=localhost

CURL_OPTS="–connect-timeout 15 --max-time 100 --silent --show-error --fail"

curl {CURL_OPTS} "http://{TARGET}:32400/identity" >/dev/null

Still don't know how to get rid of that behaviour and how I could inject the --no-healthckeck command into Portainer. It seems that there was a feature request since two years to have that added but apparently it was never considered. I'm wondering that being able to use extra args is nothing other user permanently stumble over...

Hi gderf, thanks for the advice. Unfortunately if I do it the way you describe my container would start but not work properly. Normally the disabled healthcheck should not interfere with the container operation but I assume it somehow interferes with the entrypoint. If I remove the command again the container works like a charm again.

Anyway I have doubts that the healthchecks are the root cause. I had a closer look on the curl command and without -o it would not write to the disk. So it might not be the culprit anyhow. But still intriguing why the container would not work with healthcheckcs disabled.

Ok, I have a new update.

It is the Plex container creating the writes, but not Plex itself but Docker and yes it is realted to the healthcheck. Apparently the check itself does not create the io but docker is updating the result of the healthcheck everytime in hostconfig.json and config.v2.json and since Plex is running the healthcheck every 5s it updates every 5s the files. Now that I have figured out where this is originating from I found others having the same issue:

https://forums.unraid.net/bug-…mg-every-5-seconds-r1079/

and somebody also filed a bug report for docker: https://github.com/distribution/distribution/issues/3268

But not sure this is necessarily a docker error. Unfortunately my plex container does not like for some reason when I add the command --no-healthcheck to disable the behaviour. It would then not start at all. That might be related to portainer.

I raised the error already with Plex, lets see if they are going to fix it. But im wondering that nobody else here is having the issue? Any further ideas why the --no-healthcheck would not work? I assume it is somehow related with the entrypoint but i have not enough insights into docker containers/images to really fully understand what is happending.

Yes, linuxserver solved it. But I realized it is a docker bug. Everytime a healthcheck in any container is run docker would update hostconfig.json and config.v2.json even if the state did not change.

Plex was updating every 5s which is solved now with the linuxserver image.

Shinobi I could add --no-healthcheck which fixed shinobi

For syncthing the --no-healthcheck did not work out. I assume it is somehow realted to the entrypoint and finding the right formatting in portainer.

I now only have syncthing updating the hostconfig but not as regularly, approx 10-15s which is already much better than every 5s.

If anybody has an idea on how to get --not-healthcheck working when using an entrypoint please let me know.

But still intriguing that docker is not fixing that behaviour.