Bug 228001 - devel/dbus: Applications segfault due to missing machine-id after package install
Summary: devel/dbus: Applications segfault due to missing machine-id after package ins...
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Mateusz Piotrowski
URL: https://reviews.freebsd.org/D15324
Keywords: feature
Depends on:
Blocks:
 
Reported: 2018-05-05 20:19 UTC by Wojciech A. Koszek
Modified: 2023-04-02 17:50 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wojciech A. Koszek freebsd_committer freebsd_triage 2018-05-05 20:19:46 UTC
I installed FreeBSD 11.1 + xorg-server + xorg-apps + firefox and several other packages. Everything via 'pkg'. List of packages:

https://pastebin.com/NJ8aQ5a2

I run dwm + sterm. From it, I start Firefox. Below is what I get. Note: when I did pretty much same steps in OpenBSD, it all just worked without any seg-faults.


process 1331: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not built with -rdynamic so unable to print a backtrace
Redirecting call to abort() to mozalloc_abort
 
Segmentation fault (core dumped)
Comment 1 Tobias Kortkamp freebsd_committer freebsd_triage 2018-05-06 01:05:34 UTC
Over to devel/dbus maintainers.  This is a problem with how D-Bus is
packaged on FreeBSD and not a Firefox specific problem.  On OpenBSD the
dbus package will run `dbus-uuidgen --ensure` to generate the machine-id
file when it's installed so that D-Bus can work correctly out of the
box.  On FreeBSD the rc script takes care of it and you're expected to put
dbus_enable=YES into /etc/rc.conf and start D-Bus once to generate the
machine-id.

This is a common support problem (nightmare?) on the FreeBSD forums too [1].
Often seen when users try to install and run Xfce without having
`dbus_enable=YES` in `/etc/rc.conf`.

There would be IMHO no real downsides in putting

@postexec %%PREFIX%%/bin/dbus-uuidgen --ensure

into devel/dbus' pkg-plist on FreeBSD like on OpenBSD.

[1] https://www.google.com/search?q=site%3Aforums.freebsd.org+dbus-uuidgen
Comment 2 Tijl Coosemans freebsd_committer freebsd_triage 2018-05-06 09:15:56 UTC
(In reply to Tobias Kortkamp from comment #1)
The reason that hasn't happened is because you cannot delete that file on uninstall and if you don't delete it the package builders report it as a leftover.
Comment 3 Tobias Kortkamp freebsd_committer freebsd_triage 2018-05-06 11:10:11 UTC
(In reply to Tijl Coosemans from comment #2)
> The reason that hasn't happened is because you cannot delete that file
> on uninstall and if you don't delete it the package builders report it
> as a leftover.

But packages are not being built with the leftovers check on. It's just
a warning that could be ignored if there's a will and a reason to do so.
Comment 4 Tijl Coosemans freebsd_committer freebsd_triage 2018-05-06 12:37:38 UTC
The command was removed from pkg-install in ports r347320.

A possible solution would be to create a "pkg purge" command that completely deletes a package, and allow "pkg delete" to leave files like this (and configuration files) behind.  The current solution in dbus doesn't trigger the leftover checks but technically the file is still a leftover.
Comment 5 Tobias Kortkamp freebsd_committer freebsd_triage 2018-05-06 13:12:57 UTC
> The command was removed from pkg-install in ports r347320.
> A possible solution would be to create a "pkg purge" command that
> completely deletes a package, and allow "pkg delete" to leave files like
> this (and configuration files) behind. The current solution in dbus
> doesn't trigger the leftover checks but technically the file is still a
> leftover.

Every port that has an @sample annotation in their plist leaves files
behind. Poudriere doesn't care about those and pkg will print a message
on package deinstall for them.

    You may need to manually remove ${target_file} if it is no longer
    needed.

devel/dbus could also give the same suggestion for /var/lib/dbus/machine-id.

Furthermore Mk/Scripts/check_leftovers.sh could be amended to ignore it
too. It already ignores files from fontconfig, gconf, glib, ghc, etc. so
there are precedents for this already.
Comment 6 Tijl Coosemans freebsd_committer freebsd_triage 2018-05-06 13:23:24 UTC
@sample still deletes the files if they are unmodified, so it doesn't trigger poudriere checks.

If you want to pursue this further you'll have to talk to portmgr I think.
Comment 7 Tobias Kortkamp freebsd_committer freebsd_triage 2018-05-06 13:56:48 UTC
(In reply to Tijl Coosemans from comment #6)
Here is a review for this.  Could use approval from someone from GNOME too.
Comment 8 Wojciech A. Koszek freebsd_committer freebsd_triage 2018-05-06 17:50:46 UTC
Is /var/lib where it's supposed to be? I put my file into /etc/machine-id to make it work. Isn't this file something that would not change ever on the machine?

Shouldn't this just be created at OS installation time in /etc/machine-id? That, IMO, would be the correct fix that could solve your pkg install/uninstall problem.

It appears like dbus is a hard requirement for X11 nowadays. I think during xorg-server installation, the dbus_enable="YES" should be placed in /etc/rc.conf or there should be some other forceable mechanism where user MUST enable it to get xorg-server installed. Otherwise it looks very broken.
Comment 9 Tijl Coosemans freebsd_committer freebsd_triage 2018-05-06 18:56:35 UTC
(In reply to Wojciech A. Koszek from comment #8)
/var/lib/dbus is the default location for dbus and it works with devel/linux-c6-dbus-libs.  I believe the /etc location was introduced by systemd and support for it was added in later versions of dbus.  Another problem with /etc is that it may be read-only and the rc.d script needs a writable directory to put the file in.
Comment 10 Koop Mast freebsd_committer freebsd_triage 2018-05-22 15:18:55 UTC
With the maintainer hat on, the comment of tijl@ in comment #2 is correct.
If portmgr@ approves the ignoring of the dbus machine-id file, then I have no problem with the proposed fix for dbus as in the review linked in comment #7.
Comment 11 Tobias Kortkamp freebsd_committer freebsd_triage 2018-10-20 17:06:52 UTC
I've abandoned the review for being open for too long with no response.
If someone else still cares please take it over.
Comment 12 Mateusz Piotrowski freebsd_committer freebsd_triage 2020-11-09 15:12:10 UTC
Return the PR back to the pool.

I am not sure how this should be solved properly.

It feels like the most elegant way would be to remind users to start dbus before starting firefox in pkg-message. Otherwise, if we decide to create the machine-id file during installation, we end up in a situation where, e.g., a VM image with preinstalled packages would have a hardcoded machine-id. Which in turn creates even more edge cases.
Comment 13 Mateusz Piotrowski freebsd_committer freebsd_triage 2020-11-10 08:25:17 UTC
I've spoken to bapt and I think that we are almost ready to commit the patch from Phabricator. See Phabricator for details.