Today I had my preferences.plist file wiped from my server…twice! Not sure why but I think maybe a bug in the latest update? (1.13.3.5223-cd1e0da1b) My server goes offline and the only way I can connect is by manually browsing to ip:32400/web. When I go there, it starts the initial setup wizard as if I was starting a brand new install of the server. After I reconfigured it back up a few hours later it did the same thing. Has anyone else had a similar issue?
CentOS 7
Plex Pass
If we can clear up a few misunderstandings?
On Linux, PMS runs as user plex and puts it’s Preferences.xml file in /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Preferences.xml
On MacOS, PMS runs under your username and puts its preferences in ~/Library/Application Support/Plex Media Server/Preferences.plist
When you say it erased your preferences, do you mean the account information recorded there is erased? (It’s the only real thing in there that’s of major importance). If the file is gone, yes PMS will start the first-run setup wizard again. There is a flag in Preferences AcceptedEULA="1" which tells it setup is complete.
Have you performed any customizations to your PMS configuration (like moving from /var/lib/plexmediaserver ?
Of the above, what can you replicate and then manually capture in the log files (a .tar.gz of ./Logs) which you attach here so I can follow along and we can resolve this?
Sorry I meant Preferences.xml. It is a linux server on CentOS.
This is what shows up in the Preferences.xml file:
<?xml version="1.0" encoding="utf-8"?>
<Preferences OldestPreviousVersion="1.13.3.5223-cd1e0da1b" MachineIdentifier="redacted" ProcessedMachineIdentifier="redacted" AnonymousMachineIdentifier="redacted" MetricsEpoch="1"/>
I don’t have any customizations. I’ve attached the logs but I’m not sure if it captured the problem before it rotated the logs.
logs.tar.gz (4.9 MB)
Here it’s happened again. This is after completely reinstalling plex from scratch, deleting my entire Plex Media Server folder (caches, databases, and all) and starting from scratch. It worked for about 7 hours indexing all of the metadata and then crashed again and removed everything in my Preferences.xml… I’m at a wall now cause I have no idea what direction to go now.
New logs attached: logs.tar.gz (5.2 MB)
There’s an error in the running OS but I can’t see the actual error. Maybe you can look in the journal?
Specifically, it’s updating the cert and fails. It previously had the certificate fine. Is this your private certificate?
Jul 05, 2018 21:29:00.017 [0x7f0fe3b37840] DEBUG - Running migrations.
Jul 05, 2018 21:29:00.033 [0x7f0fe3b37840] ERROR - CERT: PKCS12_parse failed: error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure
Jul 05, 2018 21:29:00.033 [0x7f0fe3b37840] ERROR - CERT: Found a certificate, but couldn't install it.
Jul 05, 2018 21:29:00.034 [0x7f0fe3b37840] DEBUG - Relay: read 4 cached entries from hosts file
Jul 05, 2018 21:29:00.034 [0x7f0fe3b37840] DEBUG - CERT: Certificate or intermediate did not exist, fetching a new one.
Jul 05, 2018 21:29:00.034 [0x7f0fe3b37840] DEBUG - HTTP requesting POST https://plex.tv/devices/6e7ff0862db4262c5a34ab9220a335ac66c9c445/certificate?version=2&X-Plex-Token=
Just to ask the stupid stuff? Running out of /tmp space or other system resource?
Hmm. Now that I think back, the problem started after a kernel update I did last week. There was another issue unrelated that was happening to my nginx install and I just updated the kernel again and that issue disappeared. Maybe the same thing was causing problems with plex. I’ll get everything setup and running again to confirm.
The kernel I was on with (potential) issues was CentOS 7 3.10.0-693.11.1 and am now on 3.10.0-862.6.3
According to their documentation:
1463311 - CVE-2017-1000380 kernel: information leak due to a data race in ALSA timer
It shouldn’t be related but it is the kernel we’re talking about. PMS doesn’t go near the audio system. With this information, I’m starting to suspect interaction of PMS and all the kernel services it uses with other processes running.
All I can say to you at this point is to keep an eye on it. RHEL kernels are supposed to be stable .
Thanks. I’ll do an update in a bit if it works. I know… I don’t think I’ve ever run into a kernel issue that has really affected me. One of the best things about RHEL.
One concern with Centos, (just voicing a concern here and not raising an alarm or anything else), is that it is (to my knowledge) the only pre-4.0 kernel out there. I’m running Fedora which is at 4.17.2-200.fc28.x86_64. Ubuntu is equally well into the 4.x level of services. PMS is compiled and tested in that environment. There’s always the risk, regardless how small, of an incompatibility creeping in because of changes in glibc or other low level runtime. That’s just something everyone needs to keep an eye on.
@ChuckPa I am checking back in to report that everything is still running good. The last kernel update seems to keep it running and I even had a BIOS update that seems to have made my system a little more stable as well. Thanks for the help
Glad I could help. Thanks for checking back . It will help others who have the same issue in the future
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
