[systemd-devel] PATCH: tmpfiles cleanup

[Lennart Poettering]

On Thu, 12.01.12 11:07, Michael Meeks (michael.meeks at suse.com) wrote:

heya,

Sorry for the long delay in responding!

> On Thu, 2012-01-12 at 10:10 +0000, Michael Meeks wrote:
> > 	No problem; it is only the belt - not the braces; I'll knock up
> > something more robust re-using the linc-cleanup-sockets goodness, that
> > should also avoid the unpleasant race-condition in there whereby a
> > socket is created between parsing /proc/net/unix and the deletion phase.
> 
> 	Hah - my 'race' is more imaginary than real because of the atime,
> mtime, ctime checks (we are actually using atime!?).

Actually, the timestamps of AF_UNIX sockets nodes are not updated when
one connects to them. :-(

> 	Nevertheless, if we want to be truly clean socket-wise we could use
> something like the attached ? this is also pretty quick to execute - so
> unless there is some serious performance reason, we might consider
> dropping the /proc/net/unix parsing altogether ? [ though of course my
> understanding may be broken here, perhaps there are odd unix socket
> types, and races, and so on that it will not handle ;-) ]

Hmm, so, I see a two problems with this. Firstly your patch currently
doesn't cover SOCK_DGRAM nor SOCK_SEQPACKET AF_UNIX sockets, only
SOCK_STREAM AF_UNIX sockets. This could certainly be fixed, but for
SEQPACKET and STREAM doing a test connect is not passive, but actually
causes the process behing the socket to wake up (it will see an incoming
connection that is immediately terminated). The wake up is probably not
much of a problem in most cases, but in some cases it might: proceses
that terminate when they are idle -- they'll be kept alive through our
repeated checks, even though they should long have died. (and processes
like that are not that uncommon, for example in systemd we ship a couple
of services like that.)

So, I really see the usefulness of your work, and I'd actually prefer
to implement things without parsing /proc/net/unix, but I fear that the
same amount of bugs and problems would be created through those spurious
wakeups of those processes as it fixed by these checks.

(The SOCK_DGRAM part we could actually get working without a wake-up
since connect() on a SOCK_DGRAM socket will not cause the remote side to
wake up, but SOCK_DGRAM is just one kind, and SOCK_STREAM is probably
far more relevant than SOCK_DRGAM and connect() on it does trigger the
wake-up...)

Parsing /proc/net/unix sucks quite a bit I must admit. There's one
improvement that I think we could do here, which is making use of the
more recent netlink based API for detecting local sockets, which the
"ss" tool is now using.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.