Re: systemd's connections to /run/systemd/private ?

[Michael Chapman <mike@xxxxxxxxxxxxxxxxx>]

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 <lennart@xxxxxxxxxxxxxx>
  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
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel