restarting i3 forgets i3bar as a zombie process #5756
Comments
|
I don’t see a link to logs.i3wm.org. Did you follow https://i3wm.org/docs/debugging.html? (In case you actually provided a link to a logfile, please ignore me.) |
|
I can reproduce the issue. As far as I can tell, WhyBefore 3ae5f31, when the double forking logic was used, every child process of i3 was immediately reparented, so taking care of that process's zombieness was never i3's responsibility. After double forking was removed, child processes of i3 started dying, becoming zombies, and getting reaped by libev, regardless of how they were spawned and even regardless of whether they were spawned by this current i3 or one of its previous incarnations (previous processes which The problem now is a race condition: if a child of i3 is still alive when i3 is restarting but dies before i3 creates the libev event loop, the event of that child's termination is lost. This is what seems to be happening with i3bar. How to fixI see a couple of possible solutions, I am not sure which one fits best.
|
|
Okay, after writing it all out, I now come to a conclusion that, perhaps, the second option makes more sense than the other two. The following patch fixes it for me: diff --git a/src/main.c b/src/main.c
index 6fae7e41..e294f50e 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1202,6 +1202,17 @@ int main(int argc, char *argv[]) {
* when calling exit() */
atexit(i3_exit);
+ /* There might be children who died before we initialized the event loop,
+ * e.g., when restarting i3 (see #5756).
+ * To not carry zombie children around, raise the signal to invite libev to
+ * reap them.
+ *
+ * Note that there is no race condition between raising the signal and
+ * entering the event loop below: the signal is just to notify libev that
+ * zombies might already be there. The child reaping will happen in the
+ * event loop anyway. */
+ (void)raise(SIGCHLD);
+
sd_notify(1, "READY=1");
ev_loop(main_loop, 0); |
One case when this might be useful is when i3 is restarted and there are children that terminate after the previous i3 instance shut down but before the new one set things up. Fixes i3#5756
One case when this might be useful is when i3 is restarted and there are children that terminate after the previous i3 instance shut down but before the new one set things up. Fixes i3#5756
I'm submitting a…
Current Behavior
When restarting i3, a new i3bar process is spawned and the old one is left alive as a zombie.
Expected Behavior
The old i3bar process is correctly closed.
Reproduction Instructions
Press
$mod+Shift+rto restart i3.Environment
Output of
i3 --moreversion 2>&-:Config file
Tomorrow I will try to provide a log file.
Thanks for your help!
The text was updated successfully, but these errors were encountered: