User:xxc3nsoredxx/Running without logind

This page describes an experimental and unsupported method of setting up an installation without logind.

elogind

logind is the login seat/session tracker used by systemd. elogind is a standalone version of logind that is used to provide support for software such as GNOME, which depends on certain systemd components, without requiring the user to install all of systemd. Removing elogind will prevent the use of such software. Some other use cases for elogind are Handling sleep/hibernation and running Xorg as a non-root user.

Disabling elogind

The system should be booted without starting elogind before it is removed:

root #rc-update del elogind boot

root #reboot

Important
Any graphical services, such as a display manager, need to be disabled as well.

Removing elogind

The elogind USE flag needs to be disabled:

FILE /etc/portage/make.conf

USE="-elogind -systemd"

If it's enabled on a package-basis, remove it from /etc/portage/package.use/ as needed.

Anything that was previously built with the USE flag enabled needs to be rebuilt:

root #emerge --ask --deep --changed-use @world

Once that is complete, unnecessary packages (including sys-auth/elogind) need to be removed:

root #emerge --ask --depclean

Reboot and poweroff

TODO: loginctl reboot and loginctl poweroff

Sleep and hibernation

TODO: /etc/elogind/logind.conf and /lib64/elogind/system-sleep/

Xorg

Warning
Since this isn't a sanctioned method for running Xorg, it is up to the user to solve any issues arising from following these instructions. To avoid unneeded headache and to receive better support it is recommended to use one of the official methods instead:

Note
This section assumes the user is logged in on tty1.

It is also possible to run an X server as a non-root user without using a logind provider. The default behavior for Xorg is to find the first available virtual terminal (tty) and to attempt to use that. This can cause issues if the tty is owned by root, which is the default unless another user is currently logged in on it. Attempting to run startx at this point will cause an error similar to this:

FILE ~/.local/share/xorg/Xorg.0.log

[   535.573] (--) using VT number 7
... snip ...
[   535.598] (EE)
Fatal server error:
[   535.598] (EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied)
[   535.598] (EE)
[   535.598] (EE)

user $ls -alF /dev/tty{1,7}

crw-------. 1 user tty 4, 1 Jan 23 17:46 /dev/tty1
crw--w----. 1 root tty 4, 7 Jan 23 17:35 /dev/tty7

Xorg provides a vtXX option, where XX refers to the tty to use. Running startx -- vt1 will launch Xorg inside tty1 which is owned by user. The -- argument is important since it marks the end of client arguments and the start of server options. In order to avoid having to manually specify (and remember) the currently active tty a line similar to the following can be added to the user's .bashrc:

FILE ~/.bashrc

alias startx="startx -- vt$(tty | sed -e 's|/dev/tty||')"

After re-sourcing the .bashrc or logging out and logging back in, running startx will launch Xorg in the currently active tty. Switching to tty2 and doing the same will launch a second instance inside that tty, both of which are running as user.

Troubleshooting

Framebuffer "Permission denied"

If starting Xorg as root works, but not as user, and the log file mentioned in the startx error contains the following line, then user cannot access the raw framebuffer device.

FILE Xorg.0.log

'"`UNIQ--pre-00000009-QINU`"'

This can be fixed by adding user to the video group. In order to apply the new permissions, user must log out and log back in.

root #

ls -l /dev/fb0

crw-rw----. 1 root video 29, 0 Apr 26 19:39 /dev/fb0