[SOLVED] What happens to stdin and stdout when you're in X

 PID  PPID  SESS  PGID TT       CMD
  950     1   950   950 tty1     -bash
  978   950   950   978 tty1     /bin/sh /usr/bin/startx
  996   978   950   978 tty1     xinit /home/hazel/.xinitrc -- /usr/bin/X :0 -auth /home/hazel/.serverauth.978
 1001   996   950  1001 tty1     fluxbox
 1004  1001   950  1001 tty1     barbarella -t Default .barbarella.default
 1005  1001   950  1001 tty1     barbarella -t Internet .barbarella.internet
 1006  1001   950  1001 tty1     barbarella -t System .barbarella.system
 1007  1001   950  1001 tty1     barbarella -t Manuals .barbarella.manuals
 1009  1001  1009  1009 ?        [fbsetbg] <defunct>
 1030  1005   950  1030 tty1     claws-mail
 1034     1   950  1030 tty1     dbus-launch --autolaunch 965b008c2a8000e20eb705c153447 --binary-syntax --close-stderr
 1035     1  1035  1035 ?        /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
 1040     1   950  1030 tty1     /usr/bin/vivaldi https://www.linuxquestions.org
 1045  1040   950  1030 tty1     cat
 1046  1040   950  1030 tty1     cat
..................... (a load of vivaldi stuff)
 2099  1004   950  2099 tty1     /opt/libreoffice6.1/program/oosplash --writer
 2117  2099   950  2099 tty1     /opt/libreoffice6.1/program/soffice.bin --writer
................................. (more vivaldi stuff)
 2751  1004   950  2751 tty1     xterm
 2753  2751  2753  2753 pts/0    bash 
 2760  2753  2753  2760 pts/0    ps -u hazel -o pid,ppid,sess,pgid,tty,cmd

This is with the modified barbarella program. What I find interesting is that everything uses tty1 except for programs launched inside an xterm.

Right thankyou. As suspected.

There's all sorts of 'horrible' at work here.

1) vim/view trying to use stderr as the terminal when it doesn't have a terminal on stdin/out is just wrong.

2) fluxbox is leaving itself suceptible to SIGTTIN/SIGTTOU by not starting barbarella in its own process group.

3) Ditto barbarella itself (which you've now fixed).

4) Finally, I wonder whether startx/xinitrc should arguably be closing stdin/out and pointing stderr at $HOME/.xsession-errors much like xdm does.

I have to say, I'm not a fan of the various xinitrc and especially /usr/bin/startfluxbox on Slackware (I don't know whether they're just the stock upstream implementations.

Now, compare to my fvwm environment:

$ ps -U $LOGNAME -o pid,ppid,sess,pgid,tty,cmd
  PID  PPID  SESS  PGID TT       CMD
 2365  2312  2365  2365 ?        ck-launch-session /usr/local/bin/startfvwm2 --no-xmodmap --no-xrdb --no-gvfs
 2379  2365  2365  2365 ?        /usr/bin/fvwm2
 2383     1  2365  2365 ?        dbus-launch --sh-syntax --exit-with-session
 2384     1  2384  2384 ?        /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
 2388  2379  2365  2365 ?        /usr/libexec/fvwm/2.6.8/FvwmButtons 7 4 none 0 8 RightPanel
 2389  2379  2365  2365 ?        /usr/libexec/fvwm/2.6.8/FvwmEvent 9 4 none 0 8 EventNewDesk
 2390  2379  2365  2365 ?        /usr/libexec/fvwm/2.6.8/FvwmEvent 11 4 none 0 8 EventNewWindow
 2394     1  2384  2384 ?        /usr/libexec/gvfsd
 2395  2379  2365  2395 ?        xload -geometry -0-0 -bg rgb:0000/3c3c/3c3c -fg rgb:ffff/ffff/ffff -nolabel -scale 4
 2396  2379  2365  2365 ?        /usr/libexec/fvwm/2.6.8/FvwmIconMan 13 4 none 0 8
 2397  2379  2365  2397 ?        xclock -geometry -0-0 -bg rgb:0000/3c3c/3c3c -fg rgb:ffff/ffff/ffff -hd rgb:ffff/ffff/ffff
 2398  2379  2365  2398 ?        xkbvleds -geometry -0-0 -watch 3 -bg rgb:0000/3c3c/3c3c -xrm *ledHeight: 15 -xrm *vSpace: 
 3630  2379  2365  3630 ?        firefox
 3661     1  2384  2384 ?        /usr/libexec/at-spi-bus-launcher
 3681  3630  2365  3630 ?        /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -intPrefs 236:1| -boolPre
 3722  3630  2365  3630 ?        /usr/lib64/firefox/firefox -contentproc -childID 2 -isForBrowser -intPrefs 236:1| -boolPre
 3739     1  2384  2384 ?        /usr/libexec/gconfd-2
 3787  2379  2365  3787 ?        xterm
 3789  3787  3789  3789 pts/0    bash
 4141  3789  3789  4141 pts/0    ps -U test -o pid,ppid,sess,pgid,tty,cmd

everything started by fvwm (xload/xclock/xkbleds/firefox/xterm) are all in their own process group, so fvwm wouldn't be susceptible to this issue. You'll also notice that they have no controlling TTY.

In short, UNIX processes are susceptible to getting bad signals unless they take defensive action, and fluxbox didn't. X was working fine, it was just that the window manager got suspended.

If it's fluxbox that stopped, that explains the behaviour of both keyboard and mouse. Moving the mouse cursor around is the job of X and that worked fine. Clicks were probably being picked up too, but they had no effect because they couldn't be localised to a window (or to the taskbar). That's the job of the window manager. And the keyboard worked for switching consoles but not for typing into an xterm.

I wonder if this extract from startx is relevant:

  # When starting the defaultserver start X on the current tty to avoid
    # the startx session being seen as inactive:
    # "https://bugzilla.redhat.com/show_bug.cgi?id=806491"
    if [ -x /usr/lib/systemd/systemd -o -x /lib/systemd/systemd ]; then
        tty=$(tty)
        if expr match "$tty" '^/dev/tty[0-9]\+$' > /dev/null; then
            tty_num=$(echo "$tty" | grep -oE '[0-9]+$')
            vtarg="vt$tty_num"
        fi
    fi

If that's really what's causing the problem, then I think the Slackware team ought to know about it.

No, I don't believe that section is anything to do with it.

You've found an extreme edge case here. In order to hit the problem, fluxbox had to fail to setpgid(), your program had to fail to setpgid() and your program had to try and run a tty based program without a tty.
I don't believe that's something you can expect a distro maintainer to come up with a solution for.

'startx' is really ugly, there's no getting around that. Slackware's xinitrc's and Xsession setup isn't ideal either. I've discussed improvements in the past but Pat didn't want to make changes owing to resource constraints (amongst other considerations), which is not entirely unreasonable.

Perhaps you'd be better off getting in touch with the fluxbox devs and suggesting they setpgid(0,0) before spawning any external processes in order to make it a little more resilient.

Originally Posted by GazL Perhaps you'd be better off getting in touch with the fluxbox devs and suggesting they setpgid(0,0) before spawning any external processes in order to make it a little more resilient.

How exactly do I do that? I don't know the correct protocol for these things. Should I email one of the project developers or would that be a bit cheeky. After all, if I hadn't made two mistakes in a row, this would never have surfaced.

I've certainly emailed people before. As long as you're respectful in your email it's generally received well, but obviously it's going to depend on the personality of the individual you're contacting.

http://fluxbox.org/help/ has a number of contact methods, but if you're uncomfortable with contacting them or if you think it's such a minor issue you don't think it's worth the effort you could just let it sit. No one would blame you and you're unlikely to hit the same issue again.

Originally Posted by GNU libc manual When a process in a background job tries to read from its controlling terminal, the process group is usually sent a SIGTTIN signal. This normally causes all of the processes in that group to stop (unless they handle the signal and don’t stop themselves). However, if the reading process is ignoring or blocking this signal, then read fails with an EIO error instead.

So it seems that the SIGTTIN is sent to the whole process group, not just the offending program. If barbarella and the program that it launches belong to the same group as fluxbox, then fluxbox stops too.

yes, exactly.

man 7 credentials is also worth a read, which is what helped me figure it out.

I still don't understand the difference between process groups and sessions. I mean, I get that process groups are smaller and are contained within sessions, but I don't understand why there are these two levels. In what circumstances would you create a new process group as distinct from a new session (or the reverse)?

That man page is too much oriented to the command line. For example, it identifies process groups with groups of programs that are launched together as a pipeline. But this thread so far suggests that graphical programs don't usually create new process groups or new sessions when they fork off new processes. Why not? And when would they (apart from fixing a bug like we just did)?

As I understand it, the session leader is for things like the shell process itself, then each command or pipeline that you start from that shell is run as a separate process group within that session. It's the session leader who then manages which process/process group is foreground/background and which gets the terminal input/output at any given time.

Now, for non tty based processes which are outside of a shell and that don't have a controlling terminal, or the need for job control, then I guess sessions are less meaningful, but I suppose one might want to group a bunch of related processes into a session to keep them all together even though there's no job control to speak of that would require it.

Now I understand it a little clear than I did at the start of this discussion I believe that in this particular case (a GUI application launcher) its correct to start a new process group and not a new session.