Server Version#: 1.27.1.5916
Need more info.
Can’t diagnose this.
Do you have log files?
Distro? Version? Processor?
Are saying you got a kernel panic because of PMS?
Yes, kernel panic from plex scanner. I’ve enabled debuging, and restarted the service. I’m waiting on it to do it again. I’ll provide logs.
what’s the Processor you’re using, how much memory is installed, and what’s the distro and version as well as kernel version?
Dual AMD EPYC 7501’s
128G RAM
256G swap
Gentoo
gentoo-sources-5.18.6
Bad news:
We don’t support Gentoo.
From personal experience, you can configure it too many ways as you build it and get it totally screwed up.
I know you don’t support Gentoo, I actually have been maintaining the ebuild for it. It unpacks the .deb, installs it in the default locations even tho the whole /lib /lib64 shenanigans, uses the shipped openrc or systemd init scripts, or unit file. So it’s hammered into place, and usually works. I hit this today and wanted to bring it to plex’s attention.
Syslog mentions this currently"
kernel: traps: PMS LoudnessCmd[18880] general protection fault ip:7fac36f337a6 sp:7fac306db448 error:0 in ld-musl-x86_64.so.1[7fac36f23000+53000]
kernel: traps: PMS LoudnessCmd[18945] general protection fault ip:7f01fe4a0641 sp:7f01f7e802d0 error:0 in ld-musl-x86_64.so.1[7f01fe490000+53000]
kernel: traps: PMS LoudnessCmd[19011] general protection fault ip:7f4bab1b8641 sp:7f4ba50272d0 error:0 in ld-musl-x86_64.so.1[7f4bab1a8000+53000]
kernel: traps: PMS LoudnessCmd[19089] general protection fault ip:7fa0a29b864b sp:7fa09c7f22d0 error:0 in ld-musl-x86_64.so.1[7fa0a29a8000+53000]
Bottom line with ANY valid kernel build.
A running application cannot panic the kernel
The kernel will catch the page fault and terminate the process.
That said, your 5.18.6 kernel build, which includes the resident drivers, is highly suspect.
Looking back over this… there is an ambiguity which we need to resolve.
- You see “General Protection Fault” (SEGV)
- You asserted you get a Kernel panic
Are you confirming that when PMS faults then the kernel panic’s and the entire host comes to an immediate halt ?
Yes, the box reboots. I dont have reboot on oops or anything set in the kernel. When I went back to check the plex logs they were gone. as in missing. not much left in syslog.
The kernel is working for everything else this box runs. I’m still waiting for logs to show more information.
the system is using:
glibc-2.34-r13
binutils-2.38-r2
File system is on nvme using XFS
I know you have based plex on musl in the last while.
Thank you. This confirms your current kernel build is not handling the SEGV correctly.
As you know, normal behavior is to dump memory (a.out) if enabled and terminate the process.
At no point should the kernel MMU fault and take down the entire system.
Look at the snippet you provided.
Process address 0 – yes, that’ll cause an immediate SEGV.
That should never escape the memory map of the process space and cause kernel fault.
It’s using AMD secure memory encryption with KASLR enabled. I dont have access to grsec-sources, but some stuff was ported to mainline that I’ve enabled. It might need pax-marking on the musl libc, but the issue hasn’t been reproduced yet.
5.18.6 was released yesterday.
When you run the previous version of the kernel, does it panic.?
This was the first 5.18 series that actually booted on this box. I’ve been poking at it every few weeks. Previous kernel was very old and pulled from the tree. (5.17.2) I’m on the latest plex build and rebooted into this kernel this morning.
I dont recall which plex version I was running with the old kernel.
Also, it’s still not hung the box ‘yet’… I’m waiting for the audio scanner.
Do you realize most of us are using 5.13 → 5.15 kernels because of their stability?
Only Intel AlderLake CPUs need 5.18.0 for the kernel support of the different core types.
My server, which I built in November 2021 uses Ubuntu Server 20.04
[chuck@lizum ~.2002]$ gog uname -a
Linux glockner 5.4.0-117-generic #132-Ubuntu SMP Thu Jun 2 00:39:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
[chuck@lizum ~.2003]$
Bleeding edge is not safe in most cases — especially Plex.
I’m the cannon fodder on the latest. Thats why I thought I’d report issues I’ve had (sorry it’s lacking more info…).
I also noticed jenkins build paths in the logs.
WARN - Held transaction for too long (/data/jenkins/server/3533312223/Library/Episode.cpp:226)
I was pondering setting up KSP, but it’s incompatible with ZFS as they dont want you to load .ko’s to protect memory.
Holding transactions too long depends entirely on the DB and I/O.
Is this SSD based?
How many media items are indexed (total file count) ?
It’s 4x ssd in RAID0, eventually it will be 4x NVMe in RAID0
How many media items?
(or just a ls -la of the Databases directory will also suffice)
