Discussion:
no user dbus session in container
(too old to reply)
arnaud gaboury
2017-07-14 12:36:12 UTC
Permalink
Raw Message
% systemctl --version
systemd 233
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN
default-hierarchy=hybrid

% machinectl list
MACHINE CLASS SERVICE OS VERSION ADDRESSES
poppy container systemd-nspawn fedora 26 192.168.1.94...

% machinectl show poppy
Name=poppy
Id=59b720b533834a4eafe07a62c2482266
Timestamp=Wed 2017-07-12 22:07:15 CEST
TimestampMonotonic=6928076
Service=systemd-nspawn
Unit=systemd-***@poppy.service
Leader=648
Class=container
RootDirectory=/var/lib/machines/poppy
State=running

After upgrade from Fedora 25 to 26, there is no more user dbus session for
user in container.

On container:
$ ps -ef | grep dbus
5:dbus 35 1 0 Jul13 ? 00:00:00 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
--syslog-only
65:root 1195 1163 0 14:18 pts/0 00:00:00 grep -nI --color dbus

On host:
$ ps -ef | grep dbus
195:dbus 582 1 1 Jul12 ? 00:21:57 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
204:gabx 614 602 0 Jul12 ? 00:00:00 /usr/bin/dbus-daemon
--session --address=systemd: --nofork --nopidfile --systemd-activation
251:gabx 1593 1588 0 Jul12 ? 00:00:00 /usr/bin/dbus-daemon
--config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork
--print-address 3
333:vu-popp+ 16543 16502 0 22:52 ? 00:00:00 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --nopidfile --systemd-activation
--syslog-only

On container, user can't connect to dbus session, and I have no idea why.
May someone please give me some hints on how to debug this issue? Thank you
Simon McVittie
2017-07-18 13:02:30 UTC
Permalink
Raw Message
After upgrade from Fedora 25 to 26, there is no more user dbus session for user
in container.
...
On container, user can't connect to dbus session, and I have no idea why.
May someone please give me some hints on how to debug this issue?
Please start by reading the system log (the Journal).

The chain of events that is meant to result in a D-Bus session bus is:

* A user logging in (somehow) starts a login session
* The login session starts an instance of `systemd --user`
* `systemd --user` starts the dbus.socket user service, listening on
that user's $XDG_RUNTIME_DIR/bus
* Some client in the login session interacts with the session bus
* As a side-effect of connecting to $XDG_RUNTIME_DIR/bus,
`systemd --user` starts the dbus.service user service
(dbus-daemon --session --address=systemd:)
* The dbus-daemon accepts the client's connection

The system log should tell you which step in that chain of events is
no longer happening.

S
arnaud gaboury
2017-07-19 09:31:36 UTC
Permalink
Raw Message
Post by arnaud gaboury
After upgrade from Fedora 25 to 26, there is no more user dbus session
for user
Post by arnaud gaboury
in container.
...
Post by arnaud gaboury
On container, user can't connect to dbus session, and I have no idea why.
May someone please give me some hints on how to debug this issue?
Please start by reading the system log (the Journal).
* A user logging in (somehow) starts a login session
* The login session starts an instance of `systemd --user`
* `systemd --user` starts the dbus.socket user service, listening on
that user's $XDG_RUNTIME_DIR/bus
* Some client in the login session interacts with the session bus
* As a side-effect of connecting to $XDG_RUNTIME_DIR/bus,
`systemd --user` starts the dbus.service user service
(dbus-daemon --session --address=systemd:)
* The dbus-daemon accepts the client's connection
I can't tell in the container the variable
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus. I have tried many
places (~/.pam_environment; /etc/systemd/system/***@.service.d/local.conf;
~/.config/systemd/user.conf).
Could it be at the root of my issue? Do I really need a per user dbsu
session in my container?
The system log should tell you which step in that chain of events is
no longer happening.
S
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Simon McVittie
2017-07-19 12:18:26 UTC
Permalink
Raw Message
Do I really need a per user dbsu session in my container?
I don't know. Do you? You haven't said anything about how you start the
container, how you log in to the container, what its purpose is, or how
(if at all) its purpose interacts with the session bus.

Again, the only advice I can give you based on the information you
provided is to read the system log and look for error messages.

If you believe you have found a bug in some component (systemd or dbus
or your container manager), the first step in resolving that bug is
to describe in detail how the bug can be reproduced, including all the
steps taken and any error messages that result from them.

Since the trigger for this regression was a Fedora upgrade, Fedora support
channels might be a more useful source of help and information than the
systemd upstream mailing list (but I suspect the first things they will
ask you to do are to describe the steps to reproduce the issue and check
the system log, so you might as well do those first, and include them
in your request for help).

S
arnaud gaboury
2017-07-19 12:27:38 UTC
Permalink
Raw Message
Post by Simon McVittie
Do I really need a per user dbsu session in my container?
I don't know. Do you? You haven't said anything about how you start the
container,
With the systemd-nspawn@ default unit file with a small override

% cat /etc/systemd/system/systemd-***@.service.d/override.conf


[Service]
ExecStart=
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot
--link-journal=try-guest --network-bridge=br0 -U --settings=override
--machine=%i --bind-ro=/home/gabx
--bind=/home/gabx/share:/home/poisonivy/share


how you log in to the container,


sudo machinectl login poppy
Post by Simon McVittie
what its purpose is, or how
(if at all) its purpose interacts with the session bus.
the machine is a web server with http, ssh, ftp, postfix...
Post by Simon McVittie
Again, the only advice I can give you based on the information you
provided is to read the system log and look for error messages.
I am on the journal
Post by Simon McVittie
If you believe you have found a bug in some component (systemd or dbus
or your container manager), the first step in resolving that bug is
to describe in detail how the bug can be reproduced, including all the
steps taken and any error messages that result from them.
Since the trigger for this regression was a Fedora upgrade, Fedora support
channels might be a more useful source of help and information than the
systemd upstream mailing list (but I suspect the first things they will
ask you to do are to describe the steps to reproduce the issue and check
the system log, so you might as well do those first, and include them
in your request for help).
Thank you again for your patience and answers.
Post by Simon McVittie
S
Loading...