Re: [PATCH xinit v2 3/3] startx: Under Linux start X on the current VT
Hi, On 04/04/2014 11:40 PM, Julien Cristau wrote: On Thu, Mar 27, 2014 at 14:18:14 +0100, Mark Kettenis wrote: What you're basically saying is that on a modern Linux systems, the historic behaviour where X allocates a new VT and occupies it is no longer wanted. This raises several questions: 1. Is there consensus among the various Linux distros that this really is the desired default behaviour? I think it's going to surprise people. I'm certainly used to being able to switch back to the console after running startx. Now maybe it's not as big a deal as I fear, and we'll get used to the new behaviour, but I don't even know what the upside is... There are 2 reasons for this change: 1) It is needed to make Xorg run without root rights 2) The old behavior creates a new session-id (as returned by getsid()), without registering it with PAM, this breaks session managers such as systemd-logind. Regards, Hans ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xinit v2 3/3] startx: Under Linux start X on the current VT
On Thu, Mar 27, 2014 at 14:18:14 +0100, Mark Kettenis wrote: What you're basically saying is that on a modern Linux systems, the historic behaviour where X allocates a new VT and occupies it is no longer wanted. This raises several questions: 1. Is there consensus among the various Linux distros that this really is the desired default behaviour? I think it's going to surprise people. I'm certainly used to being able to switch back to the console after running startx. Now maybe it's not as big a deal as I fear, and we'll get used to the new behaviour, but I don't even know what the upside is... Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xinit v2 3/3] startx: Under Linux start X on the current VT
When we let X allocate a new VT, systemd-logind will not recognize any
processes running on this VT as belonging to a valid session (since there
was no pam session opened on that tty).
This causes problems like PolicyKit denials for these processes.
ConsoleKit under Linux has been deprecated for a few years now and is no
longer being maintained, so simply make this the default under Linux.
Note we do not pass in the vt if the user has specified an alternative server
to start, as the vtX argument is only valid for the Xorg server, likewise we
omit it if the user has specified any other server arguments.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=806491
Signed-off-by: Hans de Goede hdego...@redhat.com
---
startx.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/startx.cpp b/startx.cpp
index b7a29f9..8426734 100644
--- a/startx.cpp
+++ b/startx.cpp
@@ -187,6 +187,16 @@ XCOMM process server arguments
if [ x$server = x ]; then
server=$defaultserver
+#ifdef __linux__
+XCOMM When starting the defaultserver start X on the current tty to avoid
+XCOMM the startx session being seen as inactive: RHBZ#820675
+tty=$(tty)
+if expr match $tty '^/dev/tty[0-9]\+$' /dev/null; then
+tty_num=$(echo $tty | grep -oE '[0-9]+$')
+defaultserverargs=${defaultserverargs} vt${tty_num}
+fi
+#endif
+
XCOMM For compatibility reasons, only use xserverrc if there were no
server command line arguments
if [ x$serverargs = x -a x$display = x ]; then
if [ -f $userserverrc ]; then
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xinit v2 3/3] startx: Under Linux start X on the current VT
From: Hans de Goede hdego...@redhat.com Date: Thu, 27 Mar 2014 12:55:57 +0100 When we let X allocate a new VT, systemd-logind will not recognize any processes running on this VT as belonging to a valid session (since there was no pam session opened on that tty). This causes problems like PolicyKit denials for these processes. ConsoleKit under Linux has been deprecated for a few years now and is no longer being maintained, so simply make this the default under Linux. What you're basically saying is that on a modern Linux systems, the historic behaviour where X allocates a new VT and occupies it is no longer wanted. This raises several questions: 1. Is there consensus among the various Linux distros that this really is the desired default behaviour? 2. Doesn't this really mean that the default behaviour of the X server itself should be change to take over the VT it is running on instead of allocating a new one? An excellent opportunity to remove code instead of adding more hacks I'd say ;). Note we do not pass in the vt if the user has specified an alternative server to start, as the vtX argument is only valid for the Xorg server, likewise we omit it if the user has specified any other server arguments. If I read the shell code correctly you're also not passing the vtX argument if the user specifies any arguments to be used with the standard server. For example, startx -- -depth 16 will not pass the necessary vtX argument. Also: --- startx.cpp | 10 ++ 1 file changed, 10 insertions(+) diff --git a/startx.cpp b/startx.cpp index b7a29f9..8426734 100644 --- a/startx.cpp +++ b/startx.cpp @@ -187,6 +187,16 @@ XCOMM process server arguments if [ x$server = x ]; then server=$defaultserver +#ifdef __linux__ +XCOMM When starting the defaultserver start X on the current tty to avoid +XCOMM the startx session being seen as inactive: RHBZ#820675 This sort of vendor-specific bug references isn't very helpful is it? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xinit v2 3/3] startx: Under Linux start X on the current VT
Hi, On 03/27/2014 02:18 PM, Mark Kettenis wrote: From: Hans de Goede hdego...@redhat.com Date: Thu, 27 Mar 2014 12:55:57 +0100 When we let X allocate a new VT, systemd-logind will not recognize any processes running on this VT as belonging to a valid session (since there was no pam session opened on that tty). This causes problems like PolicyKit denials for these processes. ConsoleKit under Linux has been deprecated for a few years now and is no longer being maintained, so simply make this the default under Linux. What you're basically saying is that on a modern Linux systems, the historic behaviour where X allocates a new VT and occupies it is no longer wanted. Correct, because: 1) That detaches X from the current session (as returned by getsid()) which causes problems with session management 2) That won't work when not running as root since X will not be permitted to allocate a new VT when not running as root This raises several questions: 1. Is there consensus among the various Linux distros that this really is the desired default behaviour? I don't know note we're talking about changing startx here, and on most distros X gets started through a display-manager. Atleast gdm will pass in a vt to use rather then letting X auto-allocate a new one. I assume most other display managers do the same, but I'm not sure. 2. Doesn't this really mean that the default behaviour of the X server itself should be change to take over the VT it is running on instead of allocating a new one? An excellent opportunity to remove code instead of adding more hacks I'd say ;). In all the recent work I've been doing I've been very careful to not break any existing use cases. Although I for one would love to rip out all the code related to opening a new VT instead of using the existing one, I'm not sure that will be accepted by everyone. I think your idea is good, but that we should revisit it in say a year from now, when hopefully most distros will have picked up my work to run X as non-root, and this behavior is thus no longer available anyways. Note we do not pass in the vt if the user has specified an alternative server to start, as the vtX argument is only valid for the Xorg server, likewise we omit it if the user has specified any other server arguments. If I read the shell code correctly you're also not passing the vtX argument if the user specifies any arguments to be used with the standard server. For example, startx -- -depth 16 will not pass the necessary vtX argument. Correct, as mentioned in the commit msg this is by design, if user specify any arguments other then a display number, then they should also specify the vt themselves. Also: --- startx.cpp | 10 ++ 1 file changed, 10 insertions(+) diff --git a/startx.cpp b/startx.cpp index b7a29f9..8426734 100644 --- a/startx.cpp +++ b/startx.cpp @@ -187,6 +187,16 @@ XCOMM process server arguments if [ x$server = x ]; then server=$defaultserver +#ifdef __linux__ +XCOMM When starting the defaultserver start X on the current tty to avoid +XCOMM the startx session being seen as inactive: RHBZ#820675 This sort of vendor-specific bug references isn't very helpful is it? It is in a public bug tracker, I guess it would have been more helpful if I had inserted a URL to the bug tracker there, you can view this bug at: https://bugzilla.redhat.com/show_bug.cgi?id=806491 Note the different number, that is my bad, the number in the url is correct. I'll fixed the comment to contain the correct url in my local repo. Regards, Hans ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
