client-server GUI programs
Like several other GUI programs nowadays, since 2008 lxterminal
has attempted to display all terminal emulator windows from a single process, one per X display per user. To do this, it attempts to connect to an existing socket by the sort of name that you are seeing, that incorporates the display name and your user name.
- If the connection succeeds, it simply dumps its current directory and argument vector down the socket and exits. It does not use file descriptor passing to pass along an open file descriptor to its current directory directly, but passes it by name.
- If the connection fails, it attempts to itself become the listening server on that socket. It reads messages comprising a current directory and an argument vector, and opens up a new GUI terminal emulation window for each read, as if it were its own current directory and argument vector.
The visible effect of this is that the first lxterminal
program that you invoke (and leave running) operates synchronously, whereas the second and subsequent ones do not. To observe this, start with no lxterminal
instances running, run a different terminal emulator, and invoke
lxterminal & sleep 1 ; lxterminal
from a shell. The shell will return to the prompt after 1 second, and show only 1
lxterminal
job left running.
rxvt has a similar capability, but one has to explicitly invoke the urxvtd
server, and explicitly run the urxvtc
client. Running plain urxvt
does not attempt any client-server shenanighans.
GNOME Terminal only works this way, in contrast. It always passes the argument vector over to a server process and then exits. There is, moreover, just the one server process per user, handling all displays (and bugs in the way that this mechanism initializes, to boot).
insecurity
The creation of files and sockets in /tmp
with predictable names is a well-known security concern, and lxterminal
shares it. Users can pre-create sockets in the predictable places that lxterminal
s run by other users on the same machine will attempt to talk to.
rxvt, in contrast, uses a non-group-writable non-other-writable subdirectory of each user's home directory. Another possibility for fixing this problem with lxterminal
that equally would not allow other users the access to replace one's sockets with theirs would be having the sockets in /run/user/username/lxterminal
.
(GNOME Terminal uses the user-level Desktop Bus to communicate between clients and its server. Nowadays the AF_LOCAL
socket for that lives in /run/user/username/
where it cannot be supplanted by other unprivileged users.)
bugs
One of the problems that has plagued GNOME Terminal is that it takes up a lot of open file descriptors in the single server process for each instance of a terminal emulation. It used to be 16; and is now down to a "mere" 8.
lxterminal
uses 2, one of which is a leaked open file descriptor for the socket connection from the client process. Open and close enough terminal emulations, and eventually lxterminal
will run out of available file descriptors. The following, starting with no lxterminal
instances running, used up all of the server's available file descriptors in just over a minute on one of my machines:
(ulimit -H -n 1024 ; lxterminal) &
seq 0 1024 | while read -r i ; do lxterminal -e /usr/bin/true ; done
Further reading