Unable to Restart Plex Service on QNAP

Server Version#: 1.32.0.6950
Plex Media Server Logs_2023-04-17_16-13-17.zip (1.7 MB)

A year or so back, there was a fix put in that fixed the ability to Stop and Restart the Plex service on a QNAP bare metal install without having to restart the whole box. Recently I have experienced intermittent success with this as I could normally coax it back online with a few Stops and Starts.

More recently, it seems that I’ve had to revert back to restarting the whole box to get it back up and running. Any suggestions are appreciated. Logs attached.

A process is stuck and holding it open -OR- the ports haven’t recycled in time (more likely).

Apr 17, 2023 15:36:08.072 [0x7fb74b1e9b38] INFO - Plex Media Server v1.32.0.6950-8521b7d99 - QNAP TVS-h1688X x86_64 - build: linux-x86_64 qnap - GMT -05:00
Apr 17, 2023 15:36:08.073 [0x7fb74b1e9b38] INFO - Linux version: QTS 5.0.1.2348, language: en-US
Apr 17, 2023 15:36:08.073 [0x7fb74b1e9b38] INFO - Processor: 12-core Intel(R) Xeon(R) W-1250 CPU @ 3.30GHz
Apr 17, 2023 15:36:08.073 [0x7fb74b1e9b38] INFO - Compiler is - Clang 11.0.1 (https://plex.tv 9b997da8e5b47bdb4a9425b3a3b290be393b4b1f)
Apr 17, 2023 15:36:08.073 [0x7fb74b1e9b38] INFO - ./Plex Media Server
Apr 17, 2023 15:36:08.073 [0x7fb74b456a90] DEBUG - BPQ: [Idle] -> [Starting]
Apr 17, 2023 15:36:08.073 [0x7fb74b456a90] DEBUG - FeatureManager: Using cached data for features list
Apr 17, 2023 15:36:08.110 [0x7fb74b456a90] DEBUG - [CERT] Subject name is /CN=*.e1231e7a48554e098244776a385784ce.plex.direct
Apr 17, 2023 15:36:08.110 [0x7fb74b456a90] DEBUG - [CERT] Installed certificate with fingerprint 32:ff:ea:08:ef:02:48:e8:d4:54:42:6b:1e:8c:73:7d:80:2a:45:36.
Apr 17, 2023 15:36:08.110 [0x7fb74b456a90] DEBUG - [CERT/OCSP] Stapling requests will be made to 'http://r3.o.lencr.org/'.
Apr 17, 2023 15:36:08.110 [0x7fb74b456a90] INFO - [CERT/OCSP] Successfully retrieved response from cache.
Apr 17, 2023 15:36:08.110 [0x7fb74b456a90] DEBUG - HttpServer: Listening on IPv6 as well as IPv4.
Apr 17, 2023 15:36:08.110 [0x7fb74b456a90] ERROR - HttpServer: Error binding acceptor: Address in use
Apr 17, 2023 15:36:08.110 [0x7fb74b456a90] ERROR - HttpServer: Error opening acceptor on IPv6, falling back to IPv4: Address in use
Apr 17, 2023 15:36:08.110 [0x7fb74b456a90] ERROR - HttpServer: Error binding acceptor: Address in use
Apr 17, 2023 15:36:08.156 [0x7fb74b456a90] DEBUG - [JobRunner] Job running: /share/ZFS530_DATA/.qpkg/PlexMediaServer/CrashUploader "--directory=/share/ZFS530_DATA/.qpkg/PlexMediaServer/Library/Plex Media Server/Crash Reports/1.32.0.6950-8521b7d99" --version=1.32.0.6950-8521b7d99 --platform=Linux "--platformVersion=QTS 5.0.1.2348" --serverUuid=9502ba3a75c4b272b360907c09798b3601e73788 --userId=godfatherhopkins@sbcglobal.net --sentryUrl=https://o17675.ingest.sentry.io/api/1233455/minidump/ --sentryKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --vendor=QNAP --model=x86_64 --device=TVS-h1688X
Apr 17, 2023 15:36:08.156 [0x7fb74b456a90] DEBUG - [JobRunner] Jobs: Starting child process with pid 8502

I had written the scripting to allow time for normal PMS shutdown then it does a very forcefull KILL (segmentation violation signal) which makes QTS/QuTS kill it

I’ve never had the scripting fail.

The only way to debug this is :

  1. Stop PMS.
  2. Start PMS
  3. If it fails to start
    – SSH into the box,
    ps -ef | grep -i plex
    netstat -an | grep 32400
  4. Let me know what you find.

IF the processes are gone but sockets are still there -

  1. Don’t restart it so fast !!! lol
  2. Report QTS/QuTS bug to QNAP

Thanks for the quick reply. I shall test this tomorrow, as I have some evening traffic starting up. :slight_smile:

EDIT: To add, my initial issue was upon applying the most recent update. I’ve never had it hang on one of those and experienced a small heart attack when it happened. :stuck_out_tongue:

One thing you will see more of now is the ‘503’ message from Plex/web during startup.

Engineering is presenting that message for all server startup tasks until it’s fully ready.

The device apps know to wait-retry.

What I’m getting is all of the standard Plex web sources load, and the error symbols on my own. Am I just not being patient enough? I stop the service… Wait about 10 or so seconds, and then Start it back up. I give it a minute or two refreshing the webpage before I give up and give it another go.

By definition on Linux sockets. The ‘TIME_WAIT’ when a socket closes (which is how the OS closes them) can be up to 60 seconds.

Perhaps I should test my patience first… lol

:beers:

anyone?

:slight_smile:

1 Like

Appears that waiting 60 seconds after the shutdown, restarting and waiting another 60 seconds does the trick. Was super concerned when I couldn’t coax it back after an update… but I also probably shouldn’t attack the Refresh button like a six-year-old on Christmas morning.

Thanks, Chuck!

So it appears this may not be over for me. I’m doing a pretty large scale music file update and she seems to dead crash trying to keep up on Sonic Analysis. I have it disabled until the files have all updated (tags). She’s still crashing on the overnight scans though.

I know working with live files in a directory is not ideal. I’m considering disconnecting it until the updates have finished, but I’m then worried about reimporting the whole thing.

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