Bug 806491 - systemd-logind not tracking startx sessions
systemd-logind not tracking startx sessions
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-xinit (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Reopened
: 820675 857662 (view as bug list)
Depends On:
Blocks: 868685 960955
  Show dependency treegraph
 
Reported: 2012-03-23 22:42 EDT by Ben Boeckel
Modified: 2014-09-23 01:01 EDT (History)
34 users (show)

See Also:
Fixed In Version: xorg-x11-xinit-1.3.4-1.fc21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-13 23:26:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch for startx (626 bytes, patch)
2012-06-18 12:41 EDT, Andrew Travneff
no flags Details | Diff
patch v2 (649 bytes, patch)
2012-08-30 11:01 EDT, Andrew Travneff
no flags Details | Diff
allow to specify X display number (798 bytes, patch)
2012-11-07 13:18 EST, Andrew Travneff
no flags Details | Diff
patch v3 (1.09 KB, patch)
2012-11-08 14:32 EST, Vsevolod Volkov
no flags Details | Diff
fix serverargs display in startx script (523 bytes, patch)
2013-11-27 07:02 EST, Michael Schwendt
no flags Details | Diff
Xdmx startx log (vt-crash) (15.81 KB, text/plain)
2014-09-06 17:23 EDT, Giovanni Pelosi
no flags Details

  None (edit)
Description Ben Boeckel 2012-03-23 22:42:37 EDT
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
Comment 1 Ben Boeckel 2012-03-23 22:44:56 EDT
After installing CK again, ck-launch-session creates a session in ck-list-sessions, but PolicyKit still denies despite the current session being 'Active'.
Comment 2 Michal Schmidt 2012-03-26 02:53:42 EDT
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.
Comment 3 Ben Boeckel 2012-03-26 14:13:47 EDT
Could this be documented in systemd somewhere?
Comment 4 Lennart Poettering 2012-03-26 17:42:08 EDT
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
Comment 5 Ben Boeckel 2012-03-26 19:35:18 EDT
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).
Comment 6 Michal Schmidt 2012-06-12 09:18:50 EDT
*** Bug 820675 has been marked as a duplicate of this bug. ***
Comment 7 Zdenek Kabelac 2012-06-12 09:27:14 EDT
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?
Comment 8 Renato Botelho do Couto 2012-06-14 16:09:05 EDT
+1 for startx
Comment 9 Tomi Leppikangas 2012-06-18 10:33:00 EDT
Partial solution:
$ tty
/dev/tty1
$ startx -- vt01

After that loginctl reports session as active from xterm
Comment 10 Renato Botelho do Couto 2012-06-18 11:00:26 EDT
Worked fine here, after that i'm able to suspend/hibernate on xfce4-power-manager.
Comment 11 Michal Schmidt 2012-06-18 11:02:46 EDT
Anyone willing to put that into a form of a patch for /usr/bin/startx ?
Comment 12 Andrew Travneff 2012-06-18 12:41:09 EDT
Created attachment 592704 [details]
proposed patch for startx
Comment 13 Andrew Travneff 2012-06-18 12:42:07 EDT
(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.
Comment 14 Kevin Fenzi 2012-06-18 22:06:03 EDT
Scratch build with above patch:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4175585

That takes care of the startx part, but what about xinit?
Comment 15 Andrew Travneff 2012-06-19 06:27:36 EDT
(In reply to comment #14)

This build includes just first part of patch ;)
Comment 16 Kevin Fenzi 2012-06-19 10:19:53 EDT
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.
Comment 17 Christoph Wickert 2012-08-27 17:29:25 EDT
Sorry for accidentally changing the component and assignee. Reverting this stupid JS bug.
Comment 18 Adam Williamson 2012-08-29 22:28:54 EDT
this really ought to be commonbugs so i stop forgetting about it.
Comment 19 Kevin Kofler 2012-08-30 06:45:58 EDT
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???
Comment 20 Andrew Travneff 2012-08-30 07:03:54 EDT
(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
}
Comment 21 Kevin Fenzi 2012-08-30 10:22:27 EDT
(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.
Comment 22 Andrew Travneff 2012-08-30 11:01:06 EDT
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.
Comment 23 Kevin Kofler 2012-08-30 19:42:09 EDT
Of course patching the already processed file doesn't work, it will be overwritten during the build.
Comment 24 Andrew Travneff 2012-08-31 04:49:17 EDT
(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.
Comment 25 Adam Williamson 2012-09-25 18:08:19 EDT
*** Bug 857662 has been marked as a duplicate of this bug. ***
Comment 26 Kevin Fenzi 2012-09-29 15:13:35 EDT
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. :)
Comment 27 Andrew Travneff 2012-09-30 06:55:51 EDT
(In reply to comment #26)

I see just a F18 rpm there, is it ok to install it at F17 ?
Comment 28 Kevin Kofler 2012-09-30 10:39:08 EDT
Probably not, we need an F17 build.
Comment 29 Kevin Fenzi 2012-09-30 12:37:25 EDT
f17 scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=4543610
Comment 30 Andrew Travneff 2012-10-01 06:12:56 EDT
(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
Comment 31 Robert Gadsdon 2012-10-01 13:22:35 EDT
Works OK here, too.   F17 X86_64 Kernel 3.6..

Thanks!

Robert Gadsdon
Comment 32 Fedora Update System 2012-10-01 19:13:49 EDT
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
Comment 33 Fedora Update System 2012-10-01 19:24:59 EDT
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
Comment 34 Fedora Update System 2012-10-02 15:50:06 EDT
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).
Comment 35 Petr Pisar 2012-10-19 04:01:45 EDT
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.
Comment 36 Kevin Fenzi 2012-10-19 10:26:48 EDT
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.
Comment 37 Ben Boeckel 2012-10-19 11:38:56 EDT
(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).
Comment 38 Petr Pisar 2012-10-22 04:18:24 EDT
(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.
Comment 39 Vsevolod Volkov 2012-10-22 13:57:18 EDT
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.
Comment 40 Andrew Travneff 2012-11-07 13:18:44 EST
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.
Comment 41 Vsevolod Volkov 2012-11-08 14:32:45 EST
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.
Comment 42 Andrew Travneff 2012-11-09 06:48:04 EST
(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.
Comment 43 Vsevolod Volkov 2012-11-09 13:48:32 EST
(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.
Comment 44 Andrew Travneff 2012-11-11 06:51:11 EST
(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.
Comment 45 Fedora Update System 2012-12-20 11:12:55 EST
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.
Comment 46 Roderick Johnstone 2013-01-02 08:11:12 EST
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.
Comment 47 Andrew Travneff 2013-01-02 15:02:42 EST
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 :)
Comment 48 Michael Schwendt 2013-11-27 07:02:27 EST
Created attachment 829657 [details]
fix serverargs display in startx script
Comment 49 Giovanni Pelosi 2014-09-06 17:20:01 EDT
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
Comment 50 Giovanni Pelosi 2014-09-06 17:23:11 EDT
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
Comment 51 Hans de Goede 2014-09-11 05:32:25 EDT
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,
Comment 52 Hans de Goede 2014-09-11 12:55:51 EDT
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
Comment 53 Fedora Update System 2014-09-12 03:12:52 EDT
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
Comment 54 Fedora Update System 2014-09-12 03:14:23 EDT
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
Comment 55 Fedora Update System 2014-09-12 13:47:13 EDT
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).
Comment 56 Fedora Update System 2014-09-13 23:26:35 EDT
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.
Comment 57 Fedora Update System 2014-09-23 01:01:40 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.