Am Montag, 1. April 2019, 23:02:23 CEST schrieb Patrick Shanahan:

* Axel Braun [04-01-19 15:26]:

...

Updated yesterday to latest TW, and see akonadi crashing since then:

docb@T520:~> akonadictl start QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-docb' D-Bus session bus is not available! KCrash: Application 'akonadictl' crashing... KCrash: Attempting to start /usr/lib64/libexec/drkonqi from kdeinit sock_file=/tmp/runtime-docb/kdeinit5__0 QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-docb'

[1]+ Angehalten akonadictl start docb@T520:~> Unable to start Dr. Konqi Re-raising signal for core dump handling.

-> this results in some empty kcrash files in /tmp/runtime-docb

Search for dbus: docb@T520:/tmp/runtime-docb> ps ax | grep dbus

1327 ? Ss 0:03 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only 3252 ? S 0:00 dbus-launch --autolaunch 80aebf79d908490c8d56b7d561a2aae0 --binary-syntax --close-stderr 3253 ? Ss 0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session 3410 ? Sl 0:00 /usr/bin/gmenudbusmenuproxy 4466 pts/0 S+ 0:00 grep --color=auto dbus

several have been offered in the last few days

The thread you mentioned: in opensuse-kde beginning 31-03-19 Subj: akonadiserver and kmail are leaking memory deals with akonadi consuming all memory. This is in fact a different issue than the missing connection to dbus. Other things are not working properly as well in KDE, like (no change of volume via hotkeys, no on-screen display for the same) so I guess KDE is not necessarily the originator of the problem Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Dienstag, 2. April 2019, 19:13:27 CEST schrieb Wolfgang Bauer:

Am Dienstag, 2. April 2019, 18:20:49 schrieb Axel Braun:

...

The thread you mentioned: in opensuse-kde beginning 31-03-19 Subj: akonadiserver and kmail are leaking memory

deals with akonadi consuming all memory.

Hm, I don't see any particular thread mentioned...

Maybe he meant e.g. this one? https://lists.opensuse.org/opensuse-factory/2019-03/msg00367.html

yes, looks like

...

This is in fact a different issue than the missing connection to dbus. Other things are not working properly as well in KDE, like (no change of volume via hotkeys, no on-screen display for the same) so I guess KDE is not necessarily the originator of the problem

Certainly not. The dbus user session bus is not found, and XDG_RUNTIME_DIR is not set. The latter is normally done by pam_systemd on login.

This looks very much like http://bugzilla.opensuse.org/show_bug.cgi?id=1130654 (mentioned in the above thread), which IMHO is the same issue as https://bugzilla.opensuse.org/show_bug.cgi?id=1129830.

In short: It seems that systemd "forgets" that /home is mounted in certain cases and tries to mount it again on login. This fails of course (as it is already mounted), causing pam_systemd to error out and again unset XDG_RUNTIME_DIR and deleting the corresponding directory (/run/user/$id/) which should contain the socket to connect to the DBUS session bus (as referenced by $DBUS_SESSION_BUS_ADDRESS).

A "workaround" would be to run "export dbus-launch" in the shell before starting "akonadictl start" or other applications, but that won't "fix" already running things of course.

yes, and that forces other things to fall apart. like camera for example

Markos found out that it works for him when removes the "nofail" option from the fstab entry for /home (and use "defaults" instead), maybe this would help here too?

When I remove the nofail option I end up in a rescue session. running systemctl start mount.home fails as well. So I put the nofail option into /etc/fstab back in (encrypted xfs partition, as in https://bugzilla.opensuse.org/show_bug.cgi?id=1129830) and left the rescue session with CRTL-D. not the graphical screen came up, but after logging in it still failed.

Otherwise, this should work too I suppose:

...

When I umount /home and mount it manually via systemctl start home.mount again the state is fixed and I can log in anymore.

(taken from the second bug report, you need to do that *before* logging in of course)

Sure. But seems not to be the silver bullet yet. And it leaves the question open why it suddenly fails. (will try a rollback now...) Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Dienstag, 2. April 2019, 22:16:50 schrieb Axel Braun:

...

Markos found out that it works for him when removes the "nofail" option from the fstab entry for /home (and use "defaults" instead), maybe this would help here too?

When I remove the nofail option I end up in a rescue session.

If that is the case, the mount must have failed before IMHO and the failure was only ignored because of the "nofail" option. Although I suppose you would have had different problems then... Maybe you made a mistake when modifying the fstab entry? Just to be sure: if "nofail" is the only mount option, you must replace it with "defaults", otherwise it should be enough to just omit it. Oh, and I forgot to mention that you might have to run mkinitrd too after the change, some things are mounted before / is available.

...

Otherwise, this should work too I suppose:

...

When I umount /home and mount it manually via systemctl start home.mount again the state is fixed and I can log in anymore.

(taken from the second bug report, you need to do that *before* logging in of course)

Sure. But seems not to be the silver bullet yet.

Of course not. It was rather meant as a workaround to get a working desktop session until the bug is fixed. Also, if that works it certainly "proves" that you actually have the same (underlying) problem.

And it leaves the question open why it suddenly fails.

Indeed. Or why it did not fail before... Especially as the problem started with earlier already for other people. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org