Can you explain the following lines in the netstat output?

Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags       Type       State         I-Node   Path

unix  2      [ ]         STREAM     CONNECTED     37133819 /tmp/.lxterminal-socket:0-xralf
unix  2      [ ]         STREAM     CONNECTED     37109191 /tmp/.lxterminal-socket:0-xralf

1 Answer 1


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


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 /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.)


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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .