Unlocking existing session yields black screen. Closing then reopening XFCE session fails with dbus error. xterm X session + startxfce4 works. Other users are ok.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dbus (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
# Context
* Xubuntu 18.04 using lightdm, no specific customization, no xscreensaver/
* Problem observed two machines:
** one machine with several users often swapping sessions,
** one machine with just one regular user who just locks/unlocks session often
# Action
* Open a XFCE session.
* Lock it.
* On greeter, type password to unlock.
# Expected
* Get back to opened session.
# Observed
* After typing password, screen turns to black. All pixels are fully black.
* Not even a mouse pointer is visible.
# Reproducible
* Seems random.
* Perhaps one time out of 20-50 unlock operations.
* Never occurred in 16.04 14.04
# Detailed information
From start:
* On unlocking an already opened session, after typing password screen turns to full black.
## Investigation: is machine still okay?
* As a sanity check, switching to text VT works, login on text VT works.
## Investigation: problem does not affect all sessions at once
* Bug observed both in one system with one user at a time, and on another system with two users alternating X sessions.
* From tty1, using "dm-tool switch-to-greeter" with proper environment works, allows to select other user's session, type password and return to that other user's opened session. Any attempt to return to affected user session yields black screen.
## Investigation: problem affects user even after closing all their programs
* Manually killing affected user processes allows to close faulty session and see lightdm greeter come back.
* Trying to reopen a session (as usual with lightdm) as affected user shows an error dialog:
"Unable to contact settings server
Failed to connect to socket /run/user/1000/bus: Connection refused"
and a "Close" button.
Clicking on it yields a second dialog :
"Unable to load failsafe session
Unable to determine a failsafe session name. Possible causes:
xfconfd isn't running (D-Bus setup problem);
environment variable $XDG_CONFIG_DIRS is set incorrectly (must include "/etc"),
or xfce4-session is installed incorrectly."
and a "Quit" button.
Clicking "quit" button goes back to lightdm greeter.
## Investigation: reboot solves the problem
* Rebooting the machine solves the problem (but closes all user sessions and processes).
* Problem reappears after a few days.
## Investigation: startx affected, too
* From text VT, startx has same behavior as running from lightdm and thus also cannot reach a working XFCE desktop.
## Investigation: affected user has no dbus-daemon running.
* No "/usr/bin/
## Additional information
* It is believed that the multi-user system makes the bug more salient than usual workflow because users switch more often from one session to another.
* It is believed that the single-user system makes the bug more salient than usual workflow because users often locks and unlocks their session.
1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu
Description: Ubuntu 18.04 LTS
Release: 18.04
Actually Xubuntu 18.04.
2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center
export LC_ALL=C ; apt-cache policy dbus
dbus:
Installed: 1.12.2-1ubuntu1
Candidate: 1.12.2-1ubuntu1
Version table:
*** 1.12.2-1ubuntu1 500
500 http://
100 /var/lib/
3) What you expected to happen
4) What happened instead
Described above.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dbus 1.12.2-1ubuntu1
ProcVersionSign
Uname: Linux 4.15.0-23-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Mon Jul 2 13:43:08 2018
InstallationDate: Installed on 2018-05-25 (38 days ago)
InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
ProcEnviron:
TERM=xterm-
PATH=(custom, no user)
LANG=fr_FR.UTF-8
SHELL=/bin/bash
SourcePackage: dbus
UpgradeStatus: No upgrade log present (probably fresh install)
Also, the problem is not specific to any user.
It randomly affects any of the users of the machine. At that moment only that user is affected.
Next time it may affect the same user or another.
We believe that it may affect several users at a time, if we keep the machine running until problem affects a second user. In practice, however, users have some work to do, so we reboot the machine to let them continue their work.