Learn more about these different git repos.
Other Git URLs
I think https://gitlab.com/openconnect/ocserv/-/issues/296 might be a COPR issue. My epel-7-aarch64 builds are failing because the getrlimit system call is not permitted: https://download.copr.fedorainfracloud.org/results/dwmw2/openconnect/epel-7-aarch64/01361813-openconnect/build.log.gz
getrlimit
Normally, we'd expect glibc's getrlimit() function actually to use the prlimit system call which replaces both getrlimit and setrlimit system calls. But the aarch64 glibc doesn't use prlimit; it still uses the old separate system calls. Do those need adding to a filter of permitted system calls? Or is it not the COPR environment which is preventing this?
getrlimit()
prlimit
setrlimit
Hello @dwmw2, thank you for the report.
We already have an existing issue in bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1813089
And it seems to be a kernel issue. I will try to pass it to the kernel guys and we will have to wait.
Metadata Update from @praiskup: - Issue tagged with: blocked, bug
I would be surprised is this is truly a kernel issue. Even if the kernel didn't support the old getrlimit syscall it would get -ENOSYS not -EPERM. This really looks like something (copr, mock, etc.) has filtered the system calls which are permitted in the container and has neglected to permit getrlimit(), which doesn't matter on other architectures (or indeed newer arm64) where glibc uses the prlimit syscall for that purpose.
It seems this is finally fixed on Fedora 33: $ rpm -q systemd kernel mock systemd-246.6-3.fc33.aarch64 package kernel is not installed mock-2.6-1.fc33.noarch
Thanks for reporting this!
Metadata Update from @praiskup: - Issue close_status updated to: External - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.