Public bug reported:
If gnome-shell is launched directly instead of launched through gnome-
session, the process spawning `ibus-daemon` might cause deadlock and
unable to start the graphics.
Since `ibusManager.js` checks whether service
`org.freedesktop.IBus.session.GNOME.service` exists. In our case with
Ubuntu ubiquity, we've turned off `gnome-session.service` so that the
check failed and gnome-shell spawns `ibus-daemon` after the check.
I tried using gdb to gnome-shell and discovered it's hanging in a child
process spawning `ibus-daemon`, but is still in child_setup of
`Glib.spawn_async` function:
```
root@dell-desktop:/home/oem# cat /tmp/log
== Stack trace for context 0x5584da793180 ==
#0 5584dbd2d478 i resource:///org/gnome/shell/misc/ibusManager.js:119
(2776aa47bfb0 @ 12)
#1 5584dbd2d3a8 i resource:///org/gnome/shell/misc/ibusManager.js:114
(2776aa47bf60 @ 426)
#2 5584dbd2d308 i resource:///org/gnome/shell/misc/ibusManager.js:90
(2776aa47bec0 @ 162)
#3 5584dbd2d268 i self-hosted:689 (34e3dc212650 @ 15)
```
which is, in ibusManager.js:
```
const [success_, pid] = GLib.spawn_async(
null, cmdLine, env,
GLib.SpawnFlags.SEARCH_PATH | GLib.SpawnFlags.DO_NOT_REAP_CHILD,
() => {
try {
global.context.restore_rlimit_nofile(); # <- here
} catch (err) {
}
}
);
```
Further code tracing found out that the deadlock is not during the
execution of the function (`restore_rlimit_nofile`) but the access to
the GObject (probably `global.context`).
Currently my propose to work around this issue is to add a 5 second
`setTimeout` to the caller of `_spawn` function in `ibusManager.js`.
I've lost debugging information but I can try reproducing the issue and
give the backtrace from gdb if needed.
** Affects: gnome-shell
Importance: Unknown
Status: Unknown
** Affects: oem-priority
Importance: Undecided
Status: New
** Affects: gnome-shell (Ubuntu)
Importance: Undecided
Status: New
** Tags: oem-priority originate-from-2017628 somerville
** Tags added: oem-priority originate-from-2017628 somerville
** Bug watch added: gitlab.gnome.org/GNOME/gnome-shell/-/issues #6698
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6698
** Also affects: gnome-shell via
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6698
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-shell in Ubuntu.
https://bugs.launchpad.net/bugs/2019776
Title:
If gnome-shell is started directly (instead of through gnome-session),
it might deadlock with no output to the screen
Status in GNOME Shell:
Unknown
Status in OEM Priority Project:
New
Status in gnome-shell package in Ubuntu:
New
Bug description:
If gnome-shell is launched directly instead of launched through gnome-
session, the process spawning `ibus-daemon` might cause deadlock and
unable to start the graphics.
Since `ibusManager.js` checks whether service
`org.freedesktop.IBus.session.GNOME.service` exists. In our case with
Ubuntu ubiquity, we've turned off `gnome-session.service` so that the
check failed and gnome-shell spawns `ibus-daemon` after the check.
I tried using gdb to gnome-shell and discovered it's hanging in a
child process spawning `ibus-daemon`, but is still in child_setup of
`Glib.spawn_async` function:
```
root@dell-desktop:/home/oem# cat /tmp/log
== Stack trace for context 0x5584da793180 ==
#0 5584dbd2d478 i resource:///org/gnome/shell/misc/ibusManager.js:119
(2776aa47bfb0 @ 12)
#1 5584dbd2d3a8 i resource:///org/gnome/shell/misc/ibusManager.js:114
(2776aa47bf60 @ 426)
#2 5584dbd2d308 i resource:///org/gnome/shell/misc/ibusManager.js:90
(2776aa47bec0 @ 162)
#3 5584dbd2d268 i self-hosted:689 (34e3dc212650 @ 15)
```
which is, in ibusManager.js:
```
const [success_, pid] = GLib.spawn_async(
null, cmdLine, env,
GLib.SpawnFlags.SEARCH_PATH |
GLib.SpawnFlags.DO_NOT_REAP_CHILD,
() => {
try {
global.context.restore_rlimit_nofile(); # <- here
} catch (err) {
}
}
);
```
Further code tracing found out that the deadlock is not during the
execution of the function (`restore_rlimit_nofile`) but the access to
the GObject (probably `global.context`).
Currently my propose to work around this issue is to add a 5 second
`setTimeout` to the caller of `_spawn` function in `ibusManager.js`.
I've lost debugging information but I can try reproducing the issue
and give the backtrace from gdb if needed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/2019776/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
