dhcpcd-discuss

On Fri, 30 Oct 2020 at 08:19, <shibe@xxxxxxx> wrote:

> Thank you for your consideration.
>
> > I would hope that system packagers would test dhcpcd before blindly
> comitting it for their downstreams to use.
>
> One problem is that it can break not just on dhcpcd update, but also on
> changes in libc and kernel. Libc may use different syscalls depending on
> kernel version. Kernel can be decoupled from Linux distribution in case of
> containers. Also, users may want to opt for newer kernel for hardware
> support. It's understandable that distribution maintainers don't test every
> update on every possible combination of relevant software that users may
> have. And usually they don't have to, because APIs are backwards
> compatible. In this case, it's just the syscall filter that breaks
> compatibility.
>
> Now when breakage does get discovered during testing, the options are:
> delay update (of dhcpcd, libraries or kernel) until it's investigated and
> fixed upstream,
> develop a downstream patch,
> disable syscall filters in the build.
> I believe, there should be another option. If syscall whitelist was
> modifiable at runtime and the program reported blocked syscalls, it would
> be easier to fix, and it would be fixable by end-users and administrators
> who have a combination of software that was not explicitly tested.
>
>
Note that you can use `strace` to figure out which syscall is failing. If
needed with -f or -ff to also trace forked children.

If you could report which syscall fails, which libc and kernel you're
using, that would be very useful. Then the problem could hopefully be fixed
:)

-- Maarten