In a Debian-based GNU/Linux environment, it is natural to want GUI access not only from the physical screen in front of the machine but also from another device. It is not unusual to work on the local screen in ordinary use while checking status from a notebook PC in another room, or performing maintenance only from a separate client. One common candidate in that situation is xrdp. xrdp is an implementation that accepts RDP connections on the Linux side, and serves as an entry point for GUI access from Windows Remote Desktop Connection or various other RDP clients [1].
However, when trying to use both the local GUI and a remote GUI on the same system after introducing xrdp, a familiar class of instability often appears: authentication seems to succeed, yet the session falls into a black screen; the connection is dropped immediately after login; a configuration works under one condition but fails under another. If this is dismissed only as “bad configuration,” “a heavy DE,” or “an old GPU,” the same problem tends to recur. This article does not treat such behavior as an isolated anecdote. Instead, it organizes the issue as a structural property of Linux GUI sessions, which are built from multiple interacting layers, and then derives a design judgment from that structure.
The reason this topic becomes confusing is that the Linux GUI is not a monolithic stack in the way many people casually imagine Windows or macOS. A single GUI experience emerges only after multiple components overlap: the display server, the window manager, the desktop environment, session management, inter-process communication, and authentication state. Once this is understood, phenomena such as “it turned into a black screen,” “it returned to the login prompt immediately,” or “it works locally but breaks remotely” can no longer be reduced to a vague claim that the environment is simply “heavy” or “unstable.” What is needed is to line up the observed behavior, understand the structure behind it, and then decide what unit of separation should be used in the design.
The conclusion can be summarized in advance. First, xrdp is not usually a mechanism that shares the existing local screen as it is; it normally creates a new GUI session [1][2]. Second, when the same user tries to use a local GUI and an xrdp GUI at the same time, shared user-space state such as D-Bus, the systemd user session, Xauthority, session restoration, and autostart behavior can conflict [3][4][5][6][7]. Third, installing multiple desktop environments does not remove the core of that conflict. If stable concurrent use is the requirement, the effective unit of separation is not the desktop environment but the user account.
| Conclusion | Point |
|---|---|
| The nature of xrdp | xrdp usually creates a new GUI session and presents it over RDP |
| The core source of instability | When multiple GUI sessions exist for the same user, shared user-space state can conflict |
| Design judgment | If concurrent use must be stable, separating users is more fundamental than switching desktop environments |
1. Establish the terms first
This topic becomes confused very quickly if the terminology remains vague. It is therefore necessary to align the basic vocabulary first. GUI stands for Graphical User Interface and refers to a style of operation centered on screens, windows, menus, and pointer interaction, in contrast to the text-oriented CLI. DE stands for Desktop Environment. It is not the name of a single program, but a bundle of components that together form a GUI working environment: panels, file managers, settings tools, session management, and related elements. Xfce and GNOME Flashback are both examples of desktop environments [8][9][10][11].
The display server is the foundation that handles screen drawing and input event delivery; in X11-based environments, Xorg is the representative example. The window manager is the component that manages window frames, movement, maximization, minimization, and stacking order. Sometimes it is embedded inside a desktop environment, and sometimes it is used independently. The word session is also critical here. In this article it does not mean only “being logged in,” but a full execution context that includes authentication, environment variables, process groups, the session bus, and restored state. To understand xrdp is therefore not merely to know that an RDP connection can be established. It is to understand how these components layer together to form a session.
| Term | Meaning |
|---|---|
| GUI | A visual interaction model based on screens, windows, and pointing devices |
| CLI | A text-based interaction model using typed commands |
| DE | A desktop environment: a GUI suite including panels, settings tools, and session management |
| Display server | The foundation for screen drawing and input handling, such as Xorg or Wayland |
| Window manager | The component that manages window placement, decoration, and window operations |
| Session | The execution context started after user authentication, whether GUI or CLI |
| xrdp | A server-side implementation for accepting RDP connections on Linux |
2. The question here is not “which DE is lighter”
If the issue is summarized too roughly, it seems to become a simple DE comparison: whether Xfce is lighter for xrdp, or whether GNOME Flashback is easier to handle. But that is not the real question. The real problem is this: in a Debian-based Linux environment, GUI operation is needed locally, GUI access is also wanted through xrdp, the local GUI should remain usable, and ideally the local and remote GUIs should be usable at the same time. Under those conditions, what configuration is the most coherent?
The critical point is that once one assumes “xrdp merely shows the local screen,” all subsequent reasoning becomes distorted. If xrdp were simply local screen sharing, the problem would look like nothing more than a question of bandwidth or rendering load. In reality, xrdp normally establishes a new GUI session. The relationship between local and remote is therefore not “the same screen seen by a different route,” but “a second GUI session may be created for the same user.” Unless that premise is fixed first, later phenomena such as black screens or login loops cannot be explained properly.
| Issue | Importance | Reason |
|---|---|---|
| Which DE is the lightest | Medium | It matters for choosing a remote desktop environment, but it does not determine the core of the problem |
| Whether xrdp is local screen sharing or new session creation | Critical | If this is misunderstood, the conflict structure of concurrent use cannot be understood |
| Whether local and remote use the same user | Critical | This determines the scope of shared state |
| Whether local and remote use different DEs | Secondary | This changes the UI layer but does not eliminate shared user-space state |
3. Why do the observed symptoms fluctuate depending on conditions?
What stands out first in practice is the behavior seen when an xrdp connection is made to a machine while a local GUI session is already open under the same account: a black screen after authentication, immediate disconnection after login, or the strange pattern where the same setup works once and then fails after a reboot or under a different order of operations. What matters here is that this can happen even on systems with ample CPU and memory resources [3]. It is therefore premature to conclude that the cause is simply “a heavy DE” or “an old GPU.” In actual xrdp operations, black screens and session creation failures are widely associated with inconsistencies in startup and session initialization [3].
This kind of issue also cannot be evaluated by saying “it worked once.” A pattern in which one day everything works and the next day it fails points less to an obvious typo in a configuration file and more to a shared-state problem dependent on startup order and residual state. In other words, the core of the instability lies not primarily in rendering performance, but in the order in which sessions come up, what they share, and what they inherit. Once that is recognized, the problem is no longer seen as “xrdp is unstable software,” but as “multiple GUI contexts under the same user tend to produce condition-dependent oscillation.”
| Observed symptom | Superficial interpretation | More plausible reading |
|---|---|---|
| Black screen after authentication | The display is too heavy or the GPU is too weak | The GUI session likely failed to complete initialization |
| Disconnection immediately after login | The password or permissions are wrong | The xrdp-side session likely failed and exited during creation |
| The same settings sometimes work and sometimes fail | The system is just unstable | The problem is likely shared state dependent on startup order and residual context |
4. xrdp is not “current screen sharing” but “new GUI session creation”
The first key to understanding this issue is not to equate xrdp with a VNC-style sharing of the currently visible screen. xrdp usually accepts a connection request, passes it through sesman, establishes a new session, launches an Xorg-based backend for that session, and then presents that screen to the RDP client [1][2]. The xorgxrdp project itself makes clear that it is an additional module for running the X.Org side for xrdp use [2]. The remote side is therefore not simply peeking at the already existing local screen. It is a separate GUI context.
If this one point is misunderstood, every later part of the analysis shifts in the wrong direction. If one imagines that the same local desktop is merely being streamed remotely, then the problem appears reducible to network bandwidth or rendering overhead. In reality, when the same user is already logged in locally and then connects through xrdp, a second GUI session may be created for that user. Only at that point does the question “why does concurrent use under the same user become unstable?” take on a precise technical shape.
| Item | What xrdp actually does | Common misunderstanding |
|---|---|---|
| Meaning of the connection | Creates a new GUI session and displays it over RDP | |
| Relationship to the local session | It can coexist as a separate session | |
| Where the problem starts | The same user can end up with multiple GUI sessions |
5. What is a GUI session made of?
The next step is to decompose what a GUI session actually is. A GUI session is not merely a window being drawn somewhere. At minimum it involves Xorg as the display target, D-Bus as the communication substrate for desktop components and applications, systemd-logind and pam_systemd as the layer managing login context and user services, xauth as the holder of X server authentication credentials, and the desktop environment’s own mechanisms for session restoration and autostart [4][5][6][7][12].
D-Bus is not merely an auxiliary convenience. As the freedesktop.org specification makes clear, D-Bus is a foundational mechanism not only for communication between applications but also for coordination between services and processes [4]. systemd-logind tracks users and sessions and can spawn a user@.service instance for each user. pam_systemd collaborates with systemd-logind at login time to register the session [5][6][7]. xauth manages authentication data for connections to the X server [13]. The Xfce session manager, meanwhile, officially documents its role in saving previous state, restoring it, and handling autostart behavior [9][10].
A GUI session is therefore not one process but an execution context formed by multiple layers that assume one another. When two GUI sessions exist under the same user, stability depends on which layers are shared and which are separated.
| Layer | Role | Why it matters here |
|---|---|---|
| Xorg | Provides the drawing target for applications | The remote side requires a separate display context |
| D-Bus | Mediates communication between desktop components and applications | GUI initialization and service coordination depend on it |
| systemd-logind / pam_systemd | Manage the login context and per-user service space | Shared state easily appears when the same user has two GUI sessions |
| xauth | Holds authentication information for X server connections | If display alignment breaks, GUI startup becomes unstable |
| DE session management | Saves and restores prior state and handles autostart | Its assumptions often collide when two GUI sessions are active |
6. The real shared state is not the DE but the user space
Once the observations above are assembled, it becomes clear that the center of the conflict is not primarily the visual layer or the rendering pipeline itself, but the session bus, the user service space, authentication credentials, and restored session state tied to the user. Put differently, the core question is less “which desktop environment is in use?” than “which user space is shared?”
If the same user enters both local and remote sessions, several kinds of conflict can appear. The remote desktop environment may fail to bind to the D-Bus context it expects. Restored state saved by one session may collide with the assumptions of the other. Display authentication alignment may break. The startup order of user services may become unintentionally entangled. The exact failure pattern differs by environment, but the structural understanding remains the same: the core problem is conflict in state shared at the user level.
This understanding is decisive, because it becomes the criterion for evaluating later ideas such as “would multiple desktop environments solve it?” If the essential problem were the visual layer itself, then switching desktop environments might solve it. But if the real problem lies in shared user-space state, then changing the desktop environment does not reach the root cause.
| What tends to be shared | Content | How the conflict appears |
|---|---|---|
| D-Bus context | The message-transport foundation used by desktop components and applications | It can contribute to startup failure, incomplete initialization, and black screens |
| User service space | The set of per-user services managed by systemd | It becomes unclear which session is effectively in control |
| X authentication data | Per-display authentication credentials | Misaligned display/authentication state makes startup unstable |
| Session persistence data | Saved state, autostart settings, and restoration metadata | Two GUI sessions make hidden assumption mismatches surface |
7. Xfce is a strong candidate, but not a complete answer for concurrent use under one user
It is reasonable that Xfce is repeatedly proposed as a desktop environment for xrdp. The official documentation explains that Xfce is launched through startxfce4 and that its session manager handles application startup and session persistence [8][9][10]. In general, Xfce is comparatively simple in structure, examples of xrdp-based use are abundant, and it is easy to adopt as the remote-side DE. In many cases it is indeed easier to handle than a compositor-heavy environment such as GNOME Shell.
What must be emphasized, however, is that choosing Xfce is not the same thing as guaranteeing stable concurrent use for the same user. It is possible to reduce visible instability through measures such as explicitly initializing D-Bus, disabling session saving, or turning off compositing. But these measures do not separate the shared state. They only reduce the likelihood that the conflict becomes visible. Xfce is therefore a strong practical candidate, but it cannot honestly be described as a principled guarantee that concurrent local and remote GUI use by the same user will always be stable.
If this distinction is ignored, discussion easily falls into a simple exchange of experience-based claims such as “Xfce works” or “Flashback works.” But such experience proves only that in a particular environment, shared-state collisions did not become prominent enough to cause failure. If the goal is to choose a sound design, the standard should be not whether some success cases exist, but whether the configuration can explain both why it succeeds and where it can fail.
| Evaluation item | Position of Xfce |
|---|---|
| Compatibility with xrdp | Relatively easy to handle and a strong candidate |
| Simplicity of configuration | High; it is comparatively easy to understand and has fewer configuration points |
| Complete guarantee for concurrent use under the same user | No; shared-state conflict remains a separate issue |
8. Using GNOME Flashback locally does not usually solve the problem at its root
GNOME Flashback is lighter than GNOME Shell and is based on a more classical X11-oriented composition, so it can work perfectly well as a local desktop environment [11][14]. It is therefore natural to think of using GNOME Flashback locally while assigning Xfce to the remote side. The appearance and operational feel can be separated, and at first glance that may look like conflict avoidance.
But what changes in such a setup is mainly the UI layer, not the user space. D-Bus, the user session, xauth, and related state remain shared as long as the same user account is used. A multi-DE configuration may be valid as a division of roles, but it does not directly address the real core of the present problem. It can even increase the number of variables: more settings tools, more dependencies, more startup paths, and more uncertainty about which settings affect the local side and which affect the remote side.
In short, installing multiple desktop environments can help provide different appearances and usage roles, but that is not the same thing as structurally separating conflicting state. Apparent division of labor and actual structural separation are not identical.
| Configuration | Visible advantage | Technical problem that remains |
|---|---|---|
| Same user + Xfce only | One setting lineage, easier to understand | Shared-state conflict during concurrent use remains |
| Same user + Flashback/Xfce split | The UI can be divided by role | Shared-state conflict remains, while variables increase |
9. Separate the evaluation axes: simplicity of configuration and separation of shared state
One reason this discussion tends to loop is that “simplicity of configuration” and “the ability to avoid conflict in principle” are easily mistaken for the same thing. In this problem they are different axes. The same-user, single-DE arrangement is superficially very simple: one home directory, one family of configuration files, one user context. That is true. But that simplicity is inseparable from the fact that the same user space is being shared between local and remote sessions.
In contrast, the separate-user approach increases the number of visible administrative elements because home directories and configuration files are split. But in exchange, D-Bus, the user session, authentication state, and session-persistence metadata are naturally separated by the user boundary. The visible management burden increases somewhat, while the hidden conflict structure decreases. The present design decision is therefore not a question of preference but of what layer should be chosen as the separation unit.
| Evaluation axis | Same-user model | Separate-user model |
|---|---|---|
| Superficial simplicity | High | Medium |
| Separation of user space | Weak | Strong |
| Explainability under concurrent use | Tends to be low | Tends to be high |
10. If concurrent use is not required, the same-user single-DE model is entirely rational
If one relaxes the condition slightly, the conclusion changes. If the actual requirement is “do not use the local GUI and the remote GUI at the same time,” then the same-user plus Xfce-only configuration is entirely rational. If the local GUI session is ended before entering remotely, then the condition that creates the conflict—the same user holding two GUI sessions—never arises. In that case minimal configuration and stable behavior become largely aligned.
This means that the same-user plus Xfce-only model is not always wrong. It becomes problematic only when concurrent use is strongly required and a complete guarantee is nevertheless expected from that arrangement. Once the conditions change, the optimal answer changes as well. Unless this is stated explicitly, discussion easily turns into a false disagreement between “Xfce alone is enough” and “a separate user is necessary,” even though the two positions are answering different conditions.
| Condition | Most coherent configuration | Reason |
|---|---|---|
| No concurrent use | Same user + Xfce only | It avoids the conflict condition and keeps the configuration minimal |
| Concurrent use required | A stronger separation strategy is needed | Shared-state conflict must be minimized |
11. If concurrent use is truly required, the separation unit should be the user, not the DE
From the observations and structural analysis above, the design judgment becomes fairly clear. If the requirements are “the local GUI and the xrdp GUI must be usable at the same time,” “a VNC-style existing-screen-sharing approach is not being adopted,” and “high reproducibility and stability are desired,” then the unit that should be separated is not the desktop environment but the user. The reason is straightforward: the major sources of conflict all belong to user space.
In that design, one might prepare a normal local-use account and a separate xrdp account for remote use. There is no need to multiply desktop environments unnecessarily; both sides can even be unified on a comparatively simple environment such as Xfce. In that case, the original problem setting—a single user running two GUI sessions at once—disappears. The home directories and configuration trees become separate, but that separation is intentional and directly aligned with the aim of avoiding shared-state conflict. The resulting behavior is therefore easier to explain.
The advantage of the separate-user model is not limited to stabilizing concurrent use. A dedicated remote account also acts as an emergency login path. If the ordinary user breaks the GUI configuration, or if session restoration and autostart settings make the normal login path unstable, it remains possible to enter through another user space and repair or isolate the broken settings. This is not merely a convenience feature. It is a recovery-oriented design.
| Model | Separation unit | Effect on the present problem | Recovery path |
|---|---|---|---|
| Same user + single DE | No separation | The configuration is simple, but it does not reach a full guarantee for concurrent use | Weak |
| Same user + multiple DEs | Only the UI layer is separated | It does not fundamentally address shared-state conflict | Weak |
| Separate users + single DE | User space is separated | It directly addresses the conflict structure described in this article | Strong |
12. Final summary
The argument of this article can now be restated compactly. xrdp is not usually a mechanism for sharing the local screen as it is; it normally creates a new GUI session [1][2]. Accordingly, when the same user attempts to use a local GUI and an xrdp GUI at the same time, user-level state such as D-Bus, the systemd user session, xauth, and desktop-environment session handling can conflict [4][5][6][7][13]. The core of the problem therefore cannot be explained only by the appearance of the DE or the rendering load.
Xfce is a strong candidate for the xrdp-side desktop environment, and if concurrent use is not required, an Xfce-only model for the same user is fully reasonable [8][9][10]. By contrast, a multiple-DE arrangement such as GNOME Flashback locally and Xfce remotely may divide roles at the UI layer, but it does not remove shared user-space state and therefore tends not to be a fundamental answer [11][14]. For the condition set treated here—simultaneous local and xrdp GUI use, no existing-screen-sharing model, and a desire for the highest practical stability—the most coherent design is to prepare a separate user for remote access, avoid multiplying desktop environments unnecessarily, and keep the overall environment comparatively simple.
| Configuration | Concurrent use | Stability | Simplicity | Emergency recovery path | Overall judgment |
|---|---|---|---|---|---|
| Same user + Xfce only | Possible | Medium | High | Weak | Practical if strong concurrent use is not required |
| Same user + multiple DEs | Possible | Below medium | Low | Weak | It increases variables without achieving fundamental separation |
| Separate users + single DE | Possible | High | Medium | Strong | The most coherent option under the conditions examined here |
| Same user + non-concurrent operation | Not allowed | High | High | Medium | Excellent as a minimal configuration if simultaneous use is unnecessary |
References
- neutrinolabs/xrdp. https://github.com/neutrinolabs/xrdp
- neutrinolabs/xorgxrdp. https://github.com/neutrinolabs/xorgxrdp
- ArchWiki: xrdp. https://wiki.archlinux.org/title/Xrdp
- D-Bus Specification. https://dbus.freedesktop.org/doc/dbus-specification.html
- systemd-logind.service. https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html
- pam_systemd(8). https://man7.org/linux/man-pages/man8/pam_systemd.8.html
- user@.service(5). https://man7.org/linux/man-pages/man5/user%40.service.5.html
- Getting Started with Xfce. https://docs.xfce.org/xfce/getting-started
- xfce4-session – Session Manager. https://docs.xfce.org/xfce/xfce4-session/start
- xfce4-session – Preferences. https://docs.xfce.org/xfce/xfce4-session/preferences
- GNOME Flashback. https://gitlab.gnome.org/GNOME/gnome-flashback
- dbus. https://dbus.freedesktop.org/
- XAUTH(1) manual page. https://www.x.org/archive/X11R7.5/doc/man/man1/xauth.1.html
- GNOME Flashback wiki archive. https://wiki.gnome.org/Projects/GnomeFlashback