Bug 1653421 - "systemd-nspawn -b" with systemd-enabled OS tree won't work with dbus-broker at host
Summary: "systemd-nspawn -b" with systemd-enabled OS tree won't work with dbus-broker ...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: dbus-broker
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tom Gundersen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-26 19:48 UTC by Jan Pokorný [poki]
Modified: 2018-11-28 00:39 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-11-28 00:10:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jan Pokorný [poki] 2018-11-26 19:48:18 UTC
Initially discovered with "mock --rebuild" but observed also with plain
"systemd-nspawn -bD /var/lib/machines/MACHINE", where MACHINE is created,
e.g., per systemd-nspawn(1):

  # dnf -y --releasever=28 --installroot=/var/lib/machines/MACHINE \
      --disablerepo='*' --enablerepo=fedora --enablerepo=updates install
      systemd passwd dnf fedora-release vim-minimal

Respective systemd-nspawn will then exit with status of 1 and emitting:

> Failed to register machine: Connection timed out
> Parent died too early

Only defining SYSTEMD_LOG_LEVEL=debug will provide some more insights.

Looks like either dbus-broker is not a 100% replacement or there are
some gaps with systemd integration (which doesn't preclude the former).

I don't think that broken "mock" functionality (or more specifically,
inability to run container workloads at least with OSes utilizing
native dbus daemon and perhaps communicating up to host over DBus?)
is a negligible issue for Fedora Rawhide (eventually F30) users.

Comment 1 Tom Gundersen 2018-11-26 20:53:57 UTC
What version of dbus-broker are you running, and does journalctl give any relevant information.

Comment 2 Jan Pokorný [poki] 2018-11-26 22:56:46 UTC
This was with
> dbus-broker-16-7.fc30.x86_64
> systemd-239-9.git9f3aed1.fc30.x86_64
on the host.

As mentioned, there was no good diagnostics beside some DBus related
clues (IIRC, not noted verbatim) with debug verbosity.

Comment 3 Tom Gundersen 2018-11-27 12:16:56 UTC
Are you using SELinux? Is the bug reproducible in permissive mode?

Comment 4 Jan Pokorný [poki] 2018-11-27 14:13:27 UTC
Yes, naturally.  Tried disabling DONTAUDIT but observed nothing
suspicious.  Am I alone with this observation?

Comment 5 Jan Pokorný [poki] 2018-11-27 18:51:23 UTC
Strange, a minimal Rawhide VM works well also in that context.
Will give it more troubleshooting.

Comment 6 Jan Pokorný [poki] 2018-11-28 00:09:56 UTC
Sorry, this must have been something intermittent, perhaps related to
the infamous hiccup with -6 and unreliably enablement and in turn
something I inflicted on my when trying to solve that (perhaps
mangling with nsswitch.conf might have caused that?).

But would be really strange if everything but "systemd-nspawn"
worked.  Especially when there's not exactly a good visilibity
into the cuncurrently running buses etc. or I just don't know
where to look.

That being said, now everything works so closing this bug,
will reopen should this ever recidivate.

Comment 7 Tom Gundersen 2018-11-28 00:39:06 UTC
Ok, that's good to hear. Thanks for testing and reporting regardless, really much appreciated!


Note You need to log in before you can comment on or make changes to this bug.