Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
As I understand, graphical logins via a display manager like gdm executes an X/Wayland session directly after authenticating a user, instead of executing a login shell. I see that both X and Wayland sessions are started on a virtual terminal (tty2), and what the Xorg(1) says about the vt option is: 'This option applies only to platforms that have virtual terminal support, such as Linux, BSD, OpenSolaris, SVR3, and SVR4.' Is starting X/Wayland sessions with a controlling tty done merely to provide the ability to switch to other virtual terminals while running a graphical shell in one, or is it a constraint of X/Wayland? Is it possible to start an X/Wayland session without a controlling tty on Linux, and is this up to gdm, X/Wayland, or systemd? And what would be an example of a system that runs Xorg and doesn't have virtual terminals at all unlike the systems listed in Xorg(1)?
Wayland sessions are started on a virtual terminal (tty2), and what the Xorg(1) says about the vt option is: 'This option applies only to platforms that have virtual terminal support, such as Linux, BSD, OpenSolaris, SVR3, and SVR4.'
Just a note: tty2 is not a virtual terminal but one of the (normally 6) console terminals of the system (X itself normally is using tty1).
Virtual (or more usual named pseudo) terminals in Linux are pts/X (Pseudo Terminal Stream) or (historically) pty's. The X-server does create a virtual terminal, but that mostly is using "the next available console" one, so quite often tty7.
Just a note: tty2 is not a virtual terminal but one of the (normally 6) console terminals of the system (X itself normally is using tty1).
Virtual (or more usual named pseudo) terminals in Linux are pts/X (Pseudo Terminal Stream) or (historically) pty's. The X-server does create a virtual terminal, but that mostly is using "the next available console" one, so quite often tty7.
I appreciate it, but you're wrong: A computer console, or a system console, is just a text terminal, as opposed to a graphical terminal; as in a vector-mode or raster-mode graphical terminal. And, a terminal emulator, which is associated with a pseudo-terminal slave and master parts, is just a piece of software that emulates a text terminal in a graphical environment. The device special files for virtual console screens, /dev/vcs[1-63], and virtual console screens with attributes, /dev/vcsa[0-63], just represent virtual terminal memories associated with the virtual terminals, /dev/tty[1-63]. The Linux console exists in a virtual terminal as real terminals are neither used nor needed anymore due to processing units being integrated with dumb terminals in the form of monitors and keyboards connected to computers as peripheral devices, where a single monitor and keyboard pair can be used with many terminals virtualized by the kernel now, much like the virtual file system interface between system calls above and concrete file system implementations below.
In the above output for the ps command, the Xorg command is run with the "vt" option and the value "2" referring to tty2 as the virtual terminal requested.
Quote:
[ Xorg(1) ]
vtXX XX specifies the Virtual Terminal device number which Xorg will use. Without this option, Xorg will pick the first available Virtual Terminal that it can locate. This option applies only to platforms that have virtual terminal support, such as Linux, BSD, OpenSolaris, SVR3, and SVR4.
[ github.com/torvalds/linux/blob/master/drivers/tty/vt/vt_ioctl.c ]
/* Console (vt and kd) routines, as defined by USL SVR4 manual, and by
* experimentation and study of X386 SYSV handling.
*
* One point of difference: SYSV vt's are /dev/vtX, which X >= 0, and
* /dev/console is a separate ttyp. Under Linux, /dev/tty0 is /dev/console,
* and the vc start at /dev/ttyX, X >= 1... */
Quote:
[ en.wikipedia.org/wiki/Virtual_console ]
A virtual console (VC) – also known as a virtual terminal (VT) – is a conceptual combination of the keyboard and display for a computer user interface. It is a feature of some Unix-like operating systems such as BSD, Linux, illumos and UnixWare in which the system console of the computer can be used to switch between multiple virtual consoles to access unrelated user interfaces.
Traditionally that is false. Some distro releases started using tty1 some years back, but others continued and continue to default to tty7, reserving 1-6 for the ttys. Fedora and GDM/Gnome may have started the switch to tty1 from tty7 as a part of the process of eradication of dastardly () flicker caused by mode switching during init. Some others followed suit, while the rest did and have not. My Fedoras are all on tty7, because I've conformed all my installations to the tty1 tradition, and none use GDM, Gnome or Wayland.
My guess is that the gdm-x-session and gdm-wayland-session processes are simply grabbing the controlling terminal in order to signify that the specific virtual console is in use and prevent anything else from using it, essentially saying "TTY2 is mine. Hands off!".
I have no idea whether it is necessary, but it seems like a sensible thing to do regardless. Why would you not want this to happen?
On my slackware box, non-systemd and using xdm, it looks like this:
As you can see, the Xorg server process itself is the only thing holding the controlling tty of vt7. Clearly gdm is doing it slightly differently on fedora. I've no idea why, I'm an old-school kind of guy as you can probably guess from the process list above.
@GazL Seeing the output of the ps command, with the job control and process parenthood views, on a different kind of system certainly helps, although there is still lack of clarification regarding the questions I've had in my mind (asked in the first post). You see, it's not that I want it or not, but rather I don't know why it is done the way it is done, whether there are alternatives or not, and what would be the outcomes.
PS: When you said oldscool, it reminded me of a yt channel I've recently come across: DJ Ware. I certainly recommend it by the way (No relation with the channel).
I'll check that channel out sometime, thanks for the tip.
As for the "why". The only clue I can see is this from the Xorg man page:
Code:
-keeptty
Prevent the server from detaching its initial controlling
terminal. If you want to use systemd-logind integration
you must specify this option.
Not all platforms support (or can use) this option.
So, it seems it's something to do with the way systemd-logind does its stuff. The systemd guys have a history of repurposing things that were originally intended for one job in order to do something else. Maybe your answer lies somewhere in the logind documentation, but this is where I get off this crazy train. I don't do systemd!
Traditionally that is false. Some distro releases started using tty1 some years back, but others continued and continue to default to tty7, reserving 1-6 for the ttys.
Actually, my Slackware uses both: tty1 for the startup etc and tty7 as the "graphical" one, so ctrl-alt-F7 switches TO it. Slackware normally only runs a getty on tty6, so none of the other tty's will display a login prompt.
The startup script for the display manager contains
Code:
# Tell the viewers what's going to happen...
echo "Starting up X11 session manager..."
This echo will be displayed on tty1
Code:
# These are the standard console login getties in multiuser mode:
c1:1235:respawn:/sbin/agetty --noclear 38400 tty1 linux
c2:1235:respawn:/sbin/agetty 38400 tty2 linux
c3:1235:respawn:/sbin/agetty 38400 tty3 linux
c4:1235:respawn:/sbin/agetty 38400 tty4 linux
c5:1235:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux
Actually, my Slackware uses both: tty1 for the startup etc and tty7 as the "graphical" one, so ctrl-alt-F7 switches TO it.
That's how it used to be everywhere, init messages on tty1, switch to tty7 on GUI startup. Switching from 1-6 framebuffer to 7, 8 or 9 GUI only requires Alt-Fn. Switching from whichever tty carries GUI requires Ctrl-Alt-Fn. Systemd makes it so that if startx is used from any of the ttys instead of a DM running on 7, that the GUI stays on the tty it was started from.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
) flicker caused by mode switching during init. Some others followed suit, while the rest did and have not. My Fedoras are all on tty7, because I've conformed all my installations to the tty1 tradition, and none use GDM, Gnome or Wayland.
