glibc: provide fallback for kernels with missing prlimit64 #80961
Conversation
|
Hmm, I apparently missed this syscall between 2.25 and 2.26; perhaps I was confused by this line (HOWTO above the diff):
There might be more. It's well possible I've missed other missing syscalls/features, and I don't think anyone has checked for > 2.26 at all. |
|
A quick look into the log makes me doubtful whether it's worth for us trying to keep the RHEL 6 support. I fear we'll still be in a state that kind-of works but won't be really reliable, so I don't know who will find that valuable. This year RHEL 6 is transitioning to "Extended Life-cycle Support" for another four years, and there are RHEL 7 and even 8 for some time. |
|
I think I don't understand some of the context here when we talk about the maintenance of such support. To be specific, let's talk about the maintenance of the patch suggested in my PR. So what are the possible downsides that we anticipate in this case? The way I understand it, is that if there is some change that we need to add to glibc, say, it will be a bump to the shiny new 2.31, then the patch might break (which it didn't do in two years [1], but let's assume it will). And then do we imagine that the person in charge of the update will do the due diligence and spend their effort into updating this patch for the system they very likely don't use. I think what is likely to happen is they will, just like you, very rationally, realize that there is a possible solution of just nuking the patches. And if they would go that way, then, that would require very minimal effort for them and there isn't much burden involved after all. What am I missing here? Or, perhaps, I'm not considering some other situation? disclaimer: Please don't take it as if I'm building a straw man argument here. This is not my goal right now, I'm only seeking to improve my understanding of the issue. [1] the patch did not require updates since it was added https://git.savannah.gnu.org/cgit/guix.git/log/gnu/packages/patches/glibc-reinstate-prlimit64-fallback.patch |
I'm not sure that people will realize that. The presence of that patch would suggest (not unreasonably) that we're committed to supporting RHEL6. Having said that I don't think it's a big issue in this specific case. |
If that is a concern, I could add a comment saying "This patch is maintained by @veprbl. If it gives you trouble to fill free to ping me, I'd be happy to help." |
|
Sounds reasonable. I realize that I didn't explain my concern well enough (sorry for that!), but @edolstra summarized it pretty well: with those fixes people may expect maintenance for those platforms although we don't (and/or can't provide it properly). But I'm fine with adding a warning like you suggested 👍 |
The current version of glibc implements support for kernels down to
3.2.0 (and we make sure to enable such support with apporopriate
--enable-kernel setting). The current RHEL6 operating system is based on
a maintained kernel based on 2.6.32 with lots of backports. We provide
basic support for this specific kernel by patching glibc to provide an
exception for this specific version of kernel. This allows for nixpkgs
software distribution to work on RHEL6 and it does so quite well with
almost no problems. There are, however, a few syscalls that are missing
in the 2.6.32 kernel, one of which is prlimit64. This commit provides a
fallback that uses an older {get,set}rlimit syscalls in cases when
prlimit64 is not available. This should streamline the experience for
nixpkgs users wanting to run it on RHEL6, namely, this fixes one of the
tests in findutils.
See also discussion in guix:
https://lists.gnu.org/archive/html/guix-devel/2018-03/msg00356.html
veprbl
force-pushed
the
pr/glibc_prlimit64
branch
from
a425602
to
6740593
Compare
The current version of glibc implements support for kernels down to
3.2.0 (and we make sure to enable such support with apporopriate
--enable-kernel setting). The current RHEL6 operating system is based on
a maintained kernel based on 2.6.32 with lots of backports. We provide
basic support for this specific kernel by patching glibc to provide an
exception for this specific version of kernel. This allows for nixpkgs
software distribution to work on RHEL6 and it does so quite well with
almost no problems. There are, however, a few syscalls that are missing
in the 2.6.32 kernel, one of which is prlimit64. This commit provides a
fallback that uses an older {get,set}rlimit syscalls in cases when
prlimit64 is not available. This should streamline the experience for
nixpkgs users wanting to run it on RHEL6, namely, this fixes one of the
tests in findutils.
See also discussion in guix:
https://lists.gnu.org/archive/html/guix-devel/2018-03/msg00356.html
Motivation for this change
Closes: #80352
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)