On Thu, 12.01.12 11:07, Michael Meeks ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
