Colin Watson wrote: > I grabbed the kernel source in question from > https://wiki.openvz.org/Download/kernel/rhel6/042stab127.2 (there are a > few newer versions, but it's apparently fairly recent and none of the > newer ones mention anything about resource limits). I can't see > anything in the implementation of setrlimit that could plausibly make it > return EINVAL here, unless, I don't know, there's some silent type > mismatch or something. What architecture is the container?
x86_64 > Do you know of a good support/bug contact for OpenVZ? I'm not familiar > with it at all, and I think we need some idea of what the problem is > there before we even have a clue about what a reasonable workaround in > OpenSSH might be. (Disabling the sandbox doesn't count as reasonable > here, at least not long-term.) Have you asked the hosting provider if > they know what might be going on, or if they have an upstream they could > ask? Presumably somebody maintains this kernel. I don't get the impression the hosting provider is going to be of any help; they're of the bagain basement variety and are struggling with the concept that a newer kernel is also needed for eg, running systemd. Based on uname output of "2.6.32-openvz-042stab127.2-amd64 #1 SMP Thu Jan 4 16:43:57 MSK 2018" the kernel binary comes directly from openvz.org so you seem to have the matching source. Interestingly, running as root, strace bash -c 'ulimit -Sn 0 -Hn 0' results in: setrlimit(RLIMIT_NOFILE, {rlim_cur=0, rlim_max=0}) = 0 So that kernel doesn't generally fail when called with those parameters. It seems like something else that ssh does may be leading to the EINVAL? -- see shy jo
signature.asc
Description: PGP signature