Re: openbox started from .xinitrc partially deadlock if started htop.

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).

This means I have no controling TTY attached to the session.

However there should be away for the xinit script to automatically
disconnect itself from the controlling TTY.

At a minimum the script should redirect standard output and standard error
to a log file of some kind
In my own script I have...

log=".xerrors-$HOST"
> rm -f "$log-prev"
> [ -f "$log" ]  && mv "$log" "$log-prev"
> exec >> "$log" 2>&1     # save the errors here (from here on)


You can also redirect standard input (which is non-sensical for a xinit
script)

exec </dev/null


Though this does not disconnect an 'assigned TTY' (still available from
"/dev/tty") it does cause most programs to assume their isn't one.



On Mon, Jan 2, 2017 at 5:59 PM, D.T. <[email protected]> wrote:

> 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.
>
> Other terminal apps just fail silently, only ncurses apps cause that sort
> of soft freeze.
> Killing them was sufficient iirc.
>
>
>
>
> On January 2, 2017 1:26:56 AM EET, Ian Zimmerman <[email protected]> wrote:
>>
>> 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.
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> _______________________________________________
> openbox mailing list
> [email protected]
> http://icculus.org/mailman/listinfo/openbox
>

_______________________________________________
openbox mailing list
[email protected]
http://icculus.org/mailman/listinfo/openbox