(In reply to Michael Vogt from comment #0)
> This is useful e.g. for systems with a empty /var

That makes sense.

> and also avoid the need to geneate the dbus-uuid in the package postinst

No, the postinst should still run it. A session bus should be usable and correctly set up (e.g. UUID created) after installing dbus_*.deb or the non-Debian equivalent, without needing to reboot or start the system bus.

> ExecStartPre=@EXPAND_BINDIR@/dbus-uuidgen --ensure

Did you test this patch? I'm pretty sure the correct Automake substitution is @EXPANDED_BINDIR@ like on the other lines, and this one will just produce an error.

(In reply to Michael Vogt from comment #0)
> e.g. for systems with a empty /var

In at least Debian, the expectation is that [/var]/run is transient, but /var/lib is persistent, so a machine ID generated by dbus.postinst will persist. Packages are not required or guaranteed to work correctly if files are indiscriminately deleted from /var/lib (e.g. dpkg will lose track of the set of installed packages). I believe this is the same for most distributions, including RPM-based systems.

Also, the systemd unit (dbus.service) is only used if pid 1 is systemd, which requires /etc/machine-id and will generate it if necessary, or fail to boot if that is impossible. libdbus (and its reimplementations like GDBus and sd-bus) will happily read a machine ID from either of those files. So I'm not convinced that this is even necessary...

Those two files are meant to contain the same string, except in pathological cases. systemd has always tried to copy an existing /var/lib/dbus/machine-id to /etc/machine-id rather than inventing its own, if dbus was installed first. Since D-Bus 1.8.2, dbus-uuidgen has done the converse if systemd was installed first.

Please describe the OS/environment in which you found this to be necessary? Why don't you have /var/lib/dbus/machine-id? Why don't you have /etc/machine-id?

> Did you test this patch? I'm pretty sure the correct Automake substitution is
> @EXPANDED_BINDIR@ like on the other lines, and this one will just produce an
> error.

I'm very sorry, I tested the ExecStartPre line in /etc manually but
did not rebuild the package. Sorry again.

> (In reply to Michael Vogt from comment #0)
> > e.g. for systems with a empty /var
>
> In at least Debian, the expectation is that [/var]/run is transient, but
> /var/lib is persistent, so a machine ID generated by dbus.postinst will
> persist. Packages are not required or guaranteed to work correctly if files
+are
> indiscriminately deleted from /var/lib (e.g. dpkg will lose track of the set
+of
> installed packages). I believe this is the same for most distributions,
> including RPM-based systems.

The use-case is a cloud base image where we do want to have a unique
machine-id geneated at boot time for each instance. It seems like
creating a image without a /var/lib/dbus/machine-id and generate it on
boot is a reasonable approach here.

> Also, the systemd unit (dbus.service) is only used if pid 1 is systemd, which
> requires /etc/machine-id and will generate it if necessary, or fail to boot if
> that is impossible. libdbus (and its reimplementations like GDBus and sd-bus)
> will happily read a machine ID from either of those files. So I'm not
+convinced
> that this is even necessary...

If that is not necessary thats great! I ran into a crash of a
application that tried reading /var/lib/dbus/machine-id and did not
fallback to /etc/machine-id. If this app is buggy I'm happy to fix it
and you can ignore the patch.
> Those two files are meant to contain the same string, except in pathological
> cases. systemd has always tried to copy an existing /var/lib/dbus/machine-id
+to
> /etc/machine-id rather than inventing its own, if dbus was installed first.
> Since D-Bus 1.8.2, dbus-uuidgen has done the converse if systemd was installed
> first.
>
> Please describe the OS/environment in which you found this to be necessary?
+Why
> don't you have /var/lib/dbus/machine-id? Why don't you have /etc/machine-id?

Yeah, when I call dbus-uuidgen --ensure then I end up with identical
files. The /etc/machine-id file is auto-generated from systemd and
dbus-uuidgen --ensure will copy it which is exactly what I want.

So to summarize. Please ignore the patch and close this bugreport if
its a bug that third party apps rely on /var/lib/dbus/machine-id. I'm
happy to fix the apps instead. Otherwise, please let me know and I
will fix the patch so that it does not contain the silly typo of the
original version.

Thanks,
 Michael

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/118.