This has piqued my curiosity, and I always want to learn.
I noticed that there was a bit of a lag launching konsole, so as a test I tried launching it from a terminal. This resulted in a message:
Qt: Session management error: Could not open network socket
As another test, I unset the $SESSION_MANAGER environment variable, which got rid of the error when I launched konsole, and this time it appeared without any delay.
There seems to be a socket where $SESSION_MANAGER is pointing. So in principle I can’t see any reason why it can’t be opened.
So I’m wondering what this socket is actually used for? And would I break anything if I were to unset $SESSION_MANAGER globally? (Perhaps I would speed everything else up?)
GNU/Linux is a UNIX system, and UNIX was conceived as a multi-user server/client architecture. The oldest UNIX machines were so-called minicomputers — smaller than a mainframe, but still taking up a whole wall in a large room — and the operators interacted with the system by way of terminal consoles. In the earliest years, these were teletype machines, but later on, so-called “glass terminals” were used instead. And there were many different types of those.
Even though the Linux kernel was first developed on a personal computer — an HP Vectra with an Intel 386 processor — it still follows the principles of UNIX, in that you need a terminal in order to interact with the system. However, considering that personal computers essentially have their console connected directly to the motherboard via the I/O panel at the back of the chassis, Linux includes a hardware console implemented as software within the kernel itself.
The X Window System was designed as a networked user interface, so that applications could be running on one computer but have their output displayed on the screen of another computer — commonly a graphical workstation as a precursor to the thin clients in use at certain venues today.
Given that you are trying to connect to the underlying operating system by way of a terminal window in a graphical environment, your terminal window is therefore conceived as a terminal emulator — the correct name is pseudo-terminal slave — and thus it needs to connect to the underlying system via a UNIX domain socket, which is a file that acts as a sink for interprocess communicaton in the same way as a socket for network traffic. It is not a tty based upon the kernel’s in-built console.
Try logging into a tty, and then type the command…
tty
It will echo something back in the form of…
/dev/tty3
Now, type the same command in a konsole window, and you’ll get something back like…
Thanks for a comprehensive reply (though as an old Unix hand I had a good background in it anyway).
But what you say about the terminal emulator needing to connect via the domain socket seems to suggest that konsole shouldn’t work if it can’t connect to that socket, which it seems not to be doing. Puzzling…
If you delete the socket while it’s in use, it will continue to exist without a filename, because there will still be a file descriptor holding the extents/blocks open.
If you delete it while it’s not in use, then it’ll get recreated on the fly when needed. It’s a temporary file in /tmp, and therefore the system knows that its existence is not expected to persist across reboots.
These are the sockets in use on my machine right now…
