<div dir="ltr">I also use .xinitrc with openbox, but I launch it from the gdm.  I select "User Session" from the menu during login (once only) after installing the package "xorg-x11-xinit-session"  (Fedora).<div><br></div><div>This means I have no controling TTY attached to the session.</div><div><br></div><div>However there should be away for the xinit script to automatically disconnect itself from the controlling TTY. </div><div><br></div><div>At a minimum the script should redirect standard output and standard error to a log file of some kind</div><div>In my own script I have...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="monospace, monospace">log=".xerrors-$HOST"<br></font><font face="monospace, monospace">rm -f "$log-prev"<br></font><font face="monospace, monospace">[ -f "$log" ]  && mv "$log" "$log-prev"</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">exec >> "$log" 2>&1     # save the errors here (from here on)</font></blockquote><div><br></div><div>You can also redirect standard input (which is non-sensical for a xinit script)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="monospace, monospace">exec </dev/null</font></blockquote><div><br></div><div>Though this does not disconnect an 'assigned TTY' (still available from "/dev/tty") it does cause most programs to assume their isn't one.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 2, 2017 at 5:59 PM, D.T. <span dir="ltr"><<a href="mailto:turkuting@gmail.com" target="_blank">turkuting@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I have noticed the exact same behavior for ncurses applications started directly from a launcher, i.e. not inside a terminal window. The launcher was dmenu in my case, and I probably wasn't even running openbox. I do however start all my window managers from .xinitrc.<br>
<br>
Other terminal apps just fail silently, only ncurses apps cause that sort of soft freeze.<br>
Killing them was sufficient iirc.<div><div class="h5"><br>
<br>
<br><br><div class="gmail_quote">On January 2, 2017 1:26:56 AM EET, Ian Zimmerman <<a href="mailto:itz@primate.net" target="_blank">itz@primate.net</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<pre class="m_-5782081483241810349k9mail">On 2017-01-01 21:57, Piotr Karbowski wrote:<br><br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #729fcf;padding-left:1ex"> If I try to start htop (ncurses application) via gmrun, the parent of<br> htop become openbox, the htop goes into T state and half of my system<br> deadlocks. Deadbeef, Firefox and Thunderbird goes gray and does not<br> respond/refresh. I can still use openbox, switch windows and spawn new<br> processes.<br> <br> It's not possible to kill neither htop nor openbox, but if I kill the<br> 'sh /home/piotr/.xinitrc' which shares the process group with both<br> openbox and htop then system recovers, everything spawned from it is<br> killed, I can start it up again and things works.<br> <br> If I start urxvt (terminal emulator) and then run gmrun there, run<br> htop thru gmrun, then the htop displays itself on the terminal from<br> where I started gmrun from. This confusess me greatly.<br> <br> Can someone help me understand what is going on here and where the<br> problem is, actually? A ncurses application that try to overtake the<br> terminal of parent, or openbox not handling such bizzare usecase?<br> Running ncurses application outside of terminal emulator should fail<br> anyway, but not in such way.<br></blockquote><br>I don't have a solution or even an answer, but since I use X and openbox<br>in much the same way as you do, I took a quick look at the involved<br>processes.  What I see is that openbox and even its direct children<br>(ie. GUI apps) keep the controlling terminal inherited from startx -<br>i.e. the VT where you run startx from.<br><br>To me this looks like a bug in xinit.  It should drop the controlling<br>terminal when forking the "master" app, that is openbox in this case.<br><br>But maybe a work-around would be to drop it in openbox instead, subject<br>to an option?<br><br>Unfortunately this area is one that is getting taken over by systemd -<br>see for example<br><br><a href="http://www.gossamer-threads.com/lists/gentoo/user/320739" target="_blank">http://www.gossamer-threads.<wbr>com/lists/gentoo/user/320739</a><br><br>so, I suspect that any solution will have to be self-supported.<br></pre></blockquote></div><br>
-- <br></div></div>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</div><br>______________________________<wbr>_________________<br>
openbox mailing list<br>
<a href="mailto:openbox@icculus.org">openbox@icculus.org</a><br>
<a href="http://icculus.org/mailman/listinfo/openbox" rel="noreferrer" target="_blank">http://icculus.org/mailman/<wbr>listinfo/openbox</a><br></blockquote></div><br></div>