Re: systemd failing to close unwanted file descriptors & FDS spawning and crashing

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 04.03.22 09:26, Christopher Obbard (chris.obbard@xxxxxxxxxxxxx) wrote:

> Right, so it looks like the call to close_range fails. This is a 5.4 kernel
> which doesn;t have close_range - so this is understandable.
>
> For a quick fix, I set have_close_range to false - see the patch attached.
> It seemed to work well.
>
> Since my 5.4 kernel is a heavily modified downstream one - next I will check
> if that syscall was implemented by someone else, and also I will check if
> vanilla systemd works on vanilla 5.4 (there is no reason why it shouldn't,
> right?).

Hmm, this is strange. Our code already has fallback paths in place to
handle cases where the syscall is not implemented, i.e. where we see
ENOSYS when we call it. Our code should handle this perfectly already.

Is it possible that your patched kernel added non-standard syscalls
under the syscall numbers the official kernel later assigned to
close_range()? If so, this would explain that we see EINVAL, as of
course we call the syscall assuming it was close_range(), but if it is
actually something else mit very likely might not be able to make
sense of our parameters and thus return EINVAL.

In this case I am not very sympathetic to your case: squatting syscall
numbers is just a terrible idea...

Lennart

--
Lennart Poettering, Berlin