[svlug] X Sessions

Rick Moen rick at svlug.org
Thu Nov 13 19:59:59 PST 2014


Scott wrote:

> So if I have a full DE running on tty7 (default start up) and I switch
> to tty1, log in, and execute: $ startx -- :1, I get nothing because
> there is already a session running under those credentials?

Erik Steffl mentioned 'X :1' already, which is starting up the bare
X11 server (graphics engine) on display :1 .  That's actually pretty
much the simplest possible test case, in a situation where simple is
good and something to gravitate towards to minimise the number of things
going on and the number of pieces that might shoot you in the foot.

Starting a bare X server has functional disadvantages, so using the
startx command is an appealing alternative, a point I'll return to.

As Erik also mentioned, it's really vital to check in logfiles when you
attempt such things.  Unix tends to mutter into logfiles, so looking
for clues in the right places (like, in this case, /var/log/Xorg.1.log
or such) is a very useful habit to cultivate.

In _general_, the two most universally useful tips I give to Unix users
are (1) when in doubt, consider that your problem might be
ownership/permissions, and (2) What do the logfiles say?

Tip #1 isn't likely to help you here (as X demonstrably does start, for
the first instance), but #2 should top your list.

Getting back to startx, this is simple example syntax for the second X
server:

  startx -- :1

  A more-elaborate version:

    startx gnome-session -- :1 vt8

To unpack that:  'startx' is a wrapper for the xinit utility, a
lower-level tool.  The startx wrapper makes the startup of xinit and
thus the X server a bit less painful to manage and talk to.  The '--'
is a trick:  It's a delimiter that tells startx that there are no more
client arguments addressed to startx itself, and that everything after
it should be passed verbatim to the X server.

So, in the above, 'gnome-session' gets passed as an argument to startx.
startx in turn (via xinit) runs an instance of the X server (graphics
engine), instructing it to bind itself to display :1 and bind the
session to virtual console #8.

I can spot one complication right off the bat:  You're using a distro
with the systemd init process.  The systemd init tries to be frightfully
clever and does event-driven startup of daemons as it detects attempts
to bind to those daemons' sockets, or something like that.  As I don't
have a systemd-based system in front of me, you'll need someone else to
assist with any difficulties, there.  With a SysVinit init, you would
look at the bottom of /etc/inittab to find out how many 'getty'
processes launch by default to run text consoles.  SysV-based distros
typically default to six gettys, so text consoles /dev/tty1 through
/dev/tty6.  The first X11 session, the ':0' default one, then runs on
/dev/tty7 by default, and the second one (':1'), then runs on /dev/tty8
by default.

I would _guess_ that a systemd-based system would default to starting
the first X session on /dev/tty1, the second one on /dev/tty2, etc.
I'm actually pretty sure about that guess, but someone else might be
able to cross-check.

The other complication you have in your setup is GNOME.  The GNOME and
Freedesktop.org people, to summarise the summary of a summary, really
don't believe at all in X11's client/server networked graphics model,
and make its normal operation rather difficult.  One of their pieces,
'consolekit', believes it's in control and is entitled to decide what
virtual console is 'authenticated' for access to GNOME's logind process.

For a while, you could use a utility called ck-launch-session  in
~/.xinitrc to get a new session for the X server.  Later from 2012
on, this reportedly broke in GNOME logind.  If you can figure that out,
good luck, but I htink the writing's on the wall that the GNOME people
don't intend to support multiple X sessions on a single host.

I might, at this dramatic juncture in our narrative, recommend a handy
little control called the ~/.xinitrc file to you.  That is of course a
startup file for xinit, and therefore is in a derivative sense one for
startx.  ~/.xinitrc can contain any valid shell commands, but the
obvious thing to put in it for test purposes is something like this:

   /usr/bin/xterm

Just one line, flush-left.  Save, exit.  Then, on one of your text
consoles (e.g., on the /dev/tty1 screen), try something like;

   startx -- :1

or

   startx -- :1 vt2

Your systemd-based system will probably (if I'm figuring out these
things correctly) default to the next unused virtual console for the
second X session (if you type the first version of that command line),
whereas the second version says specifically 'Oh, and please use virtual
console /dev/tty2 for this'.

Oh, BTW, the one-line ~/.xinitrc file literally says to the X server (via
wrappers) 'please start exactly one X client app, a single xterm'.  If this
is successful, you will see an xterms window with no edge controls in the
middle of a mottled X graphical screen that otherwise has no features at
all.  It's actually rather fun to play with, for demonstration purposes,
because you can start and kill various other things from the xterm 'root
window' -- such as window managers, like this:

   /usr/bin/fvwm &

This assumes you have the package containing the fvwm window manager
installed.  Note that the xterm suddenly sprouts fvwm-type edge controls,
and you have an fvwm context menu.  Rerver to just a bare xterm;

   killall fvwm

Start a different window manager for comparsion's sake:

  /usr/bin/wmaker &

That's Window Maker.  And so on.





More information about the svlug mailing list