[Ubuntu 16.04 and official Docker image] System.bundle stops responding



I am having an issue with Plex Media Server, including versions through current, I originally had the issue under a native install in Ubuntu 16.04, so I tried moving to docker (where I am now), and the issue persisted.

1) Matching stops working. Automatic matching doesn't match anything, and trying to match manually results in a timeout (There was a problem...)
2) Server settings page cannot be loaded (Results in "Server settings are unavailable.")
3) Content art doesn't display for random selection of items (locally cached works, maybe?) Displays the gray PC monitor look'n icon instead of the art.

This can occur after a couple days of uptime, or a few hours, it seems entirely random. I've had to setup cron to originally restart plex, and now restart the docker container, nightly. Even so, it still can happen within the 24 hour window, sometimes as early as a few hours after startup.

I've determined the System.bundle appears to be to blame. In the logs, the problem is indicated by a lot of curl_easy_perform timeout errors, all against the current port System.bundle is listening on, as shown in the attached log file. The com.plexapp.system.log shows nothing eventful going on, and a strace on the process shows just a bunch of what appear to be busylooping threads. In a normal, non-docker install, the issue can be resolved by killing the pid of the System.bundle python instance, and letting plex re-spawn it. This doesn't seem to work for a docker instance, as it doesn't appear to respawn the process.

I've had this issue since at least (the latest I made notes from), up to the most current version, It occurs both under a standard install in Ubuntu 16.04, and the official Plex docker image. The library was preserved during the move to docker, and I have checked the sqlite databases for any corruption, and they all seem to check out.



I've the same issue as this.

1) Matching stops working. Automatic matching doesn't match anything, and trying to match manually results in a timeout (There was a problem...)

If I reboot my Unraid server I can match one or two files, but after that, I get the same issue.


This has happened twice more since posting, even with nightly restarts. I did confirm I was able to clear the issue, even in docker, by killing com.plexapp.system. As soon as I killed it, the artwork started fully populating in the library views, and Settings/Server started loading. After hitting Settings/Server, the com.plexapp.system process was respawned automatically.

I’d really love some Plex dev insight here, it feels like its getting stuck waiting for some external event, but I have no idea how to determine what that is. I am familiar with python, but not Plex’s framework.


This (or something similar) started happening to us recently. We use docker, and at one point it stopped matching new media (says no results found for every agent and query), and didn’t recognise subtitles that were manually added next to the video file (worked fine on another plex server with same files). I advised server owner to restart the container, but after that started the “Server settings are unavailable.” error, and many plugins missing from Channels section, like sub-zero and webtools. Also no agents on library Edit, and “Loading…” instead of agents on match (or just match to an empty value). Webtools page doesn’t open now too, so I don’t have an easy access to debug logs, but probably will get them eventually.

What do you mean by killing ‘com.plexapp.system’ ? Kill every process within plex container with such name?

How often does it repeat itself after the fix? Or did it stop breaking? Does fresh install of server fixes it for the time being? And is there a safe way to transfer all the settings/libraries/metadata to a new server instance without transferring the bug too?


There’s one System.bundle process running. You can kill it from within the container, or outside, it doesn’t matter. Something like the below will work:
pkill -f System.bundle

Afterwards, just do a force reload of the landing page and it’ll spawn a new System.bundle.

It reoccurs about as often as the initial occurrence. It seems to be related to library scanning; if I reduce the interval, it seems to go longer between lockups. It continues to be a problem for me, but as no devs seem to care, I’m just living with it for now.