"error constructing proxy..." when trying to launch gnome-terminal as root

Question

openSUSE Leap 42.2 Gnome Terminal 3.20.2

I have a terminal window open. If I type the following command:

gnome-terminal

as a non-root user it successfully launches a new terminal.

However if I run the command as root I get the following error message:

Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: The connection is closed

If I try to launch the terminal with dbus-launch gnome-terminal then it works.

What is preventing the gnome-terminal command launching the terminal as root? And is dbus-launchan acceptable workaround or likely to cause unforeseen issues (I don't really understand what it is doing)?

Solution

Remember how Windows applications mainly worked back in the Win16 days before Win32 came along and did away with it: where there were hInstance and hPrevInstance, attempting to run a second instance of many applications simply handed things over to the first instance, and this made things difficult for command scripting tools (like Take Command) because one would invoke an application a second time, it would visibly be there on the screen as an added window, but as far as the command interpreter was concerned the child process that it had just run immediately exited?

Well GNOME has brought the Win16 behaviour back for Linux.

GNOME Terminal is now a client-server application. The gnome-terminal program is just a client that constructs Desktop Bus messages to a server, passing along its command line options, environment, working directory, and arguments, and then simply exiting. The server is gnome-terminal-server which registers as org.gnome.Terminal on the Desktop Bus and which is responsible for all of the actual terminal emulation and displaying the window(s) on the GUI(s).

A Desktop Bus client like gnome-terminal locates the Desktop Bus broker via an environment variable, which usually points to socket in a per-user directory such as /run/user/1001. Alternatively, the environment variable specifies to look in "the current user's runtime directory" and a path similar to the aforementioned is constructed from the client process's effective user ID. This directory in either case is conventionally private to the individual user, and inaccessible to other (unprivileged) users.

Hilarity ensues when people attempt to run gnome-terminal as another user via sudo and suchlike. If the environment variable points to an explicitly-named runtime directory, an unprivileged client cannot connect to the per-user Desktop Bus. If the environment variable points to "the current user's" runtime directory, it looks for the wrong Desktop Bus broker, often the one for a user that does not currently have a Desktop Bus broker running because the user has not logged in and started up that user account's per-user services. (Per-user Desktop Bus brokers are run by a per-user service manager. The per-user service manager is either started explicitly or, in the case of some service management softwares, by some rather ugly hooks into the user authentication process employed by the likes of the login, su, and SSH server programs.)

The reason that dbus-launch worked for you as the superuser is that dbus-launch explicitly launched another Desktop Bus broker, running as the superuser, which gnome-terminal was able to talk to. Luckily, the system was also configured to demand-start the gnome-terminal-server server when the client attempted to connect to it via the broker. (This is not necessarily the case, and nowadays such demand-starting is seen as an inferior mechanism as it ends up with lots of Desktop Bus server processes that aren't running under any kind of service management. Indeed, not having the broker itself under service management is considered inferior too. It's also generally not considered a good idea for the superuser account to have these sorts of services running, as many of them do not expect to be running with superuser privileges because they expect to be running under the aegides of ordinary user accounts.)

Further hilarity ensuses if, as the questioner at "How can I launch gnome-terminal remotely on my headless server? (fails to launch over X11 forwarding)" does, people attempt to run gnome-terminal when even the original user does not have a Desktop Bus broker running. This happens when, for example, one has logged in via SSH but the SSH login process does not start up the per-user service manager, which in turn means that the per-user Desktop Bus broker is not run, and the gnome-terminal-server server cannot be reached over a Desktop Bus. (According to how the system is configured, graphical login could still trigger starting the per-user service manager, and hence one might observe that logging in graphically as the same user magically makes things work. And again dbus-launch would explicitly start a non-service-managed Desktop Bus broker.)

Yet more hilarity ensues when one has one of the service managers that has the hooks into login, su, and the SSH server. These hooks usually implement the semantics of starting up per-user service management, and all of the per-user services that it starts, at first log-on for that user; and stopping them all at last log-off for that user. If one has a lot of short-lived and non-overlapping SSH sessions, then there can be a lot of overhead generated uselessly starting up and shutting down the entire per-user service management system (and all of its auto-start services) at the starts and ends of each of those SSH sessions. systemd, one such service manager, has an imperfect "linger" mechanism that only really half addresses this. It means that per-user service management "lingers" after the final log-off, but it does not stop the per-user service management from being started at all.

Further reading

• Jonathan de Boyne Pollard (2016). /run/user/jim/dbus. "Gazetteer". nosh Guide. Softwares. jdebp.eu.
• Jonathan de Boyne Pollard (2016). "per-user user services". nosh Guide. Softwares. jdebp.eu.
• Run true multiple process instances of gnome-terminal
• Make user systemd service persistent
• https://unix.stackexchange.com/a/323700/5132

Comments

[Jürgen A. Erhard]

Wonderful GNOME, how I freakin' hate you.

[Guillaume Boudreau]

I would like to note that dbus - the program implementing the "Desktop Bus broker" in the explanation above, isn't inherently a desktop bus - it is the same process managing the system's bus, in which case it is running with system permissions and is considered secure (which likely can't be said about gnome-terminal-server). I would generally consider a message bus a good thing and KDE makes very good use of it, while splitting a user application into a client/server architecture I would consider a bad thing and I would suggest looking at KDE's konsole as an alternative.