Automatic X login without a DM

jouke · 2012-08-29 12:12:41

It turned out to be a lot harder than I expected to configure my system with systemd and without consolekit or a desktop manager, so that it would log me in to X automatically at boot.
I wanted to be able to shutdown without entering a password, so my session had to be registered with polkit and made 'active'. This is how I did it.

Install a systemd-enabled version of polkit from https://dev.archlinux.org/~tomegun/.
Write some scripts, now available at https://github.com/joukewitteveen/xlogin (use make install as root).
Enable the automatic login: systemctl enable xlogin\@<username>.service.

Some considerations

In my opinion this whole setup is much simpler than through Auke Kok's user-session-units, although I expect systemd user sessions to become the default in the future. At the moment that approach is just too buggy.

In step two, I wrote a simple bash script called x-daemon. Its functionality is more or less identical to Auke Kok's xorg-launch-helper, which contains about 15 times as many lines of code.
The two service files could not easily be merged because of systemd bug 54176.

I installed polkit-gnome and added the following line to my .xinitrc:

/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1 &

This way I get a nice graphical password dialog if a program requires authentication.

For shutdown etc. I use the following script, although I am not entirely happy with it:

#!/bin/bash

ACTION=$(zenity --title "End Session" --list --text "" --radiolist --column "" --column "" --hide-header FALSE Logout TRUE Shutdown FALSE Reboot)

#[[ $? -eq 0 ]] || exit 1

case $ACTION in
  Logout)
    loginctl terminate-session "$XDG_SESSION_ID";;
  Shutdown)
    systemctl poweroff;;
  Reboot)
    systemctl reboot;;
esac

Something similar can be achieved through the likes of obshutdown, but I tried to keep things as simple as possible.

This way I managed to set up a system without consolekit, without a desktop manager and even without a desktop environment. Instead of using a desktop environment, I am very happy to use xfdesktop (backdrop and then some), docky-plank (I wish... for now awn is a stop-gap solution for a dock), kupfer (launcher) and gala (compositing window manager), all started through .xinitrc.

Last edited by jouke (2012-08-29 12:51:46)

65kid · 2012-08-29 12:23:12

looks interesting, I'm gonna try it out, thanks.

I'm currently using polkit 107 from tomegun and agetty autologin together with "startx -- vt01" in my bash_profile. Works fine without crappy consolekit. But the agetty autologin always felt kind of hacky to me. Didn't have to add polkit to my xinitrc though...

I also couldn't get the user-session units by Auke Kok to work, I got X to start up, but my session wasn't registered properly.

jouke · 2012-08-29 12:30:56

The added line in .xinitrc regarding polkit is only to present a graphical password dialog in case polkit needs to authenticate. If no authentication agent is present and no terminal is connected to a program that wants to authenticate, authentication fails. If a terminal is available, text-based authentication takes place. The gnome-polkit thing is just a dialog, really .

65kid · 2012-08-29 12:43:54

jouke wrote:

The added line in .xinitrc regarding polkit is only to present a graphical password dialog in case polkit needs to authenticate. If no authentication agent is present and no terminal is connected to a program that wants to authenticate, authentication fails. If a terminal is available, text-based authentication takes place. The gnome-polkit thing is just a dialog, really .

ah ok, that makes sense

I just tried it, seems to work.
It's also faster than starting X after getty autologin. Boot feels almost instant.

it's just that for some reason my .bashrc isn't loaded in urxvt anymore, wonder why that happens...

and regarding your README, you could actually replace

# systemctl enable xlogin\@.service
# mv /etc/systemd/system/graphical.target.wants/xlogin\@{,<username>}.service

with...

# systemctl enable xlogin\@<username>.service

jouke · 2012-08-29 13:00:47

Ah, so they fixed that! Thanks, I updated the docs.

As far as I can tell, your .bash_profile should be sourced when xlogin is started and that should in turn source .bashrc. Until you find the cause, you can just source .bashrc from .xinitrc .

Trilby · 2012-08-29 13:03:52

I have auto login to X set up without a DM and with systemd. I just set up autologin to tty1 for systemd, and set up everything else (exec xinit called from .bashrc conditional) just as it was with initscripts.

I'm not sure why you needed to change anything.

jouke · 2012-08-29 22:23:35

Trilby wrote:

I'm not sure why you needed to change anything.

Because, as 65kid mentioned, the tty-autologin method is hackish and has noticeable overhead. It also costs you a tty.
If you are going to use systemd as a process governor, having it govern X is a good thing. Your remark is almost the same as saying: I'm not sure why systemd is a good thing.

In fact, if this new method turns out to be reliable, I'd want to suggest inclusion in the wiki.

Trilby · 2012-08-29 22:59:10

You are correct about the tty of course, but can you elaborate on it being "hackish" and having "noticeable overhead"?

How is one conditional and one command in .bashrc more hackish that several scripts that use zenity dialogs and depend on various other tools? And what overhead is this?

I only meant to suggest an alternative I felt was overlooked - but if you wish to sling mud, I hope you'll at least back up your claims.

Last edited by Trilby (2012-08-29 23:00:05)

65kid · 2012-08-30 14:09:26

Trilby wrote:

You are correct about the tty of course, but can you elaborate on it being "hackish" and having "noticeable overhead"?
How is one conditional and one command in .bashrc more hackish that several scripts that use zenity dialogs and depend on various other tools? And what overhead is this?

I consider it "hackish" because:
* I'm constantly logged into the tty but can't actually use it
* I can't see X's output without redirecting it
* the system has to wait for the tty to be ready and log in to start the X server, while the tty and the X server are (imho) actually two completely independent things that have almost nothing to do with each other. so why should one thing wait and depend on the other? (that's also why the service file method is faster, systemd doesn't have to wait for agetty to load and log in)

and as mentioned it just makes sense to let systemd handle this. It also takes care of logging, restarting etc. This will even be way more more awesome when systemd user-sessions work properly and most of this stuff is provided upstream.

and the zenity script he provided has actually nothing to do with the login mechanism itself.

65kid · 2012-09-06 15:22:37

I actually got a proper systemd user session to work. Note that you will need the dbus user units from user-session-units and the patched dbus it depends on (and the systemd enabled polkit obviously).

I kind of mixed your method with user-session-units from Auke Kok. In xlogin@.service I start the systemd user-session instead of executing .xinitrc (also note that I removed the KillMode= here because control-group is actually the default). As far as I can see, the only big difference to Auke Kok's method is that we start X from the system session and not from the user session.

[Unit]
Description=systemd user session for user %I
After=graphical.target systemd-user-sessions.service
Wants=x@vt7.service

[Service]
User=%I
WorkingDirectory=/home/%I
Environment=DISPLAY=:0
TTYPath=/dev/tty7
PAMName=login
ExecStart=/usr/lib/systemd/systemd --user

[Install]
WantedBy=graphical.target

Then I created the following user units in ~/.config/systemd/user/ for my "stuff".

~/.config/systemd/user/default.target is symlinked to i3.target.

i3.target

[Unit]
Description=i3 Window Manager
Requires=dbus.socket
After=dbus.socket 
Wants=i3.service
AllowIsolate=yes

i3.service

[Unit]
Description=i3 Window Manager
After=dbus.socket

[Service]
ExecStart=/usr/bin/i3

nm-applet.service

[Service]
ExecStart=/usr/bin/nm-applet

[Install]
WantedBy=default.target

xrdb -merge.service

[Service]
Type=oneshot
ExecStart=/usr/bin/xrdb -merge .Xresources

[Install]
WantedBy=default.target

xcompmgr.service

[Service]
ExecStart=/usr/bin/xcompmgr

[Install]
WantedBy=default.target

Last edited by 65kid (2012-09-06 15:28:44)

zacariaz · 2012-09-06 15:55:19

I can not say how much I appreciate what you're trying to do, but frankly, this is just too much for me, not least because I don't quite understand what's going on and that I need patched packages from AUR. (that's kinda dodgy in my world, though AUR is of course great.)

So thanks you very much, but I think I'm going to stick with slim for now, while waiting for a simpler solution.

jouke · 2012-09-06 18:26:05

@65kid:
Good idea! The KillMode was a leftover from an attempt to make logout work. Currently systemctl stop xlogin\@<username> doesn't kill the processes that are forked from .xinitrc.
Do mind that systemd user sessions are not properly supported yet. For instance, we still have https://bugs.freedesktop.org/show_bug.cgi?id=50962.

@zacariaz:
It is really not that difficult. It will become dead simple once polkit 0.107 hits [extra], for now you have to install that one by downloading it from https://dev.archlinux.org/~tomegun/ and installing it through pacman -U --asdeps polkit-0.107*.
Installation of the xlogin stuff is not (yet) possible through the AUR, although a PKGBUILD script would be extremely simple. If anyone wants to do it, please do[1]. To manually install it, it is easiest to just clone the repository: git clone git://github.com/joukewitteveen/xlogin.git and then (as root) do: cd xlogin; make install. The totall installed size is about half a kilobyte (that's nothing).
After that you are ready to set up your autologin. Disable your DM: systemctl disable slim.service and enable your autologin: systemctl enable xlogin\@<username>.service. That's it!

You can now delete consolekit (720kB), slim (456kB) and possibly xorg-xinit (52kB).
Another convincing argument for the xlogin method might be provided by the look of pstree with and without it (but really, the clean approach is the only argument you need).

[1] The requirements are polkit >= 0.107, systemd, xorg-server and bash.

zacariaz · 2012-09-06 18:45:09

@jouke
Still seems fairly complicated to me and even if it isn't, I prefer to wait until this (or another?) solution is more... well, mainstream.

Not that I think that just above one MB is important, I would very much like to see polkit gone, likewise with slim, and as for xinit... well, why not.

But for, as I said, I prefer to wait.

nierro · 2012-09-06 18:56:16

I switched from polkit 0.105 recompiled with --enable-systemd flag + autologin@tty1 + .bash_profile (as wiki suggests), and try out your method.
Everything works, expect i'm not able to mount internal fs without password. (with my polkit 0.105 it worked)
Well, external usb works instead.
Here is my .pkla

[Storage Permissions]
Identity=unix-group:storage
Action=org.freedesktop.udisks2.*
ResultAny=yes
ResultInactive=yes
ResultActive=yes

bwat47 · 2012-09-11 04:52:31

Thanks, this works pretty well

Last edited by bwat47 (2012-09-12 18:26:39)

bwat47 · 2012-09-12 18:30:00

65kid wrote:

I actually got a proper systemd user session to work. Note that you will need the dbus user units from user-session-units and the patched dbus it depends on (and the systemd enabled polkit obviously).
I kind of mixed your method with user-session-units from Auke Kok. In xlogin@.service I start the systemd user-session instead of executing .xinitrc (also note that I removed the KillMode= here because control-group is actually the default). As far as I can see, the only big difference to Auke Kok's method is that we start X from the system session and not from the user session.
[Unit]
Description=systemd user session for user %I
After=graphical.target systemd-user-sessions.service
Wants=x@vt7.service

[Service]
User=%I
WorkingDirectory=/home/%I
Environment=DISPLAY=:0
TTYPath=/dev/tty7
PAMName=login
ExecStart=/usr/lib/systemd/systemd --user

[Install]
WantedBy=graphical.target
Then I created the following user units in ~/.config/systemd/user/ for my "stuff".
~/.config/systemd/user/default.target is symlinked to i3.target.
i3.target
[Unit]
Description=i3 Window Manager
Requires=dbus.socket
After=dbus.socket 
Wants=i3.service
AllowIsolate=yes
i3.service
[Unit]
Description=i3 Window Manager
After=dbus.socket

[Service]
ExecStart=/usr/bin/i3
nm-applet.service
[Service]
ExecStart=/usr/bin/nm-applet

[Install]
WantedBy=default.target
xrdb -merge.service
[Service]
Type=oneshot
ExecStart=/usr/bin/xrdb -merge .Xresources

[Install]
WantedBy=default.target
xcompmgr.service
[Service]
ExecStart=/usr/bin/xcompmgr

[Install]
WantedBy=default.target

I decided to try your method, and almost everything works except the xrdb service. I've installed the user-session-units and patched dbus from the aur, and edited my xlogin@\.service to start the systemd user session instead of xinitrc. Then I created i3.service, i3.target and xrdb.service in /home/brandon/.config/systemd/user, and symlinked default.target to i3.target. After doing this and rebooting i3 loaded up fine, but my .Xresources is not being marged at all so I have to manually tun the xrdb -merge command. I absolutely cannot figure out why this service isn't working any ideas?

65kid · 2012-09-12 18:52:07

bwat47 wrote:

I decided to try your method, and almost everything works except the xrdb service. I've installed the user-session-units and patched dbus from the aur, and edited my xlogin@\.service to start the systemd user session instead of xinitrc. Then I created i3.service, i3.target and xrdb.service in /home/brandon/.config/systemd/user, and symlinked default.target to i3.target. After doing this and rebooting i3 loaded up fine, but my .Xresources is not being marged at all so I have to manually tun the xrdb -merge command. I absolutely cannot figure out why this service isn't working any ideas?

works fine for me. does it work if you manually start it after boot up?

systemctl --user start xrdb-merge

also check

systemctl --user status xrdb-merge

bwat47 · 2012-09-12 18:59:00

65kid wrote:

bwat47 wrote:
I decided to try your method, and almost everything works except the xrdb service. I've installed the user-session-units and patched dbus from the aur, and edited my xlogin@\.service to start the systemd user session instead of xinitrc. Then I created i3.service, i3.target and xrdb.service in /home/brandon/.config/systemd/user, and symlinked default.target to i3.target. After doing this and rebooting i3 loaded up fine, but my .Xresources is not being marged at all so I have to manually tun the xrdb -merge command. I absolutely cannot figure out why this service isn't working any ideas?
works fine for me. does it work if you manually start it after boot up?
systemctl --user start xrdb-merge
also check
systemctl --user status xrdb-merge

Well I feel silly, figured it out as soon as I read your post

I needed to enable it with systemctl --user enable, now it works, thanks! Now I'm off to make a few more quick services (urxvtd, clipit)

Last edited by bwat47 (2012-09-12 21:16:30)

d3Xt3r · 2012-09-15 03:41:29

65kid wrote:

I actually got a proper systemd user session to work. Note that you will need the dbus user units from user-session-units and the patched dbus it depends on (and the systemd enabled polkit obviously).
I kind of mixed your method with user-session-units from Auke Kok. In xlogin@.service I start the systemd user-session instead of executing .xinitrc (also note that I removed the KillMode= here because control-group is actually the default). As far as I can see, the only big difference to Auke Kok's method is that we start X from the system session and not from the user session.
[...]

Hi 65kid,

I got everything to work, except that I can't get nm-applet to initiate a new connection (manually) - I get this error message:

Failed to add/activate connection

(32) No session found for uid 1000 (Error statting file /var/run/ConsoleKit/database: No such file or directory)

Any ideas what's wrong? Thanks!

Edit:

Looks like my system's more broken than I thought - external USB drives no longer show up under Nautilus (unless I mount them manually). Previously, when I was booting to x manually using startx, I had no such issues.
I would really appreciate it if someone could help troubleshoot this, thanks!

Last edited by d3Xt3r (2012-09-15 08:51:16)

65kid · 2012-09-15 10:07:20

d3Xt3r wrote:

65kid wrote:
I actually got a proper systemd user session to work. Note that you will need the dbus user units from user-session-units and the patched dbus it depends on (and the systemd enabled polkit obviously).
I kind of mixed your method with user-session-units from Auke Kok. In xlogin@.service I start the systemd user-session instead of executing .xinitrc (also note that I removed the KillMode= here because control-group is actually the default). As far as I can see, the only big difference to Auke Kok's method is that we start X from the system session and not from the user session.
[...]
Hi 65kid,
I got everything to work, except that I can't get nm-applet to initiate a new connection (manually) - I get this error message:
Failed to add/activate connection

(32) No session found for uid 1000 (Error statting file /var/run/ConsoleKit/database: No such file or directory)
Any ideas what's wrong? Thanks!
Edit:
Looks like my system's more broken than I thought - external USB drives no longer show up under Nautilus (unless I mount them manually). Previously, when I was booting to x manually using startx, I had no such issues.
I would really appreciate it if someone could help troubleshoot this, thanks!

do you have polkit 107 from tomegun? Also make sure you compile NetworkManager with --with-session-tracking=systemd from the ABS.

d3Xt3r · 2012-09-16 06:27:19

65kid wrote:

[...]
do you have polkit 107 from tomegun? Also make sure you compile NetworkManager with --with-session-tracking=systemd from the ABS.

Thanks for the reply. I was using a rebuilt polkit from the repos, but after reading your reply I installed tomegun's polkit, and rebuilt NetworkManager. My USB drives still don't automount, but NetworkManager is now prompting for a password when trying to connect. Here are my pklas:

[nm-applet]
Identity=unix-group:network
Action=org.freedesktop.NetworkManager.*
ResultAny=yes
ResultInactive=no
ResultActive=yes

[Storage Permissions]
Identity=unix-group:storage
Action=org.freedesktop.udisks2.filesystem-mount;org.freedesktop.udisks2.modify-device
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Edit: Wow, nm just keeps on prompting me for my password for no reason, like I'm not even trying to connect (I'm already connected) and suddenly there's a password prompt.

Edit: Seems like it was trying to connect to APs it couldn't access. Removed the offending APs and now it's not prompting me anymore - well, unless if I try to connect manually, of course.

Last edited by d3Xt3r (2012-09-17 06:03:07)

nathan0n5ire · 2012-10-09 16:05:00

65kid wrote:

I actually got a proper systemd user session to work. Note that you will need the dbus user units from user-session-units and the patched dbus it depends on (and the systemd enabled polkit obviously).
I kind of mixed your method with user-session-units from Auke Kok. In xlogin@.service I start the systemd user-session instead of executing .xinitrc (also note that I removed the KillMode= here because control-group is actually the default). As far as I can see, the only big difference to Auke Kok's method is that we start X from the system session and not from the user session.
[Unit]
Description=systemd user session for user %I
After=graphical.target systemd-user-sessions.service
Wants=x@vt7.service

[Service]
User=%I
WorkingDirectory=/home/%I
Environment=DISPLAY=:0
TTYPath=/dev/tty7
PAMName=login
ExecStart=/usr/lib/systemd/systemd --user

[Install]
WantedBy=graphical.target
Then I created the following user units in ~/.config/systemd/user/ for my "stuff".
~/.config/systemd/user/default.target is symlinked to i3.target.
i3.target
[Unit]
Description=i3 Window Manager
Requires=dbus.socket
After=dbus.socket 
Wants=i3.service
AllowIsolate=yes
i3.service
[Unit]
Description=i3 Window Manager
After=dbus.socket

[Service]
ExecStart=/usr/bin/i3
nm-applet.service
[Service]
ExecStart=/usr/bin/nm-applet

[Install]
WantedBy=default.target
xrdb -merge.service
[Service]
Type=oneshot
ExecStart=/usr/bin/xrdb -merge .Xresources

[Install]
WantedBy=default.target
xcompmgr.service
[Service]
ExecStart=/usr/bin/xcompmgr

[Install]
WantedBy=default.target

Why is dbus necessary at all for the user session? I just dumped the dbus parts in the systemd user session files, and it ran almost perfectly for me (unfortuantly it doesnt seem to realize that I use /bin/zsh instead of /bin/bash for my shell anymore, but Im seeing if I can remedy that with an enviroment file).

65kid · 2012-10-09 16:33:37

nathan0n5ire wrote:

Why is dbus necessary at all for the user session? I just dumped the dbus parts in the systemd user session files, and it ran almost perfectly for me (unfortuantly it doesnt seem to realize that I use /bin/zsh instead of /bin/bash for my shell anymore, but Im seeing if I can remedy that with an enviroment file).

you are right, it seems to be not strictly necessary. Letting i3 depend on dbus as in my posted service file is actually non-sense since i3 itself doesn't need dbus at all. It is however necessary for nm-applet and I'm sure there a lot of other user services / applets which depend on dbus.

nathan0n5ire · 2012-10-09 19:54:31

hmm, nm-applet is working fine without an explicit user dbus service or socket for me. Actually its working better then fine -- when I was starting my X thru startx, and .xinitrc, nm-applet wasnt allowing me to disable wirless or networking (both of those options were grayed out) but now it allows me to do both.

Last edited by nathan0n5ire (2012-10-09 20:05:12)

65kid · 2012-10-09 20:03:02

then my guess is that you start the user dbus from somewhere else:

$ systemctl --user stop dbus.service dbus.socket
$ nm-applet

** (nm-applet:13768): WARNING **: Could not connect: Connection refused

** (nm-applet:13768): WARNING **: Failed to initialize D-Bus: Failed to connect to socket /run/user/1000/dbus/user_bus_socket: Connection refused

Arch Linux

#1 2012-08-29 12:12:41

Automatic X login without a DM

#2 2012-08-29 12:23:12

Re: Automatic X login without a DM

#3 2012-08-29 12:30:56

Re: Automatic X login without a DM

#4 2012-08-29 12:43:54

Re: Automatic X login without a DM

#5 2012-08-29 13:00:47

Re: Automatic X login without a DM

#6 2012-08-29 13:03:52

Re: Automatic X login without a DM

#7 2012-08-29 22:23:35

Re: Automatic X login without a DM

#8 2012-08-29 22:59:10

Re: Automatic X login without a DM

#9 2012-08-30 14:09:26

Re: Automatic X login without a DM

#10 2012-09-06 15:22:37

Re: Automatic X login without a DM

#11 2012-09-06 15:55:19

Re: Automatic X login without a DM

#12 2012-09-06 18:26:05

Re: Automatic X login without a DM

#13 2012-09-06 18:45:09

Re: Automatic X login without a DM

#14 2012-09-06 18:56:16

Re: Automatic X login without a DM

#15 2012-09-11 04:52:31

Re: Automatic X login without a DM

#16 2012-09-12 18:30:00

Re: Automatic X login without a DM

#17 2012-09-12 18:52:07

Re: Automatic X login without a DM

#18 2012-09-12 18:59:00

Re: Automatic X login without a DM

#19 2012-09-15 03:41:29

Re: Automatic X login without a DM

#20 2012-09-15 10:07:20

Re: Automatic X login without a DM

#21 2012-09-16 06:27:19

Re: Automatic X login without a DM

#22 2012-10-09 16:05:00

Re: Automatic X login without a DM

#23 2012-10-09 16:33:37

Re: Automatic X login without a DM

#24 2012-10-09 19:54:31

Re: Automatic X login without a DM

#25 2012-10-09 20:03:02

Re: Automatic X login without a DM

Board footer