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
Attachment:
signature.asc
Description: PGP signature