Plex regularly unavailable but shows as running on Qnap

Logs show:

  1. Start session (server.1.log)
Jul 21, 2019 22:53:19.011 [0x7f60fffff700] DEBUG - Created thumbnail of size 668x376, has pixels: 1
Jul 21, 2019 22:53:19.043 [0x7f6181a31700] DEBUG - Job running: '/share/CACHEDEV1_DATA/.qpkg/PlexMediaServer/CrashUploader' '--directory=/share/CACHEDEV1_DATA/.qpkg/PlexMediaServer/Library/Plex Media Server/Crash Reports/1.16.2.1297-4b7ace214' '--version=1.16.2.1297-4b7ace214' '--platform=Linux' '--platformVersion=QTS 4.3.6.0979' '--serverUuid=0c28f96454f433b59ec374d80e70f7e9d967094d' '--userId=eric.junk@tab-md.com' '--sentryUrl=https://sentry.io/api/1233455/minidump' '--sentryKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' '--vendor=QNAP' '--model=x86_64' '--device=TS-451+'
Jul 21, 2019 22:53:19.098 [0x7f6181a31700] DEBUG - Jobs: Starting child process with pid 30560
  1. Fresh start (Server.log)
Jul 22, 2019 00:25:47.050 [0x7f47c94b7700] INFO - Plex Media Server v1.16.2.1297-4b7ace214 - QNAP TS-451+ x86_64 - build: linux-x86_64 qnap - GMT -04:00
Jul 22, 2019 00:25:47.050 [0x7f47c94b7700] INFO - Linux version: QTS 4.3.6.0979, language: en-US
Jul 22, 2019 00:25:47.050 [0x7f47c94b7700] INFO - Processor       Intel(R) Celeron(R) CPU  J1900  @ 1.99GHz
Jul 22, 2019 00:25:47.050 [0x7f47c94b7700] INFO - ./Plex Media Server
Jul 22, 2019 00:25:46.911 [0x7f47d5c53740] DEBUG - BPQ: [Idle] -> [Starting]

There is indeed time missing.

I wonder if I need to see about auto-restart in QTS ?

Sorry, don’t follow your last sentence. Are you saying I should restart QNAP? Or that there ought to be a function for Plex to auto-restart itself?

The 44mb log directory I zipped up was before I restarted PMS. You said the log files were missing in there, but I was looking at them right up to 22:53…

ETA: I think I see what you’re saying. There was no additional activity logged between the crash and when I manually restarted. Maybe an auto-restart routine would help get it back up and running.

The bigger question (for me) is what is causing the crash in the first place? Prior to these issues about 2 months ago - I had a rock-solid, hands-off Plex server. Now, if I go more than 48 hrs without some family member or friend complaining about the server, it’s a long time.

On QNAP, if PMS stops for any reason, I don’t automatically restart it.
On Workstation Linux, it is automatically restarted immediately (up to 3 attempts).

It might be possible for me to do the same on QNAP.

Should it detect PMS has halted for any reason, within reasonable tolerance,

  1. Log and report this to you (QNAP logs)
  2. Restart PMS.

Sounds reasonable - certainly better than it is now. However, even better (or in addition to that) would be figuring out why it’s becoming unresponsive/crashing in the first place.

I noticed that in the crash report log, it’s failing to send the dump file to sentry.io. Is that relevant, or can you recover info from the logs you see now?

I agree entirely - There is no reason for it to behave as it is currently. Any work I might consider would be a) stopgap b) done in the same manner as traditional desktop Linux is - obeying those constraints

Ok, I’m just hoping you have enough from the logs to help track down the gremlin. If not, let me know how else I can help troubleshoot.

Also, since there seems to be some kind of miscommunication (at least on my system) between how the App Center sees the running processes, I’m hoping that whatever trigger you use to determine PMS is really no longer running, uses something other than the status as reported by the App Center…

The gremlin which stopped it would be with Engineering.

I’m with Support (and do the packaging – aka QPKG and how it runs on a particular host )

Fair enough. Just let me know what I can do to help in the process. Desperate to get this back to how it used to be… Have a good night!

you too. be well.

Just another quick question… does my discussion with you initiate the bug fix with engineering, or do I need to reach out to them separately? Also, if you could go back and remove my log/code that contains my email above, that would be great.

Thx.

This issue is already known to them. They have many reports (silently submitted “Crash Dump” reports) which they are already looking at.

We have a team member who is dedicated to going through them.

I cannot ask for anything more. Nothing is worse than thinking you’re the only one with a problem.

Again, I appreciate your help.

You’re very welcome. You’re not alone (unfortunately) but thanks to the data, they can usually find the problems quickly and start working on resolving them.

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