Re: openbox started from .xinitrc partially deadlock if started htop.
Ian Zimmerman <[email protected]> Sun, 1 Jan 2017 15:26:56 -0800
| Newsgroups | gmane.comp.window-managers.openbox |
|---|---|
| Message-ID | <[email protected]> |
On 2017-01-01 21:57, Piotr Karbowski wrote: > If I try to start htop (ncurses application) via gmrun, the parent of > htop become openbox, the htop goes into T state and half of my system > deadlocks. Deadbeef, Firefox and Thunderbird goes gray and does not > respond/refresh. I can still use openbox, switch windows and spawn new > processes. > > It's not possible to kill neither htop nor openbox, but if I kill the > 'sh /home/piotr/.xinitrc' which shares the process group with both > openbox and htop then system recovers, everything spawned from it is > killed, I can start it up again and things works. > > If I start urxvt (terminal emulator) and then run gmrun there, run > htop thru gmrun, then the htop displays itself on the terminal from > where I started gmrun from. This confusess me greatly. > > Can someone help me understand what is going on here and where the > problem is, actually? A ncurses application that try to overtake the > terminal of parent, or openbox not handling such bizzare usecase? > Running ncurses application outside of terminal emulator should fail > anyway, but not in such way. I don't have a solution or even an answer, but since I use X and openbox in much the same way as you do, I took a quick look at the involved processes. What I see is that openbox and even its direct children (ie. GUI apps) keep the controlling terminal inherited from startx - i.e. the VT where you run startx from. To me this looks like a bug in xinit. It should drop the controlling terminal when forking the "master" app, that is openbox in this case. But maybe a work-around would be to drop it in openbox instead, subject to an option? Unfortunately this area is one that is getting taken over by systemd - see for example http://www.gossamer-threads.com/lists/gentoo/user/320739 so, I suspect that any solution will have to be self-supported. -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html _______________________________________________ openbox mailing list [email protected] http://icculus.org/mailman/listinfo/openbox