[PATCH xinit v2 3/3] startx: Under Linux start X on the current VT

[Hans de Goede]

Hi,

On 03/27/2014 02:18 PM, Mark Kettenis wrote:
>> From: Hans de Goede <hdegoede at 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