I updated to the latest version this morning and now i cannot access Plex. I am also unable to change the Plex deamon user even though it has been change in the /etc/default/plexmediaserver file
**export PLEX_MEDIA_SERVER_USER=Plexuser
**
Services continue to startup as user plex
kodi@MediaOne:/$ ps aux | grep plex
plex 2230 0.0 0.0 4628 824 ? Ss 13:35 0:00 /bin/sh -c LD_LIBRARY_PATH=/usr/lib/plexmediaserver “/usr/lib/plexmediaserver/Plex Media Server”
plex 2232 0.0 0.4 251912 34180 ? Sl 13:35 0:00 /usr/lib/plexmediaserver/Plex Media Server
kodi 2356 0.0 0.0 14428 1036 pts/0 S+ 14:55 0:00 grep --color=auto plex
For what it’s worth, my CentOS 7 had a similar issue. After upgrade, the server acted like it was down, rebooted, still not coming up. I had to roll it back really quick as I had no time to troubleshoot.
I can get any info if needed to assist with this as well.
Can you reinstall (temporarily) and manually grab the log files from the Logs directory (ar cfz <filename.tar.gz> ./Logs style) and attach them?
Also, are you running a customized configuration (/etc/systemd?)
You had a lot of sync’d items making a mess (which needs cleaning up manually by going in and deleting them from your Sync list)
When it did the update, because of those sync’d items, the database couldn’t migrate (minor) to the schema and PMS hard crashed
Back down to 1.13.0 (where you were)
Clean up all those old / unneeded lists. you have MANY listed. It might be better to start over with them because the media files (sync output) files are long gone
Then, with PMS working normally perform the upgrade
You don’t change the master service definition file. I overwrite that with each release.
If you want enduring changes, make them in the systemd standard override file
There are many mixed results with 18.04 . I have not yet quantified what is causing some users to have a flawless experience while others are forced to roll back to 16.04 to regain their flawless experience. For those who do fall back, upon rolling back to 16.04, it is immediate. The existing PMS library immediately springs right back to life as if never interruptied
Your sync temp directories are under the transcode temp directory
yes. I could show you all the LPE (Local Path Evaluator) errors in your logs where PMS is expecting the media but it’s long since gone. From what I see here, after many lines referring to damaged lists of sync items, did contribute to the update failure. I’m trying to avoid telling you to ‘start over’ at ALL cost.
That’s not good. This is a ‘Go out for dinner and leave you with the check’ scenario.
I will see if they can manually be removed from the database but if not, it’s not going to be pretty. You’ll be out back “washing dishes” to get this one done