On Wed, 2012-01-11 at 22:01 +0100, Lennart Poettering wrote:
> > Trying to chase down my sudden keyring / tmpfile socket death
> > syndrome ;-) I poked at the tmpfile cleanup code.
...
> This is interesting, it apparently boils down to the first column being
> 32bit for you and 64bit for me. I guess just skipping 53 chars is not OK
> after all..
Right, and hard-coding such a number seems just a tad lame (to the
un-initiated me) ;-)
> Is your machine 32bit?
Yes.
> Thanks for tracking this down!
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.
On Wed, 2012-01-11 at 22:12 +0100, Lennart Poettering wrote:
> Here's the fix:
You rob me of the joy of getting a patch into systemd ! ;-)
> What's interesting btw is though the first column of /proc/net/unix is
> 64bit on 64bit machines the header line didn't get fixed and the table
> is all skewed now on 64bit machines. I guess in a way that's a kernel
> bug...
I'm amazed (given the clear heuristic we have for sorting paths from
non-paths ;-) that we prefer this more complicated, slower, more fragile
code instead - but c'est la vie ;-)
What are we trying to protect against with that extra complexity ? the
kernel switching to dumping a space delimited base64 blob after column
<n> and before the path ? ;-)
But anyhow - working on the next patch ;-)
ATB,
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
