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