FS#53268 - [systemd] 233-1 prevents to startx. "Could not sync environment to dbus.". Disk quota exceeded.

Attached to Project: Arch Linux
Opened by dreem (dreem) - Sunday, 12 March 2017, 10:28 GMT
Last edited by Christian Hesse (eworm) - Thursday, 13 July 2017, 19:58 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
After upgrading systemd to 233-1 and rebooting the machine, starting sddm, and authorizing user - desktop environment (particulary plasma) is unable to start showing "Could not sync environment to dbus." error window.

journalctl doesn't notice anything particulary interesting except for this:
systemd[916]: user@994.service: Failed at step KEYRING spawning /usr/lib/systemd/systemd: Disk quota exceeded

It's interesting because i'm not using quota.

My Arch is installed on btrfs filesystem, build on two phisical disks:
# btrfs fi show
Label: 'archlinux' uuid: 75887859-50e0-4bd8-98b2-84e6ad916a29
Total devices 2 FS bytes used 171.24GiB
devid 1 size 123.00GiB used 89.03GiB path /dev/sda2
devid 2 size 123.00GiB used 89.03GiB path /dev/sdb1


# LANG=C df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 246G 174G 71G 72% /

# mount | grep -i " / "
/dev/sda2 on / type btrfs (rw,noatime,compress=lzo,ssd,discard,space_cache,autodefrag,subvolid=2804,subvol=/rootfs)


Btrfs volume is sliced to basic subvolumes to allow snapshoting with subvolumes:
- rootfs
- homefs
- pacpkg
- snaps
I believe the names are self-describing.

Downgrading btrfs-progs from 4.10-1 to 4.9.1-1 didn't help.
Downgrading systemd and systemd-sysvcompat to 232-8 (with newest btrfs-progs 4.10-1 installed) solved the problem.



Additional info:
* package version(s)
233-1

* config and/or log files etc.
journalctl -b said:
mar 12 10:53:28 xaos systemd[916]: user@994.service: Failed at step KEYRING spawning /usr/lib/systemd/systemd: Disk quota exceeded
mar 12 10:53:28 xaos systemd[1]: Started Session c1 of user sddm.
mar 12 10:53:28 xaos systemd[1]: Failed to start User Manager for UID 994.
mar 12 10:53:28 xaos systemd[1]: user@994.service: Unit entered failed state.
mar 12 10:53:28 xaos systemd[1]: user@994.service: Failed with result 'protocol'.
mar 12 10:53:28 xaos sddm-helper[914]: pam_systemd(sddm-greeter:session): Failed to create session: Start job for unit user@994.service failed with 'failed'

startx (with exec startkde) said:
X.Org X Server 1.19.2
Release Date: 2017-03-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.13-1-lts x86_64
Current Operating System: Linux xaos 4.11.0-rc1-mainline #1 SMP PREEMPT Tue Mar 7 09:55:43 CET 2017 x86_64
Kernel command line: BOOT_IMAGE=../vmlinuz-linux-mainline root=/dev/disk/by-uuid/75887859-50e0-4bd8-98b2-84e6ad916a29 edd=off rw rootflags=subvol=rootfs initrd=../initramfs-linux-mainline.img
Build Date: 03 March 2017 06:00:24PM

Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/dreem/.local/share/xorg/Xorg.0.log", Time: Sat Mar 11 23:46:29 2017
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(II) [KMS] Kernel modesetting enabled.
Loading stage "initial" 151
startkde: Starting up...
dbus-update-activation-environment: error: unable to connect to D-Bus: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead
startkde: Could not sync environment to dbus.
xinit: connection to X server lost

waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.


Steps to reproduce:
Assuming that problem only occurs when using btrfs:
1. update systemd to 233-1
2. reboot
This task depends upon

Closed by  Christian Hesse (eworm)
Thursday, 13 July 2017, 19:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  systemd 233.75-2
Comment by dreem (dreem) - Sunday, 12 March 2017, 10:32 GMT
Note: don't be concerned about 4.11.0-rc1-mainline kernel, exactly same is happening on 4.10.1-1-ARCH
Comment by dreem (dreem) - Sunday, 12 March 2017, 10:38 GMT
during conversation on IRC #archlinux one user confirmed that he was also touched by the "Could not sync environment to dbus." problem and that commenting testing and downgrade helped.
Comment by Dave Reisner (falconindy) - Sunday, 12 March 2017, 13:35 GMT
Probably related to one of the two commits mentioned in https://github.com/systemd/systemd/issues/5522
Comment by Alexander Minges (athemis) - Wednesday, 15 March 2017, 13:00 GMT
Happens on my system as well, though I'm _not_ using btrfs, but ext4.
Comment by Richard Ullger (rullger) - Tuesday, 23 May 2017, 10:56 GMT
This issue is intermittent on my system. Sometimes I successfully log in, sometimes I get the "Could not sync environment to dbus." error. When I do get the error I have always managed to log in by switching to another tty and restarting sddm (sudo systemctl restart sddm). When sddm comes up I can then log in.
Comment by Daniel Bermond (Bermond) - Saturday, 10 June 2017, 01:56 GMT
This same dbus error message is showing to me when starting plasma, preventing it to load. But I'm on systemd 232-8 and ext4, so I'm not sure it's related to this bug. This issue started to happen after the update to Qt 5.9.
Comment by Daniel Bermond (Bermond) - Saturday, 10 June 2017, 04:07 GMT
Found what was causing my dbus message issue: problem with '~/.config' folder. Somehow it got messed after an update, even with wrong permissions.
I could fix this with 'rm -rf ~/.config'. Computer is usable again.
Comment by Pavel (bartender) - Saturday, 17 June 2017, 09:12 GMT
I have this error even even with systemd 232 (never updated to 233).
Comment by Pavel (bartender) - Saturday, 17 June 2017, 09:53 GMT
Hint for you: I was able to solve this by replacing my custom user service gpg-agent.service in ~/.config/systemd/user with package-provided.
Somehow user the failed start of user services was interferring with normal login process — user instance of systemd broke.
Comment by dreem (dreem) - Saturday, 17 June 2017, 16:30 GMT
Earlier suggested removing whole ~/.config directory is imho inacceptable. Also my system is missing ~/.config/systemd directory, so this workoarund won't work for me.
Comment by dreem (dreem) - Thursday, 13 July 2017, 19:39 GMT
fixed in systemd 234.0-1
No more problems like one from subject.
Now catching "Process Xorg of user 0 dumped core" @ sddm, gdm works fine tho and I am able to login to kde, different problem.
Comment by Christian Hesse (eworm) - Thursday, 13 July 2017, 19:57 GMT
Should be fixed since systemd 233.75-2 with reverting the keyring commits.

Loading...