On 01/05/19 13:54, Sean MacLennan wrote:
> I almost always run X11... so I want it to startup when I login.
> Without a DM, this is how I handle it.
For a single-user laptop or workstation, why does there even need to be a
concept of "logging in"? And why do you need 3-4 layers of shells running in the
background to manage your X session? You've got:
- your login shell
- startx
- xinit
- your .xinitrc, if you don't exec your window manager
Exactly zero of these are necessary for a proper X session! X is a client-server
protocol, not magic. Start a server, start a client, tell it where the server
is, and that's it. No shells, no gettys, none of that cruft -- this is suckless,
right?
This is what I do:
1) I have a udev rule that chowns tty1 to my user, so I can run Xorg without
root privileges:
SUBSYSTEM=="tty", KERNEL=="tty1", OWNER="me", GROUP="me", MODE="0600"
If your Xorg is suid root or cap_sys_admin, you don't need this. But I prefer
to not give it privileges it doesn't need.
2) In my user's unprivileged s6[1] supervision tree[2], I have a supervised
service that runs Xorg on tty1:
Xorg -displayfd 5 vt1
The `-displayfd` argument tells Xorg to write its display number to a file,
which is put in an envdir[3] and unsurprisingly named "DISPLAY". The fact
that Xorg is independently supervised means it is always running, regardless
of which (if any) clients are connected. So if my window manager crashes, I
don't lose my session!
Another benefit of supervision is that Xorg is always run in the same
environment. I could ssh into the box and restart Xorg, and it would be
right back on tty1, 100% of the time.
3) Also in my user's s6 supervision tree, I have a service for my window
manager. s6-rc[4] handles the dependency on the X server and the DISPLAY
environment variable automatically.
s6-envdir -fi /run/user/me/env i3
I have similarly simple services for urxvtd, redshift, compton, etc. That way
I *always* know at a glance
a) if those background processes are running, because s6 will tell me; and
b) where the processes are, because it's always the same place -- in the
supervision tree.
It is simply not possible to have "leftover" processes from a previous
session, or to start a service with the wrong environment by starting it from
the "wrong" shell.
4) What about passwords? Simple! Have the screen locker start at boot, just like
everything else I've mentioned so far.
Doing things this way means I get to reuse the same tools for managing my X
session as I do for my system services. It also means there's a consistent set
of environment variables for all of my processes, and there are no extra shells
sitting around. Here's what the process tree looks like (where each of the
s6-supervise processes are using a *single 4k page* of RAM, and the s6-svscan's
are using about 64k, and absolutely 0 CPU time unless you interact with them):
s6-svscan -s [PID 1, running as root]
├─ s6-supervise user-services_AT_me
│ └─ s6-svscan -S [running as me]
│ ├─ i3bar --bar_id=bar-0 --socket=/run/user/me/i3/socket
│ │ └─ i3status
│ ├─ s6-supervise xorg
│ │ └─ Xorg -displayfd 5 -nolisten local -nolisten tcp -quiet -tst vt1
│ ├─ s6-supervise urxvtd
│ │ └─ urxvtd -q
│ │ └─ zsh
│ ├─ s6-supervise ssh-agent
│ │ └─ ssh-agent -a /run/user/me/ssh-agent -Ds
│ ├─ s6-supervise s6rc-oneshot-runner
│ │ └─ s6-ipcserverd -1 ... [runs oneshots like setting the wallpaper]
│ ├─ s6-supervise s6rc-fdholder
│ ├─ s6-supervise redshift
│ │ └─ redshift -r
│ ├─ s6-supervise mpd
│ │ └─ mpd --no-daemon --stderr
│ ├─ s6-supervise i3
│ │ └─ i3
│ └─ s6-supervise compton
│
... [system services]
TL;DR: "startx vs a DM" is a false dichotomy. "Logging in" to a PC is
meaningless. Supervision is the *correct* answer to managing a set of
long-running processes.
Cheers,
Samuel
[1]:
https://skarnet.org/software/s6 (like runit, but much better)
[2]:
https://github.com/smaeul/rc-user
[3]:
https://skarnet.org/software/s6/s6-envdir.html
[4]:
https://skarnet.org/software/s6-rc
Received on Sat Jan 05 2019 - 22:12:41 CET