Description of problem: In an attempt to try out the ckremoval feature, removing CK causes a seat to not be created when using "exec startx" from a TTY when the window manager is not launched with ck-launch-session. Things such as PolicyKit deny based on Active checks when using the X session, but not from TTY logins. I see no documentation for what replaces ck-launch-session if there is one. Version-Release number of selected component (if applicable): systemd-44-2.fc18.x86_64
After installing CK again, ck-launch-session creates a session in ck-list-sessions, but PolicyKit still denies despite the current session being 'Active'.
startx cannot create a new session. Sessions are tied to the audit system. Once the session identifier is set for a process, it is immutable. See Lennart's explanation in http://lists.freedesktop.org/archives/systemd-devel/2012-February/004614.html If I understand the thread correctly, it's impossible to have support for startx anymore.
Could this be documented in systemd somewhere?
Actually, we can make this work. There was a discussion on irc a couple of weeks back about this. The proposed way to make this work is by changing startx to spawn X on the console tty it is started from. That way we don't create a new session with a new tty but rather (temporarily) upgrade the console session to an X session. This should be relatively easily be implementable: - startx should ensure to invoke X on the tty it is started on - X should be grab the input device so that no keypresses end up on both X and the shell. Note sure what the latest on this is. Tentatively teassigning to xorg-x11-xinit
That solution would be fine with me (I use "exec startx" to avoid the issue of being able to ^C startx by switching to the original TTY and getting a shell that way).
*** Bug 820675 has been marked as a duplicate of this bug. ***
Users are used to boot system without running X display - and run 'startx' at will when they need to start Xsession. Solution of running gdm and again login into something is not an option here - startx has it's big advantage in debugging many X problems and memory leaks, so there is big need to be able to run the X session from the terminal via simple command like startx. Is here any progress?
+1 for startx
Partial solution: $ tty /dev/tty1 $ startx -- vt01 After that loginctl reports session as active from xterm
Worked fine here, after that i'm able to suspend/hibernate on xfce4-power-manager.
Anyone willing to put that into a form of a patch for /usr/bin/startx ?
Created attachment 592704 [details] proposed patch for startx
(In reply to comment #11) > Anyone willing to put that into a form of a patch for /usr/bin/startx ? Attached, based at Tomi's solution. Fixes #820675 for me.
Scratch build with above patch: http://koji.fedoraproject.org/koji/taskinfo?taskID=4175585 That takes care of the startx part, but what about xinit?
(In reply to comment #14) This build includes just first part of patch ;)
Odd. I included all of it, but this package uses CPP to process the shell scripts so possibly something failed there. Will look as time permits.
Sorry for accidentally changing the component and assignee. Reverting this stupid JS bug.
this really ought to be commonbugs so i stop forgetting about it.
Why can't we just FIX the f***ing bug instead of documenting it? A patch has been available for 2½ MONTHS! See comment #12. Why the f*** is this bug still open???
(In reply to comment #19) There is the reason—some strange result of patched script processing (comment #16). One can use a simple alias or shell function until investigated. I put something like following in my .bashrc and use it instead of startx: stx() { local tty_num=$(tty | grep -oE '[0-9]+$') startx -- -logverbose 7 vt$tty_num &>/var/tmp/my_xorg.log }
(In reply to comment #19) > Why can't we just FIX the f***ing bug instead of documenting it? A patch has > been available for 2½ MONTHS! See comment #12. Why the f*** is this bug > still open??? Perhaps you should go talk a walk or have a nice cup of tea? Anyhow, 2 reasons: 1. The patch doesn't actually end up working if applied before building. I looked at it again last night for a few minutes but didn't see why it was just not including the code block in the startx script after cpp pass. I'll poke at it again as time permits. If someone else would like to, please feel free. 2. The patch fixes startx, but not xinit. xinit is in C and needs some coding. Please feel free to poke at that and attach a patch as well. If I can get the startx part working, I'd be happy to push that out and save the xinit part for later.
Created attachment 608214 [details] patch v2 (In reply to comment #21) > 1. The patch doesn't actually end up working if applied before building. Maybe I've found the reason. Please try a second patch. First one is for already processed file and cpp may fail at interpreting shell comments as its own directives.
Of course patching the already processed file doesn't work, it will be overwritten during the build.
(In reply to comment #23) > Of course patching the already processed file doesn't work, it will be > overwritten during the build. Just in case: the change there isn't a filename, it is the replacement of '#' with XCOMM macro.
*** Bug 857662 has been marked as a duplicate of this bug. ***
Finally got around to going back to look at this. ;) The problem with the patch is that it was adding the new block inside a #ifdef __APPLE__ block. ;) Fixed that. Scratch build at: http://koji.fedoraproject.org/koji/taskinfo?taskID=4541155 that appears to fix startx here. If some other folks could do a quick test on this and say it works for them I will push out an update. Note that it doesn't fix xinit. :)
(In reply to comment #26) I see just a F18 rpm there, is it ok to install it at F17 ?
Probably not, we need an F17 build.
f17 scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=4543610
(In reply to comment #29) > f17 scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=4543610 Fix works for me. Can reboot and mount USB flash from KDE, session is active in systemd-loginctl. F17 x64
Works OK here, too. F17 X86_64 Kernel 3.6.. Thanks! Robert Gadsdon
xorg-x11-xinit-1.3.2-7.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/xorg-x11-xinit-1.3.2-7.fc18
xorg-x11-xinit-1.3.2-7.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/xorg-x11-xinit-1.3.2-7.fc17
Package xorg-x11-xinit-1.3.2-7.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-xinit-1.3.2-7.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-15243/xorg-x11-xinit-1.3.2-7.fc18 then log in and leave karma (feedback).
As I already noted to the bodhi, the patch breaks "startx&exit" use case. Result is X server cannot handle keyboard input. That's because you have introduced race by pinning X to VT which disappeared in the mean time.
Well, other solutions welcome. ;( I just wanted to fix the common case here to stop the flood of issues with people unable to have perms to do things.
(In reply to comment #35) > As I already noted to the bodhi, the patch breaks "startx&exit" use case. > Result is X server cannot handle keyboard input. > > That's because you have introduced race by pinning X to VT which disappeared > in the mean time. "exec startx" works fine here. It should get what (I presume) you're looking for (killing X -> no shell).
(In reply to comment #37) > (In reply to comment #35) > > As I already noted to the bodhi, the patch breaks "startx&exit" use case. > > Result is X server cannot handle keyboard input. > > > > That's because you have introduced race by pinning X to VT which disappeared > > in the mean time. > > "exec startx" works fine here. It should get what (I presume) you're looking > for (killing X -> no shell). Yeah, this is good solution.
The startx patch makes it impossible to specify display in command line. if/fi part of the patch should be placed after parsing command line arguments.
Created attachment 640245 [details] allow to specify X display number (In reply to comment #39) You are right, arguments parsing became broken for this case. Moving down the pasted block seems enough, patch attached (made for already preprocessed file). However I'm not sure it doesn't introduce similar mistakes for another features.
Created attachment 641054 [details] patch v3 Patch v2 does not fix all problems caused by the first patch. Both patches always add vtXX and don't allow to specify other virtual terminal number. Also startx is terminated if tty command could not determine current terminal number. But Xorg can pick the first available terminal that it can locate. Patch v3 fixes described problems. It adds vtXX only if tty command is not failed and there is no vtXX option in the command line.
(In reply to comment #41) > Both patches always add vtXX and don't allow to specify other virtual terminal number. > Xorg can pick the first available terminal that it can locate. To clear the point, direct binding to VT was added to remove xorg VT autodetection you describe and launch it from an authenticated session, as far as I understand. Otherwise you have an "inactive" session inside X and it causes some unpleasant things described above and in the bug duplicates. In this case autodetect is a thing to escape, in other words. Please correct me if I'm wrong. Regarding VT specify, could you describe the case more exactly? I just can imagine a case when you are authenticated at two or more VTs and want to launch X at one VT from another.
(In reply to comment #42) > To clear the point, direct binding to VT was added to remove xorg VT > autodetection you describe and launch it from an authenticated session, as > far as I understand. Otherwise you have an "inactive" session inside X and > it causes some unpleasant things described above and in the bug duplicates. > In this case autodetect is a thing to escape, in other words. Please correct > me if I'm wrong. It's clear. Direct binding to VT should be by default but must not stop startx if tty command failed. In some cases it will be better to have "inactive" session than nothing. For example, starting X from rc.local. > Regarding VT specify, could you describe the case more exactly? I just can > imagine a case when you are authenticated at two or more VTs and want to > launch X at one VT from another. Right.
(In reply to comment #43) > Direct binding to VT should be by default but must not stop > startx if tty command failed. In some cases it will be better to have > "inactive" session than nothing. In this case some override option would be better, as for me. Something like --allow-auto-vt which will allow creation of "inactive" session. The best case is to aware user before he face any problems caused by this. Immediate exit may be not the best solution and some warning can be an alternative, but I don't know how to implement it reliably and visible enough at the same time. > Right. What is preventing to launch X directly from the target VT? I'm not against that, it's mostly a curiosity.
xorg-x11-xinit-1.3.2-7.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I'm finding a problem with this patch as in xorg-x11-xinit-1.3.2-7.fc18. After a kickstart install, my firstboot script runs startx with a .xinitrc file to briefly run X so that I can find out how many monitors are physically connected to the system. I then use that information to make the right xorg.conf file. The problem is that during this firstboot script there is no vt, so startx doesn't start X, rather it gives the message: "Error getting tty num", and then exits. I have been able to work round this using xinit to start X instead of startx. I wonder if you would consider reviewing whether startx not being able to get the vt number should be a fatal error please. Thanks.
So we have one more argument for smth like --allow-auto-vt. However startx doesn't process any runtime options given for itself, as far as I understand. Need more opinions :)
Created attachment 829657 [details] fix serverargs display in startx script
I was playng with Xdmx, with this command: startx -fg white -bg gray20 -- $(which Xdmx) :5 -input $DISPLAY -display $DISPLAY -display :0.0 -norender -noglxproxy -ignorebadfontpaths but the unmodified "starx" fail parsing of "$server" argument in command line. What i get is /bin/X vt1 /bin/Xdmx ... instead of /bin/Xdmx ... --- trying to fix the script (around patch: RHBZ#820675 , for vt parameter), i can avoid server program error but Xdmx complains about vt paramenter --- without the vt parameter X(dmx) crashes with message: xinit: XFree86_VT property unexpectedly has 0 items instead of 1 xterm: cannot load font '-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1' xinit: connection to X server lost waiting for X server to shut down
Created attachment 935079 [details] Xdmx startx log (vt-crash) output of startx command, with patched startx command startx -fg white -bg gray20 -- $(which Xdmx) :5 -input $DISPLAY -display $DISPLAY -display :0.0 -norender -noglxproxy -ignorebadfontpaths
Hi, (In reply to Giovanni Pelosi from comment #49) > I was playng with Xdmx, with this command: > > > startx -fg white -bg gray20 -- $(which Xdmx) :5 -input $DISPLAY -display > $DISPLAY -display :0.0 -norender -noglxproxy -ignorebadfontpaths > > > but the unmodified "starx" fail parsing of "$server" argument in command > line. > > What i get is > > /bin/X vt1 /bin/Xdmx ... > > instead of > > /bin/Xdmx ... Right, this is a bug in F-20 startx which has been fixed in F-21, atm there are no intentions to also fix this for F-20. > trying to fix the script (around patch: RHBZ#820675 , for vt parameter), i > can avoid server program error but Xdmx complains about vt paramenter > > xinit: XFree86_VT property unexpectedly has 0 items instead of 1 > xterm: cannot load font > '-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1' > xinit: connection to X server lost Xdmx does not take a vt parameter, and the "xinit: XFree86_VT property unexpectedly has 0 items instead of 1" error is harmless, the real problem is that the xterm (*) cannot find an usable font and then exits, taking down the Xdmx session with it, as it is used as the window manager. You can try installing xorg-x11-fonts-misc to fix this. Regards, Hans *) Which gets started by /etc/X11/xinit/Xclients as the window manager since you don't have anything else installed,
Hi all. I'm the new xorg-x11-"apps" maintainer. Upstream has a better version of the "add vt" startx patch, which should resolve any issues people are having with the current incarnation. I'm in the process of updating xorg-x11-xinit to the latest upstream version, which will resolve this bug. Regards, Hans
xorg-x11-xinit-1.3.4-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/xorg-x11-xinit-1.3.4-1.fc21
xorg-x11-xinit-1.3.4-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/xorg-x11-xinit-1.3.4-1.fc20
Package xorg-x11-xinit-1.3.4-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-xinit-1.3.4-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-10768/xorg-x11-xinit-1.3.4-1.fc21 then log in and leave karma (feedback).
xorg-x11-xinit-1.3.4-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
xorg-x11-xinit-1.3.4-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.