[PATCH] Move machine-id to /var

Robert McQueen robert.mcqueen at collabora.co.uk
Tue Oct 24 10:52:22 PDT 2006

Havoc Pennington wrote:
> Robert McQueen wrote:
>> Unless we have a use case for reboot-persisting UUIDs, it would be
>> easier for users (live CDs, package maintainers, thin clients, embedded
>> systems, etc) if it was kept in /var/run which is more likely to be
>> writable on such unusual systems.
> Why do you say this? The FHS clearly says that /var/lib has to be
> writable ... if someone is making it not writable they are just on crack.

Not just whether it's writable or not, but whether it's shared between
systems. There's a big difference for something in /var/run is expected
to exist only for the lifetime of that boot, and something in /var/lib
should be made at install-time and persist indefinitely. If the latter,
and it's supposed to be machine-unique, it makes it harder to roll
out/clone in large deployments because you need to go back and
change/remove something in /var/lib.

>> Persisting it across reboots seems as
>> useless to me as persisting the name of the session bus socket, which we
>> obviously don't try and do either.
> The usefulness would be if we document the machine id as "best-effort
> persistent across reboots" - we'd say it ideally is and while on some
> deployment models it may not be, apps can still consider it worthwhile
> to e.g. attach a a cache to the machine id and try to keep that cache
> around across a reboot.

I wasn't aware this was part of the purpose of the ID, just that it was
for clients (and particularly autostarting) to know whether they were
connected to the same systems' bus. If it's only *necessary* for the
autostarting stuff, we should only provide the semantics that are
required for that to work.

>> Is it too late to change this?
> A day after the patch is posted, no ;-)

It's not of huge importance, but I still think it's worth changing,
because the inconvenience to giving people an additional
post-image-creation step before cloning or burning systems (or risk
confusing the applications who have decided to use the ID...), etc, is
something they won't thank us for.

> Havoc


More information about the dbus mailing list