On Wed, Jul 10, 2019 at 10:44:14PM +0000, Zbigniew J??drzejewski-Szmek wrote: > That's ancient... 228 was released almost four years ago. That's the joy of using a commercial Linux distribution; they tend to be conservative about updates. SLES may very well have backported fixes to the packaged version they maintain. They may also have a newer version of a systemd RPM for us to take. I'm looking for an efficient way to repro the symptoms, as to confirm whether a newer RPM solves this for us. > > > > When we first spin up a new SLES12 host with our custom services, > > > > the number of connections to /run/systemd/private numbers in the > > > > mere hundreds. > > > > > That sounds wrong already. Please figure out what those connections > > > are. I'm afraid that you might have to do some debugging on your > > > own, since this issue doesn't seem easily reproducible. Above, I cite a desire for reproducing the symptoms. If you're confident that a newly-spun-up idle host should not hover at hundreds of connections, then hypothetically I could update the vendor-provided systemd RPM (if there is one), reboot, and see if the connection count is reduced. > strace -p1 -e recvmsg,close,accept4,getsockname,getsockopt,sendmsg -s999 > > yields the relevant info. In particular, the pid, uid, and guid of the > remote is shown. My approach would be to log this to some file, and > then see which fds remain, and then look up this fd in the log. > The recvmsg calls contain the serialized dbus calls, a bit messy but > understandable. E.g. 'systemctl show systemd-udevd' gives something > like this: Thanks for such succinct feedback; I'll see what I can get from this. In my prior email, I showed how some of the connections were hours/days old, even with no connecting peer. Does that sound like expected behavior? > HTH, > Zbyszek -- Brian Reichert <reichert@xxxxxxxxxxx> BSD admin/developer at large _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel