service: Main process exited, code=exited, status=1/FAILUREĪpr 08 06:10:13 Keschdeichel systemd: rtkit-daemon. Rdkit was failing fast and giving up (that will be a different bug, it just seems broken on my system):Īpr 08 06:10:13 Keschdeichel systemd: Started RealtimeKit Scheduling Policy Service.Īpr 08 06:10:13 Keschdeichel rtkit-daemon : Successfully called chroot.Īpr 08 06:10:13 Keschdeichel rtkit-daemon : Successfully dropped privileges.Īpr 08 06:10:13 Keschdeichel rtkit-daemon : Successfully limited resources.Īpr 08 06:10:13 Keschdeichel rtkit-daemon : pthread_create failed: Resource temporarily unavailableĪpr 08 06:10:13 Keschdeichel rtkit-daemon : Canary thread running.Īpr 08 06:10:13 Keschdeichel rtkit-daemon : Exiting canary thread.Īpr 08 06:10:13 Keschdeichel rtkit-daemon : Demoting known real-time threads.Īpr 08 06:10:13 Keschdeichel rtkit-daemon : Demoted 0 threads.Īpr 08 06:10:13 Keschdeichel systemd: rtkit-daemon. rw-r- 1 paelzer whoopsie 52962868 Apr 8 06:09 _usr_bin_ konversation. Multiple apps crashed at 06:09, but we will find later that this is a follow on issue of the underlying gnome/X/.
The following goes *back* in time through my logs one by one.
#Portal reloaded trigger bug update#
Logging in again confirmed that all apps were gone and the gnome shell was brought down what seems like triggered by a background update o accountsservice.Īs always things are not perfectly clear :-/ This morning I found my computer on the login screen.īut not the one of the screen log, no a new one - so something must have crashed.
* Fixed upstream (v251) in https:/ /github. confĮnvironment= SYSTEMD_ NSS_DYNAMIC_ BYPASS= 0 * As a workaround dbus-daemon could be replaced by dbus-broker, which never showed this issue or the behaviour could be changed back by using the `SYSTEMD_ NSS_DYNAMIC_ BYPASS` env variable, like this: * This fix touches the communication between systemd and dbus daemon, especially the NSS lookup, so if something is broken the (user-)name resolution could be broken. * So our test plan is to ask CPC for confirmation if the issue is fixed. * Canonical's CPC team has the ability to reproduce this issue (with a relatively high probability) in their Azure test environment, due to the specific setup they are using * This bug is really hard to reproduce, as can be seen from the multi-year long discussion at https:/ /github. * It can also lead to dbus-daemon being killed/re-started, taking down other services with it, like GDM, killing user sessions on the way (e.g. Which will disable synchronously blocking varlink calls from nss-systemd That by setting SYSTEMD_ NSS_DYNAMIC_ BYPASS= 1 env var for dbus-daemon, Time PID 1 synchronously blocks on some call to dbus-daemon (e.g. * There's currently a deadlock between PID 1 and dbus-daemon: in someĬases dbus-daemon will do NSS lookups (which are blocking) at the same
0 kommentar(er)
