There's some mismatch between Linux kernel 3.10 and #KDE that wants to use clone3 to create a process thread.
There's some mismatch between Linux kernel 3.10 and #KDE that wants to use clone3 to create a process thread.
There's some mismatch between Linux kernel 3.10 and #KDE that wants to use clone3 to create a process thread.
Do I know anyone from @kde@lemmy.kde.social @kde@floss.social who is able to assist with debugging it further?
The system call clone3 has been added to linux 5.3 but it seems that KDE does not do any fallback in case the system call is rejected with EPERM.
@zygoon @kde@lemmy.kde.social @kde kernel 3.10 was released more than 10 years ago and received a last update in 2017. Is that really a kernel still used in the wild?
Looking at https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=sched.h, KDE does not do a clone3 directly. It's likely done by a dependency of Plasma :( But I might be wrong as I'm definitively not an expert in syscall
2@carlschwan @kde@lemmy.kde.social @kde@floss.social
Yeah, RHEL 7 uses it out of the box and is still supported, at least until June 2024: https://www.redhat.com/en/blog/end-maintenance-red-hat-enterprise-linux-7-almost-here
0@zygoon @carlschwan @kde@lemmy.kde.social @kde@floss.social It's likely coming from some usage of libseccomp somewhere. This also afflicts the container stack and such, which is why RHEL 9 containers on RHEL 7 are not supported.
Container/sandbox runtimes using libseccomp need to explicitly always allow clone3() through, or otherwise it will not fail correctly on RHEL 7.
2
@zygoon @kde@lemmy.kde.social @kde@floss.social because any reasonable implementation will treat EPERM from a process creation system call as a fatal error. If this is e.g., blocked through seccomp. ENOSYS is the correct error to return. It's just naive seccomp sandboxes that started this EPERM nonsense. So I'd rule that out first. Unless you're using something that requires specific capabilities such as creating a process with a specific PID. That can legitimately return EPERM.
1@brauner @kde@lemmy.kde.social @kde@floss.social
Thanks for the insight. I was surprised by EPERM, would have expected ENOSYS as well.
Looks like EPERM is most likely coming out of unknow system call name being filtered-out by snap-seccomp compiler. I'll update snapd to 2.61.1 to avoid chasing fixed bugs and then see if there's something to improve in the compiler.
1