Plex spawns so many processes it drives the server to an OOM

Plex Media Server NAS & Devices
1

Server Version#: 1.14.1.5488
Player Version#: 3.77.4

Plex is spawning so many rogue processes that it literally drove my server to an OOM. Fortunately the server recovered enough to allow me to send a pkill -u Plex command to it and it freed up 4 GB of my memory. Because my system uses ZFS most of the memory is allocated to the file system. I did a rough count and counted about 100 rogue processes in memory that were never purged when Plex needed to be rebooted. With that being said, I’m guessing this may also be a source of Plex crashing with the more recent builds.

Now I know I should probably up the server RAM, and I will in the near future but Plex should not be spawning so many rogue processes and filling up the RAM like this.

2

Is this FreeBSD, FreeNAS, jail? host?

The process start/restart is managed by the rc.d script, maybe it not killing the old processes?

I’m guessing this may also be a source of Plex crashing with the more recent builds. can you show more evidence of this? PMS logs? dmesg maybe?

I run my ms server on FreeBSD and I’m not noticing this crashes.

Do you have data on what were the processes that were left running? Is it PMS or transcoder? Scanner? Tuner Service etc? If we have more details on that it might be easier to find what is happening too. I.E. if those were all the Transcoder it could be possibel that sessions were not being terminated, which would be a bug for sure (but I don’t see that in my server so I doubt it, since I’m running the same version exactly)

3

This is XigmaNAS, which is based on FreeBSD, and it is not a jail. It is a dedicated NAS server. PMS logs seem the just end without any indication of why it crashes, as if the process just dies. Oddly enough the child processes linger. My Plex server has been crashing every day since the builds came out a few months back. Before then, it was rock solid stable. Now, since I’m located far away from the server, I had to deal with an OOM issue because when I checked ‘top’ I saw what I roughly counted 100 processes coming from the user ‘plex’, but the service itself was in a stopped state. Once I finally managed to send the pkill -u plex command to the server, RAM usage dropped 4 GB and FreeBSD recovered completely. I then restarted it and all seemed well until it just crashed again 30 minutes ago. I can send you the logs via PM, as I’m not comfortable posting them in public domain if that is alright.

As for dmesg, what is that? Lingering processes were mostly the tuner and script host processes, and some transcoder processes. The PMS process itself was also there no scanner service was visible IIRC. After the latest crash there are two left over processes which are still actively doing something. A script host, and the tuner service.

EDIT: After now rebooting the PMS process, it spawned two new script hosts, and a tuner service without killing the old ones.

4

The “Script Host” scripts can be normal, it will spawn more as needed, but I’m intrigued by “without killing the old ones.” do you mean you’re stopping PMS and the binaries stay there?

Also if the service was in a stopped stated and pms was still running than this is an indication it was the service that stopped but the process and its children were not stopped.

So lets try to debug from start, and I’m assuming this is just installed from “pkgng” and a plain FreeBSD install (there might be some XigmaNAS tweaks to the system involved but lets ignore that for now).

dmesg is a cmd, please run it and see if there are any lines related to errors (or processes dying). Just type dmesg -a as root post the output here (do parse any private info that might be present)

5

Oh also can you post the rc.conf with the lines related to PMS particaluary plexmediaserver_maxplugin ?

6

I haven’t actually stopped them myself. When PMS crashes those binaries stay there and are abandoned by newer instances of PMS. I’ve had to reboot PMS so many times in the past due to crashes, that I assumed it would just clear out the lingering processes on reboot and spawn new ones. It doesn’t. In the end my server suffered from an OOM, as I nuked over 100 processes started by Plex. I can certainly test it out and observe what happens. I’m only speaking about processes. I incorrectly interchanged service and process, where I meant process only. Yes, Plex was installed with the pkg command.

The output of the dmesg -a is:

pid 27412 (Plex Media Server), uid 972: exited on signal 11

7

This would indicate a segfault. As an added note, I did recently do a RAM stress test which passed. So no hardware issues here.

8

Here is rc.conf

plexmediaserver_plexpass_support_path="/mnt/Internal/plexpass/plexdata"
plexmediaserver_plexpass_tmp="/mnt/Internal/plextmp"
plexmediaserver_plexpass_maxplugins="6"
9

This is managed by the system though, I’m assuming you restart the service via “service plexmediaserver restart” since the process is supposedly dead the script starts a new one… You should see a message referring to the fact that the service was not start when the stop is attempted though.

And yes it seems its segfaulting and we need to find out why, however when this happen the process should not be there any longer, I mean the system its telling you the process was killed…

Can you actually see the same process id still running in the system? (Try: ps aux| grep plex i.e. and compare the pid’s)

I would still like to see logs btw in case they offer some clue to the segfault (please enable debug and maybe verbose mode too)

10

Well, kind of. I would assume the GUI which XigmaNAS has would be calling that. In XigmaNAS, there is a GUI that let’s you start/stop/restart the Plex service and I use that. As I’ve been using it for a long while, it’s reasonable to assume that the GUI isn’t doing anything wrong either.

The PMS process is not there after the segfault happens, but the remaining Tuner/Transcoder/Script Host processes are, and are using RAM/CPU. When the service is restarted, the those processes are not terminated, and so Plex will keep spawning new ones after every restart from a crash without wiping the old ones. This is what drove my server to an OOM before I managed to send a kill signal to the processes.

I’ll enable verbose and debugging, but we’ll have to wait for another segfault.

11

OK that’s makes sense and hence why I was asking which process are actually left, so none is really PMS!

This is normal, if a process segfaults.

As I said the service (or “daemon”) is managed by the rc.d script (I assume the GUI simply calls this script) and as long as all is ok the script is able to restart all normally (making sure previous instances are killed).
On a segfault its a bit different, PMS wouldn’t be running so you would get this on a terminal:

service plexmediaserver stop
plexmediaserver not running? (check /var/run/plex/plex.pid).

The rc.d script check if the process is running (and its not) so it moves along.

You can still stop all children if you run this mannually:
cat /var/run/plex/plex.pid This will get you the (now dead pms process id) then kill its children:

kill `pgrep -g 92379`

As I was trying to explain above this is not something plex can control, its the system than controls the services via the rc.d script, I do agree that this could be handled better, but we can’t do much since the rc.d script is not controlled by us.

You could try to edit the script manually and change the check (so it checks for children to no just the main process) but that might be to much work and it would be re-written on updates anyway.

With that said and this clarified I’d like to see Ive we can figure why we are getting the segfault, so I’ll wait for more logs on that…

Btw do u know which FreeBSD version is being used as a base?

12

Well I do have a suggestion. Since only Plex process are spawned as the user “Plex”, and “Plex” only, would it be unreasonable to have it check for other Plex spawned processes, and kill everyone of them, but it’s own, and then to spawn the new processes?

13

It’s not the ideal solution, the rc.d script should only kill the process it started before and it’s children… You can be running other things as that user.

But it’s you’re system, you’re call… You could put that in a cron script or something.

Either way we should true to find the cause of the default as it might be a legitimate bug in pms.

14

BTW, the FreeBSD version is FreeBSD 11.2-RELEASE-p3 #0 r338829M. I forgot to mention that. :slight_smile:

15

It segfaulted again. I have the logs. Where do you want them?

16

I somehow missed the notification for this… @Cyberpower678 you can DM them to me if you prefer (be sure to hide any sensitive information )

17

Actually I think I may have figured out the problem. The server’s ARC max setting was off so the ZFS was eventually crowding Plex out. Plex then tried to access unavailable memory, and not being able to cope with that, it segfaulted. I have reset my ARC settings. I will observe and see if the issue persists.

18

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