Description of problem: When selecting the "Xorg" session type (the second section in the server xrdp.ini file), the screen is painted in a single color (e.g. black, turquoise, something) but is otherwise unresponsive. Version-Release number of selected component (if applicable): xrdp-0.9.2-10.fc25.x86_64 How reproducible: totally Steps to Reproduce: See description. Additional info: 1) Tailing /var/log/xrdp.log shows slowly accumulating errors (see below) $ tail -f xrdp.log [20170514-22:30:13] [DEBUG] xrdp_wm_log_msg: connecting to sesman ip 127.0.0.1 port 3350 [20170514-22:30:13] [INFO ] xrdp_wm_log_msg: sesman connect ok [20170514-22:30:13] [DEBUG] xrdp_wm_log_msg: sending login info to session manager, please wait... [20170514-22:30:13] [DEBUG] return value from xrdp_mm_connect 0 [20170514-22:30:16] [INFO ] xrdp_wm_log_msg: login successful for display 26 [20170514-22:30:16] [DEBUG] xrdp_wm_log_msg: started connecting [20170514-22:30:19] [DEBUG] Closed socket 19 (AF_UNIX) [20170514-22:30:23] [DEBUG] Closed socket 19 (AF_UNIX) [20170514-22:30:26] [DEBUG] Closed socket 19 (AF_UNIX) [20170514-22:30:30] [DEBUG] Closed socket 19 (AF_UNIX) [20170514-22:30:33] [DEBUG] Closed socket 19 (AF_UNIX) [20170514-22:30:37] [DEBUG] Closed socket 19 (AF_UNIX) [20170514-22:30:40] [DEBUG] Closed socket 19 (AF_UNIX) [20170514-22:30:44] [DEBUG] Closed socket 19 (AF_UNIX) ... 2) /var/log/messages shows $ tail -f messages May 14 22:30:26 hpc16 xrdp-sesman: [20170514-22:30:26] [CORE ] main: app started pid 17388(0x000043ec) May 14 22:30:26 hpc16 xrdp-sesman: [20170514-22:30:26] [INFO ] main: DISPLAY env var set to :26.0 May 14 22:30:26 hpc16 xrdp-sesman: [20170514-22:30:26] [INFO ] main: using DISPLAY 26 May 14 22:30:26 hpc16 xrdp-sesman: [20170514-22:30:26] [INFO ] channel_thread_loop: thread start May 14 22:30:26 hpc16 xrdp-sesman: [20170514-22:30:26] [INFO ] term_signal_handler: got signal 15 May 14 22:30:26 hpc16 xrdp-sesman: [20170514-22:30:26] [INFO ] channel_thread_loop: g_term_event set May 14 22:30:26 hpc16 xrdp-sesman: xrdp-chansrv [0166807487]: scard_deinit: May 14 22:30:26 hpc16 xrdp-sesman: chansrv:smartcard_pcsc [0166807487]: scard_pcsc_deinit: May 14 22:30:26 hpc16 xrdp-sesman: [20170514-22:30:26] [INFO ] channel_thread_loop: thread stop May 14 22:30:26 hpc16 xrdp-sesman: [20170514-22:30:26] [INFO ] main: app exiting pid 17388(0x000043ec) 3) Actually (just noticed while typing up this ticket) something does happen, we eventually get a session startup error message which when dismissed shows us the login session chooser where we can try again. It just takes a LONG time to get there and I never waited that long. At this point in /var/log/xrdp.log we see: [20170514-22:38:17] [DEBUG] Closed socket 8 (AF_INET 127.0.0.1:3350) [20170514-22:38:17] [DEBUG] Closed socket 7 (AF_INET 127.0.0.1:3350) [20170514-22:38:17] [DEBUG] Closed socket 8 (AF_INET 127.0.0.1:3350) [20170514-22:38:17] [INFO ] setpriv --no-new-privs Xorg :27 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log [20170514-22:38:27] [ERROR] X server for display 27 startup timeout [20170514-22:38:27] [CORE ] waiting for window manager (pid 18193) to exit [20170514-22:38:27] [ERROR] X server for display 27 startup timeout [20170514-22:38:27] [ERROR] another Xserver might already be active on display 27 - see log [20170514-22:38:27] [DEBUG] aborting connection... [20170514-22:38:27] [CORE ] window manager (pid 18193) did exit, cleaning up session [20170514-22:38:27] [INFO ] ++ terminated session: username cb, display :27.0, session_pid 18192, ip 192.168.20.65:20456 - socket: 12 Sadly, I cannot locate any logfile :-( 4) Lastly, totally as an aside, I see a whole bunch of commented out session sections. Are these long obsolete, for some different OS, really useful? Is there some place where the details and current status of these sections is documented? For example when I google "libxup.so" I tend to get hits from 2002! Lastly, I certainly appreciate your good work. XRDP is a GREAT tool.
Do you have SELinux enabled? If so, is xrdp-selinux package installed? The log file will generally be in the home directory for xorgxrdp.
The system has SELINUX=Permissive. I'll take another look for the log files when I get home.
Okay, I've figured out the problem(s), and a temporary workaround. 1) There is no logfile. Instead /bin/Xorg is launching Xorg.wrapper which outputs an error message and quits. It never launches the /usr/libexec/Xorg and so the -logfile argument is never used. 2) The Xorg error message is "/usr/libexec/Xorg.wrap: Only console users are allowed to run the X server". So apparently Xorg.wrap is enforcing an access control policy. However (as discussed below) my user CAN login to the console. 3) Workaround: create /etc/X11/Xwrapper.config and add the following line: allowed_users = anybody. On my system (Fedora-25) there is no Xwrapper.config and apparently the default behavior is as if "allowed_users = console" was specified. I have no idea how Xorg.wrap is making this determination. In point of fact, the account I am using IS able to login to the console, although it is NOT a local account but rather an Active Directory account. I modified /etc/sssd/sssd.conf to allow that AD account to login via the console, SSH, etc.
Caution - I have TWO similar Fedora-25 systems. The original problem was reported on my HOME system, which is NOT joined to a domain. Today I was able to reproduce what SEEMS to be the same problem on my WORK machine which IS joined to a domain. The analysis and workaround reported in Comment 3 above is from my WORK (domain) machine. Tonight I'll see if the problem and workaround are the same on my HOME (non-domain) machine and report my findings. Lastly, I now have access to 2 different session types: Xvnc and Xorg. Where can I go to figure out the PROs and CONs of the two session types? This is a subset of my earlier more general question about the current status of the commented out sections (i.e. are they useful, are they really old obsolete stuff, or what? Also what do some of the more obscure options mean - such as "code", etc). Any insight you can offer (such as a pointer to some wiki) would be appreciated.
(In reply to Charles Butterfield from comment #3) > 3) Workaround: create /etc/X11/Xwrapper.config and add the following line: > allowed_users = anybody. This is documented in /usr/share/doc/xrdp/README.Fedora.
(In reply to Charles Butterfield from comment #4) > Lastly, I now have access to 2 different session types: Xvnc and Xorg. > Where can I go to figure out the PROs and CONs of the two session types? > This is a subset of my earlier more general question about the current > status of the commented out sections (i.e. are they useful, are they really > old obsolete stuff, or what? Also what do some of the more obscure options > mean - such as "code", etc). Any insight you can offer (such as a pointer > to some wiki) would be appreciated. Xorg is a new thing and not yet overly mature. It is supposed to be better in the long run, because it supports dynamic resizing etc. I found it a bit rough around the edges (the pointer seems to be lagging), so YMMV. Xvnc is the old and "proven" thing.
1) Yes, I see now. Sorry, I didn't think to look there (/usr/share/doc). I was focusing on the man page and the config files themselves. 2) Thanks for the info about Xorg vs Xvnc. 3) In my earlier comments I assumed that "console" meant "authorized to login to the console" rather that "currently logged into the console". The later seems really odd. That confusion was why I was thinking domain vs non-domain was relevant. I see now that it is not. 4) The default behavior of Xorg w.r.t. requiring the user to be CURRENTLY logged into the console seems so odd (and counter productive) that I'm thinking of filing a bug report about it to the Xorg group. Does that seem to make sense to you? Surely this must affect any software that wants to create a virtual framebuffer using Xorg software.
(In reply to Charles Butterfield from comment #7) > 4) The default behavior of Xorg w.r.t. requiring the user to be CURRENTLY > logged into the console seems so odd (and counter productive) that I'm > thinking of filing a bug report about it to the Xorg group. Does that seem > to make sense to you? Surely this must affect any software that wants to > create a virtual framebuffer using Xorg software. I guess the intention (from reading the manual page) was to distinguish between users with physical access to the system and the ones without. As such, I guess it works as expected. Now, whether that's a bug, I honestly have no idea...
FYI - I just created the related https://bugzilla.redhat.com/show_bug.cgi?id=1451518 assigned to "xorg-x11-server" inquiring about changing the default from "allowed_users=console" to "allowed_users=anybody". Not sure what their posture will be, but it would seem to make sense to "fix" the issue at the source (unless the fix is inherently dangerous) rather than in each package that uses a virtual framebuffer, or worse, by each user of a virtual framebuffer.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.