[opensuse-factory] Latest TW: akonadi crashes
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 Any idea? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Axel Braun <Axel.Braun@gmx.de> [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 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 1. April 2019, 23:02:23 CEST schrieb Patrick Shanahan:
* Axel Braun <Axel.Braun@gmx.de> [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, 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
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. 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? 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)
Kind Regards, Wolfgang -- 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
On 02/04/2019 22.16, Axel Braun wrote:
Am Dienstag, 2. April 2019, 19:13:27 CEST schrieb Wolfgang Bauer:
...
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.
That points to another preexisting problem. Mount home should not fail. When I try to mount a second time on my laptop, which also has home encrypted, it simply says that it is already mounted. And "mount /home" the first time would fail because it doesn't ask for the password, it is not done that way. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
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
Am Mittwoch, 3. April 2019, 11:36:51 CEST schrieb Wolfgang Bauer:
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.
Uh, my bad....yes, adding defautls and mkinitrd made the system boot again
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.
It seems to be related to encrypted home partition...thats at least what all have in common
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.
No, it probably started at the same time. Due to vacation I jumped from 20190217 to 20190327.... Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Axel Braun -
Axel Braun
-
Carlos E. R. -
Patrick Shanahan -
Wolfgang Bauer