I've tried to debug this a bit more tonight, and after a good 4
hours there are two things I can report:
1. with the default ruleset, udev leaks an ethtool socket to
net.agent (and by extension to ifup, dhclient, ...)
Details: 80-net-setup-link.rules loads the udev builtin
"net_setup_link", which in turn creates a static object of type
link_config_ctx, and then goes on to call link_config_apply,
which calls link_config_ctx_connect. This function opens both an
ethtool and a netlink socket. The netlink socket is correctly marked
as CLOEXEC, but the ethtool socket is not marked this way.
With net_setup_link loaded, the Debian-specific net rules run, and
call into the /lib/udev/net.agent shell script.
The end result is that dhclient (and many other programs!) inherit an
ethtool socket opened by udev.
2. Replacing #!/bin/sh with #!/bin/bash magically makes the problem
go away in my VM. I believe this is because bash closes all sorts of
things on startup, while dash doesn't do that.
Unfortunately, fixing the fdleak from #1 above doesn't fix the
overall problem -- likely there's another fdleak somewhere that I
didn't find.
A patch for #1 that totally ignores error branches, but could serve
as a starting point for somebody else:
--- systemd-215/src/udev/net/link-config.c 2014-11-01 04:40:50.000000000
+0100
+++ systemd-215.ch/src/udev/net/link-config.c 2014-11-01 04:41:50.603183984
+0100
@@ -130,6 +130,16 @@
}
}
+void link_config_ctx_disconnect(link_config_ctx *ctx) {
+ if (!ctx)
+ return;
+
+ safe_close(ctx->ethtool_fd);
+ ctx->ethtool_fd = -1;
+ sd_rtnl_unref(ctx->rtnl);
+ ctx->rtnl = NULL;
+}
+
void link_config_ctx_free(link_config_ctx *ctx) {
if (!ctx)
return;
@@ -410,6 +420,7 @@
return r;
}
+ link_config_ctx_disconnect(ctx);
return 0;
}
@@ -430,6 +441,7 @@
if (r < 0)
return r;
+ link_config_ctx_disconnect(ctx);
*ret = driver;
return 0;
}
--
,''`. Christian Hofstaedtler <z...@debian.org>
: :' : Debian Developer
`. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03
`-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
