[systemd-devel] PATCH: tmpfiles cleanup

Michael Meeks michael.meeks at suse.com
Thu Jan 12 02:10:31 PST 2012


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.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot



More information about the systemd-devel mailing list