[Pkg-systemd-maintainers] Bug#619244: Bug#619244: Bug#619244: systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id

[Tobias Frost]

Hallo Simon

Am Dienstag, den 15.04.2014, 13:25 +0100 schrieb Simon McVittie:
> On 15/04/14 13:10, Tobias Frost wrote:
> > Maybe it is sufficient to agree on a load order, like switch the order dbus
> > tries to read the uuid?
> 
> If there is a conflict, I consider consistency with dbus-from-the-past
> to be a higher priority than with systemd. Of course, if all goes well,
> there shouldn't be a conflict - if both files exist then they should
> have the same contents.
> 
> The failure mode, if different components see different machine IDs, is
> that a component might think another component is running remotely.
> That's not *so* bad.
> 
> > But as systemd is supposed to start earlier, I guess, it is
> > probably better to have dbus read it first to avoid races)
> 
> What matters is the order in which their postinsts created the machine
> IDs. I believe d-i still installs sysvinit as pid 1, and wheezy d-i
> certainly does, so it seems reasonably likely that the sort of systems
> where this question is relevant will install dbus (as a dependency for
> task-desktop, for instance) before systemd. In that case, everything is
> fine, because systemd copies dbus' idea of the machine ID.

> The failing case is when dbus is installed second, and generates an
> entirely new machine ID instead of copying systemd's. As I said, I'd be
> happy to review a patch.

I hacked something together for discussion: 
In postinst, lets check for /etc/machine-id validity, and if it is valid
copy it to /var/lib/dbus/machine-id. (I prefered cp instead over links
to avoid dangling links if e.g systemd is purged; Just deleting won't
work either as there are some programs with hard-coded paths to dbus' id
without fallback to systemd's)  

However, I'm unsure if this needs to be handled: If dbus is updated and
the both machine-ids are different, dbus's machine-id-file will change
at runtime, which could cause problems according dbus-uuidgen(1). 
Is this really a problem, as the user will be prompted for a reboot
anyway? 
In this case the only option would be to fix this when dbus starts or
live with the different ids until the admin fixed it manually.

-- 
Tobi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbus.postinst.patch
Type: text/x-patch
Size: 789 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140416/76a5931a/attachment-0002.bin>