start window manager with "dbus-launch"?

Message

djqwzlcsz · Post by **djqwzlcsz** » Sat Dec 19, 2020 11:44 pm

Hello,

on Debian I always had "exec bspwm" in my .xinitrc file to start my window manager with startx.
Since elogind was required to emerge x11-base/xorg-server I've read the Wiki page about elogind.
It says I should put "exec dbus-launch --exit-with-session <WINDOW_MANAGER>" in my .xinitrc.

How is the above different to just running "exec bspwm"? Which one is "better"? What will I gain?

eccerr0r · Post by **eccerr0r** » Sun Dec 20, 2020 12:00 am

You should have been able to disable elogind support if you don't want it, though I'm not sure about the consequences of doing such from your setup.

With the legacy windowmanagers out there which do not provide services to simplify access to console attached devices, there probably is no need for elogind/systemd support anyway, unless you run something that uses the support beyond the windowmanager, perhaps like one of the file managers from a full desktop environment.

Since it seems that you were "forced" to use elogind, then I'd say you should rebuild everything with USE=-elogind to revert to previous behavior and all is better - no need to set up a session through dbus.

Post by Hu » Sun Dec 20, 2020 12:19 am

The requested change runs a DBUS session, with your window manager and all the children thereof under it. This will give those processes access to a common DBUS session. Per eccerr0r's post, this may not actually gain you anything that you care about.

figueroa · Post by **figueroa** » Sun Dec 20, 2020 3:37 am

My .xintrc which I recommend. Substitute your own WM if you are not using openbox:

Code: Select all

setxkbmap -option terminate:ctrl_alt_bksp
xhost +local:root > /dev/null
/usr/bin/numlockx on
# ck-launch-sesssion in DEPRECATED
# ck-launch-session dbus-launch --sh-syntax --exit-with-session startlxde
# dbus-launch --sh-syntax --exit-with-session startxfce4
# dbus-launch --sh-syntax --exit-with-session startlxde
dbus-launch --sh-syntax --exit-with-session openbox-session

Refer questions to the dbus-launch man page. It's surprisingly informative. Likewise, the openbox and openbox-session man pages are helpful. openbox-session is what lightdm runs. Also, it's what x2go runs for remote sessions. /usr/bin/openbox-session is a script so you can read it. (Ignore that if openbox is not your WM.)

djqwzlcsz · Post by **djqwzlcsz** » Sun Dec 20, 2020 10:04 am

I've read the dbus-launch man page and honestly I didn't learn anything useful...
Yes it is a "a wrapper around the main X client" and it will "start a session bus instance of dbus-daemon".
But I can't imagine what that actually means...

The dbus-daemon man page was a little bit more informing.
So now I know dbus is something that makes various applications able to communicate with each other.

That't the theory. But I still don't know if I need that or not. What will I gain or loose?
Puhh...

Currently I'm running Gentoo in a VM anyway... guess I'll just go back some snapshots and try it with USE -elogind.
Guess I'll see if I miss anything or not.

btw. Yes I am using "one of the file managers from a full desktop environment". PCManFM... if that counts

Naib · Post by **Naib** » Sun Dec 20, 2020 10:33 am

You might not need it. You might not be running applications that need a user IPC (assuming it cannot use the system wide instance)

I have only ever used: windowmaker,openbox,awesomewm and then just launch the apps I want and thus without a classic DM that might require an IPC, I never did.
I recently switched to pipewire and it does need it so finally I have a need to launch a user dbus session.

So... You can either launch one as a just in case or wait until some application requires it to communicate with other applications

GDH-gentoo · Post by **GDH-gentoo** » Sun Dec 20, 2020 2:32 pm

Exactly. Using dbus-launch to start the window manager also launches a per-login session message bus. It doesn't matter whether you are using elogind (which connects the system-wide message bus, a different bus instance launched by the init system) or if Xorg is running as root. What matters is whether you are using applications that want to connect to the session bus. If you are using elogind, you can use busctl to find out:

Code: Select all

$ ps -eo pid,args
  PID COMMAND
  ...
  412 dbus-daemon --system --nofork --nopidfile
  ...
  450 elogind-daemon
  ...
  688 /bin/sh /usr/bin/startx
  705 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 -auth /tmp/serverauth.XXX
  ...
  772 /usr/bin/dbus-launch --exit-with-session /etc/X11/Sessions/openbox
  773 /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
  774 /usr/bin/openbox --startup /usr/libexec/openbox-autostart OPENBOX

Here, Openbox is started with dbus-launch, process 412 is the dbus-daemon process that implements the system-wide message bus, and process 773 is the one that implements the login session message bus, but...

Code: Select all

$ busctl --user
NAME                 PID PROCESS USER      CONNECTION UNIT SESSION DESCRIPTION
:1.4                 863 busctl  XXX       :1.4       c3   -       -          
org.freedesktop.DBus   - -       -         -          -    -       -

... nobody is actually connected to the session bus (other that busctl itself temporarily).

figueroa · Post by **figueroa** » Sun Dec 20, 2020 2:46 pm

GDH-gentoo wrote: ...

Thanks for those details. That deepens my understanding. From my perspective, elogind and dbus-launch are good things. These help your GUI login behave predictably, as intended, rather than waiting around for something to complain, or worse, fail.

eccerr0r · Post by **eccerr0r** » Sun Dec 20, 2020 4:41 pm

I know there are die hard classic UN*X environment fans out there that believe console should be just another unprivileged dumb terminal, and sometimes it's hard to keep them satisfied too. While software technology goes on, just keeping the "session/seat" deal going generally lets less problems show up ("go with the flow"), there indeed are situations that you simply don't need elogind/systemd services...

I'd view it more of not "wards off problems" but "provides a way to remove seams" but if the software you're using doesn't take advantage of the seam removal, then these services are just adding more bloat. Generally I also view the console/session/seat paradigm a "good thing" and "useful" as well, but sometimes it's simply not necessary. It's up to the person setting up the machine to decide.

Question still remains - what downstream software is being used that could possibly take advantage of the console. If the person just wants to treat the console as a dumb video terminal and nothing else (no disk drives, no USB ports, no sound, etc.) and the software has its own way to communicate among its pieces (own shared memory mechanisms) then these are not necessary.

(One example that I find that's a wonderful use of dbus that's not strictly console related is the screen saver. Using the dbus api, a movie player application can trigger the screensaver to not kick in, but once the movie player exits, it will no longer trigger the screensaver and the screensaver can then turn off the display. Nothing is more annoying than watching a movie and the screensaver kicks in, but you wouldn't (always) want something like gkrellm to keep the screen from blanking/shutting down when you're not there.)

figueroa · Post by **figueroa** » Mon Dec 21, 2020 3:36 am

I've got 8 threads in 4 cores + 16 GB RAM. Why would I care about a few bytes of memory and a bogomip here or there. The default recommended configuration works well for me and will probably be best for most user. I don't think it's a good use of my time avoid elogind and dbus. I accept their benefits and I'm happy about it. On most days, I consider it a miracle when the GUI shows up after I log back in.

djqwzlcsz · Post by **djqwzlcsz** » Mon Dec 21, 2020 4:01 pm

figueroa wrote:I don't think it's a good use of my time avoid elogind and dbus.

I want to understand what things do, before using them or even relying on them. And for now I barely understand dbus/elogind.

Okay, I tried what you guys said and disabled elogind and systemd use flags.

If I try to run startx I'll get: Cannot open /dev/tty0/ (permission denied)

According to this reddit post either elogind or dbus is required:
https://www.reddit.com/r/Gentoo/comment ... rmissions/
Also the "Non root Xorg" wiki page says something similar.

btw. I've emerged xorg with -suid flag.
(Had this in my notes for rootless xorg from when I tried Gentoo 10 months ago...)
(Also old wiki pages mentions it: https://wiki.gentoo.org/index.php?title ... did=884856)

I guess this has changed since then.

So from what I understand I now have to either enable elogind (globally) or suid (for xorg-server) use flag, right?
Want to make sure first since compiling whole Xorg on that notebook takes a while.

edit: Hmm tested it in a VM and even with elogind flag enabled I get this error message.

that's the whole log if it helps, maybe its just a config problem? I used the config files from my debian system, but those are only for the window manager stuff etc. I didn't do any special Xorg config other than setting my keyboard layout. Is something else required? Used the Xorg Guide from the wiki.

Code: Select all

[    44.096] 
X.Org X Server 1.20.10
X Protocol Version 11, Revision 0
[    44.097] Build Operating System: Linux 5.4.80-gentoo-r1-x86_64 x86_64 Gentoo
[    44.098] Current Operating System: Linux gentoo 5.4.80-gentoo-r1-x86_64 #1 SMP Sat Dec 19 16:36:06 CET 2020 x86_64
[    44.098] Kernel command line: BOOT_IMAGE=/vmlinuz-5.4.80-gentoo-r1-x86_64 root=/dev/mapper/gentoo-root ro dolvm crypt_root=UUID=fe28b5a9-a9b2-47b4-81ab-878ff62b86c4 root_trim=yes
[    44.099] Build Date: 21 December 2020  05:15:08PM
[    44.100]  
[    44.100] Current version of pixman: 0.40.0
[    44.101]    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
[    44.101] Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    44.104] (==) Log file: "/home/user/.local/share/xorg/Xorg.0.log", Time: Mon Dec 21 17:18:58 2020
[    44.104] (==) Using config directory: "/etc/X11/xorg.conf.d"
[    44.105] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[    44.105] (==) No Layout section.  Using the first Screen section.
[    44.105] (==) No screen section available. Using defaults.
[    44.105] (**) |-->Screen "Default Screen Section" (0)
[    44.105] (**) |   |-->Monitor "<default monitor>"
[    44.105] (==) No monitor specified for screen "Default Screen Section".
    Using a default monitor configuration.
[    44.105] (==) Automatically adding devices
[    44.105] (==) Automatically enabling devices
[    44.105] (==) Automatically adding GPU devices
[    44.105] (==) Max clients allowed: 256, resource mask: 0x1fffff
[    44.105] (WW) The directory "/usr/share/fonts/misc/" does not exist.
[    44.105]    Entry deleted from font path.
[    44.105] (WW) The directory "/usr/share/fonts/TTF/" does not exist.
[    44.105]    Entry deleted from font path.
[    44.105] (WW) The directory "/usr/share/fonts/OTF/" does not exist.
[    44.105]    Entry deleted from font path.
[    44.105] (WW) The directory "/usr/share/fonts/Type1/" does not exist.
[    44.105]    Entry deleted from font path.
[    44.105] (WW) The directory "/usr/share/fonts/100dpi/" does not exist.
[    44.105]    Entry deleted from font path.
[    44.105] (WW) The directory "/usr/share/fonts/75dpi/" does not exist.
[    44.105]    Entry deleted from font path.
[    44.105] (==) FontPath set to:
    
[    44.105] (==) ModulePath set to "/usr/lib64/xorg/modules"
[    44.105] (II) The server relies on udev to provide the list of input devices.
    If no devices become available, reconfigure udev or disable AutoAddDevices.
[    44.105] (II) Loader magic: 0x5643c9ec8ce0
[    44.105] (II) Module ABI versions:
[    44.105]    X.Org ANSI C Emulation: 0.4
[    44.105]    X.Org Video Driver: 24.1
[    44.105]    X.Org XInput driver : 24.1
[    44.105]    X.Org Server Extension : 10.0
[    44.105] (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory)
[    44.106] (II) xfree86: Adding drm device (/dev/dri/card0)
[    44.107] (--) PCI:*(0@0:2:0) 15ad:0405:15ad:0405 rev 0, Mem @ 0xe0000000/134217728, 0xe8c00000/2097152, I/O @ 0x0000c160/16, BIOS @ 0x????????/131072
[    44.107] (II) LoadModule: "glx"
[    44.107] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[    44.108] (II) Module glx: vendor="X.Org Foundation"
[    44.108]    compiled for 1.20.10, module version = 1.0.0
[    44.108]    ABI class: X.Org Server Extension, version 10.0
[    44.108] (==) Matched vmware as autoconfigured driver 0
[    44.108] (==) Matched modesetting as autoconfigured driver 1
[    44.108] (==) Matched fbdev as autoconfigured driver 2
[    44.108] (==) Matched vesa as autoconfigured driver 3
[    44.108] (==) Assigned the driver to the xf86ConfigLayout
[    44.108] (II) LoadModule: "vmware"
[    44.108] (II) Loading /usr/lib64/xorg/modules/drivers/vmware_drv.so
[    44.126] (II) Module vmware: vendor="X.Org Foundation"
[    44.126]    compiled for 1.20.10, module version = 13.3.0
[    44.126]    Module class: X.Org Video Driver
[    44.126]    ABI class: X.Org Video Driver, version 24.1
[    44.126] (II) LoadModule: "modesetting"
[    44.126] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
[    44.126] (II) Module modesetting: vendor="X.Org Foundation"
[    44.126]    compiled for 1.20.10, module version = 1.20.10
[    44.126]    Module class: X.Org Video Driver
[    44.126]    ABI class: X.Org Video Driver, version 24.1
[    44.126] (II) LoadModule: "fbdev"
[    44.126] (WW) Warning, couldn't open module fbdev
[    44.126] (EE) Failed to load module "fbdev" (module does not exist, 0)
[    44.126] (II) LoadModule: "vesa"
[    44.126] (WW) Warning, couldn't open module vesa
[    44.126] (EE) Failed to load module "vesa" (module does not exist, 0)
[    44.126] (II) vmware: driver for VMware SVGA: vmware0405, vmware0710
[    44.126] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    44.126] (EE) 
Fatal server error:
[    44.127] (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied)
[    44.127] (EE) 
[    44.128] (EE) 
Please consult the The X.Org Foundation support 
     at http://wiki.x.org
 for help. 
[    44.129] (EE) Please also check the log file at "/home/user/.local/share/xorg/Xorg.0.log" for additional information.
[    44.129] (EE) 
[    44.130] (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
[    44.130] (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor
[    44.130] (EE) Server terminated with error (1). Closing log file.

figueroa · Post by **figueroa** » Mon Dec 21, 2020 4:23 pm

If you read your unread news you'll find the answers.

Code: Select all

eselelec news read new | more

If you already read the news, but did not heed:

Code: Select all

eselelec news read all | more

Look for the elogind article especially.

djqwzlcsz · Post by **djqwzlcsz** » Mon Dec 21, 2020 4:27 pm

Yes I've already read that.
It says I should just enable elogind or suid.
But it doesn't work.

EDIT:
hmm... if I run "startx -- vt1" instead of "startx" this works fine and my X starts...
Is it required to do this on Gentoo or do I have any problem in my configs?

Post by Hu » Mon Dec 21, 2020 4:50 pm

How did you enable elogind? Does the command mentioned in the news indicate that you have a session open?

djqwzlcsz · Post by **djqwzlcsz** » Mon Dec 21, 2020 5:01 pm

I added USE="elogind" to "/etc/portage/make.conf" and then did a "emerge --ask --changed-use --deep @world".

No it didn't say I have a session open.
This should say I have a session open after I login via tty? Or only after starting X?

btw. the command "startx -- vt1" also works when I emerged xorg-server without elogind, systemd or suid.
(-elogind -systemd in make.conf and xserver-xorg -suid in package.use)

well now I'm completely 100% confused.

Post by Hu » Mon Dec 21, 2020 7:35 pm

You need a session to be able to start X without special arguments. From your lack of mention, I think you neither set elogind to start on boot, nor started it manually. Please run rc-update add elogind default ; /etc/init.d/elogind start as root, then log in as your regular user at a text console and try again.

GDH-gentoo · Post by **GDH-gentoo** » Mon Dec 21, 2020 10:44 pm

djqwzlcsz wrote:I want to understand what things do, before using them or even relying on them. And for now I barely understand dbus/elogind.

djqwzlcsz wrote:well now I'm completely 100% confused.

Let's try to clarify.

1)

djqwzlcsz wrote:So from what I understand I now have to either enable elogind (globally) or suid (for xorg-server) use flag, right?

Yes. Installing x11-base/xorg-server with both USE flags unset should not work: Xorg would complain that it doesn't have enough privileges to open the /dev/dri/card* and /dev/input/* special files. If it is installed with elogind set, the elogind daemon will open those files on Xorg's behalf. If it is installed with suid set, Xorg will have the required privileges to do that itself.

For desktop profiles, x11-base/xorg-server will be installed with the elogind USE flag set and the suid USE flag unset by default, so there is no need to modify /etc/portage/make.conf or /etc/portage/package.use in that case. sys-apps/dbus and sys-auth/elogind will be installed as dependencies.

2) Having elogind installed is not enough, you must either add service elogind to OpenRC's boot runlevel, or service dbus to OpenRC's default runlevel. This is probably what's missing, and Hu explained how to do this. You can check the result using the rc-status -a command.

3) If x11-base/xorg-server is installed with the elogind USE flag set, the X server must use the same terminal that you are using to run startx. Again, because it doesn't have enough privileges to open the /dev/tty* special files. This requires passing specific options in the command line. If you are using Gentoo's default xserverrc file (/etc/X11/xinit/xserverrc), it will do that for you, but will only work if elogind is working properly in turn. "Working properly" means that you should have a session after logging in, which you can find out using the loginctl command, and variable XDG_VTNR should be present in the environment.

Hu wrote:Please run rc-update add elogind default [...]

The ebuild asks users to use the boot runlevel instead: rc-update add elogind boot.

djqwzlcsz · Post by **djqwzlcsz** » Tue Dec 22, 2020 3:42 pm

Thank you all for taking the time to help me with this issue.

I'm not using a desktop profile but the hardened profile instead.
So I've to set the flags manually.

I've done the following now:
Add elogind use flag to make.conf
Add -suid for x11-base/xorg-server in package.use
emerge --ask --verbose --update --deep --newuse --quiet @world
rc-update add elogind boot

After a reboot loginctl shows that I have a session.
"startx" worked without any special arguments.

However XDG_VTNR is not set.

Code: Select all

~ $ printenv | grep -i XDG
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
XDG_SESSION_ID=1
XDG_RUNTIME_DIR=/run/user/1000

But everything seems to work just fine now.

(btw. I think this forum is clearly missing a inline code formatting.

)

GDH-gentoo · Post by **GDH-gentoo** » Tue Dec 22, 2020 10:50 pm

djqwzlcsz wrote:

Code: Select all

~ $ printenv | grep -i XDG
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
XDG_SESSION_ID=1
XDG_RUNTIME_DIR=/run/user/1000

Strange, I have more. For a tty login:

Code: Select all

$ printenv | grep -i XDG
XDG_SEAT=seat0
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
XDG_VTNR=1
XDG_SESSION_ID=c3
XDG_RUNTIME_DIR=/run/user/1000

For a GUI login (SDDM):

Code: Select all

$ printenv | grep -i XDG
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
XDG_SEAT=seat0
XDG_SESSION_DESKTOP=
XDG_SESSION_TYPE=x11
XDG_CURRENT_DESKTOP=
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_VTNR=7
XDG_SESSION_ID=c2
XDG_RUNTIME_DIR=/run/user/1000

But this is handled by PAM magic and I'm using a desktop profile. I don't know about hardened profiles.

figueroa · Post by **figueroa** » Wed Dec 23, 2020 2:27 am

For what it's worth, under lightdm:

Code: Select all

$ env | grep XDG
XDG_CONFIG_DIRS=/etc/xdg
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session14
XDG_SEAT=seat0
XDG_SESSION_DESKTOP=openbox
XDG_SESSION_TYPE=x11
XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/figueroa
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_VTNR=7
XDG_SESSION_ID=86
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_DIRS=/usr/local/share:/usr/share

djqwzlcsz · Post by **djqwzlcsz** » Wed Dec 23, 2020 4:25 pm

Oh I know what it was.

via SSH:

Code: Select all

XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
XDG_SESSION_ID=2
XDG_RUNTIME_DIR=/run/user/1000

On the machine itself:

Code: Select all

XDG_SEAT=seat0
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
XDG_VTNR=1
XDG_SESSION_ID=1
XDG_RUNTIME_DIR=/run/user/1000

eccerr0r · Post by **eccerr0r** » Wed Dec 23, 2020 4:51 pm

Yeah, one thing about the logind seats is that it makes sessions real clear that it's a child of remote access or from a terminal emulator on console in X.

Both are assigned a pseudo teletype (pty) but only one of these gets console access through polkit.