On Wed, 14 Aug 2019, Michael Chapman wrote: > On Wed, 14 Aug 2019, Brian Reichert wrote: > > On Thu, Aug 01, 2019 at 07:18:20PM +0000, Zbigniew J??drzejewski-Szmek > > wrote: > > > Yes. (With the caveat that there *are* legitimate reasons to have new > > > long-lived fds created, so not every long-lived fd is "wrong".) > > > > I finally was able to track down what's happening on my system. > > > > This is sufficient to reproduce the effect of increasing the number > > of file descriptors open to /run/systemd/private; at least, on my > > box, in it's current state: > > > > sh -c 'exec 1>&-; /usr/bin/systemctl status ntpd.service' > > I can reproduce this on CentOS 7's systemd 219, but not on Fedora 29's > systemd 239.
Looking in to this further, my guess is that this is fixed in: commit 7fe2903c2315db9d9f501ae255a6b6e4f01ba46c Author: Lennart Poettering <lenn...@poettering.net> Date: Fri Feb 9 17:53:28 2018 +0100 fd-util: move certain fds above fd #2 (#8129) which was introduced in systemd 238. What's happening is that systemctl is getting fd 1 for the socket to /run/systemd/private, as it's the lowest unused fd, but fd 1 (aka stdout) is also where it sends its regular human-readable output. This commit ensures that the socket is moved to a file descriptor that can't be mistaken for a standard stream. I'm not sure if systemd >= 238 itself still suffers from the problem where any "extra" data on that connection causes it to leak its file descriptor. That may still be a problem, or it may have been fixed by a different commit. _______________________________________________ systemd-devel mailing list firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel