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)
```
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.
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.freedeskto p.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:
``` desktop: /home/oem# cat /tmp/log ///org/ gnome/shell/ misc/ibusManage r.js:119 (2776aa47bfb0 @ 12) ///org/ gnome/shell/ misc/ibusManage r.js:114 (2776aa47bf60 @ 426) ///org/ gnome/shell/ misc/ibusManage r.js:90 (2776aa47bec0 @ 162)
root@dell-
== Stack trace for context 0x5584da793180 ==
#0 5584dbd2d478 i resource:
#1 5584dbd2d3a8 i resource:
#2 5584dbd2d308 i resource:
#3 5584dbd2d268 i self-hosted:689 (34e3dc212650 @ 15)
```
which is, in ibusManager.js:
```
null, cmdLine, env,
GLib. SpawnFlags. SEARCH_ PATH | GLib.SpawnFlags .DO_NOT_ REAP_CHILD,
try {
global. context. restore_ rlimit_ nofile( ); # <- here
} catch (err) {
}
const [success_, pid] = GLib.spawn_async(
() => {
}
);
```
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.