axosyslog:4.7.1 on CentOS 7: iv_fd_epoll_timerfd_poll: got error 1[Operation not permitted] #85
Comments
|
After talk with Balazs understood that setting In general we tested on typical AWS EC2 instances under CentOS 7 (7.9.2009, kernel 3.10.0) P.S. Very strange but syslog-ng 4.6 working okay under same OS |
|
Hmm.. there was an update to ivykis 0.43 which contains this patch: This should transparently fall back to using the older syscall as long as it returns ENOSYS (no such system call). But maybe this is not the case? Can you check with strace that it indeed invokes epoll_pwait2() and that it is returning EPERM instead of ENOSYS? Quoting the manpage: |
|
just confirmed that if running under a non-privileged container under centos7, we get EPERM instead of ENOSYS that's why the autodetection for epoll_pwait2() does not work. |
|
Thanks @bazsi for checking this, looks like we have a workaround then. |
Commit 491daf4 ("iv_fd_epoll: Add support for epoll_pwait2().") added support for epoll_pwait2(), with a fallback to epoll_wait() in case epoll_pwait2() is not supported by the kernel we are running on, which would be indicated by epoll_pwait2() returning -ENOSYS. Some reports (e.g. axoflow/axosyslog#85 , #33 (comment) ) suggest that some container technologies can cause -EPERM to be returned for epoll_pwait2(), independently of whether or not epoll_pwait2() is actually supported by the kernel we are running on, and this trips us up because we don't currently handle -EPERM gracefully, as we did not expect that we would have to do so. Making system calls return -EPERM to indicate that they were filtered out by a security policy framework seems somewhat dubious, especially when considering the amount of application and user confusion generated by system calls that are not documented as being able to fail with -EPERM now suddenly being able to fail with -EPERM, but there is not much we can do about this. I would be against adding EPERM-as-ENOSYS fallbacks for every current or future case where we handle ENOSYS, but: 1. it seems that this is the only case where this triggers; 2. upstream seems to agree that this EPERM behavior is a bug (see e.g. these links dug up by László Várady: containers/common#573 , containers/podman#10337 , opencontainers/runtime-spec#1087 ), so there will hopefully be no new cases of this in the future; 3. there's at least one container technology release (podman on CentOS 7) where this bug triggers and where the platform is sufficiently old to no longer be receiving updates, as pointed out by Balazs Scheidler, so this issue can't be fixed by users updating their container software. Under these circumstances, adding a workaround on our end seems reasonable, and this commit does so. This issue was originally reported by @mstopa-splunk on GitHub. Workaround originally by Balazs Scheidler. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Hi team, do you support axosyslog:4.7.1 on CentOS 7?
We have the following error on start after upgrading:
The text was updated successfully, but these errors were encountered: