Setting $DBUS_SESSION_BUS_*

swytch · n00b Joined: 16 Nov 2021 Posts: 8

I'm running into the following problem: $DBUS_SESSION_{ADDRESS,PID} are note set, which is breaking pinentry's behavior (it falls back to the ncurses version in the tty of Xorg, so I can't access the prompt).

Doing some research pointed out I have to call `startx` through `dbus-launch`, which I didn't do until now. So I update my .xinitrc from :

Anon-E-moose · Posted: Tue Nov 16, 2021 6:00 pm Post subject:

DBUS_SESSION_BUS_ADDRESS
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

swytch · n00b Joined: 16 Nov 2021 Posts: 8

Yeah it's a typo on my part, I don't get anything from tab when typing

Anon-E-moose · Posted: Tue Nov 16, 2021 7:10 pm Post subject:

swytch · n00b Joined: 16 Nov 2021 Posts: 8

I now realize the title is misleading -- I'll edit it. The DBUS_SESSION_BUS_* variable are not available when I open a session, be it tty which automatically launches Xorg or ttyX which stays in console-mode.

I thought they were set somewhere but not available to a terminal emulator for some obscure reason, which is why I talked about retrieving them rather than setting them: I assumed launching launching my window manager with dbus-launch would set those variables somewhere. But maybe it doesn't? I don't know.

Anyway replacing dbus-launch with dbus-run-session doesn't do the trick, and the variables are still unavailable... If they've ever been set.

Anon-E-moose · Posted: Tue Nov 16, 2021 10:42 pm Post subject:

dbus-run-session automatically sets it.

Not sure exactly how you're trying to run it.

Typically you would use it out of .xinitrc file (for startx) to start your window manager.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

swytch · n00b Joined: 16 Nov 2021 Posts: 8

I have

Anon-E-moose · Posted: Tue Nov 16, 2021 11:42 pm Post subject:

Probably doesn't work because you're using zsh. It behaves differently than bash.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

Anon-E-moose · Posted: Wed Nov 17, 2021 12:01 am Post subject:

From your original post (and next time you ask for help you might mention early on that you are using zsh) you have

/usr/bin/dbus-launch --sh-syntax --exit-with session /usr/local/bin/dwm

which uses sh/bash syntax, you might try it like this (not sure if it will work)

/usr/bin/dbus-launch --csh-syntax --exit-with session /usr/local/bin/dwm

(if I remember right csh syntax is similar to zsh)

If this doesn't work, do what I recommended earlier and read the man pages for dbus-*
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

swytch · n00b Joined: 16 Nov 2021 Posts: 8

I already tried with the --auto-syntax flag, didn't work. Neither does --csh-syntax. I also read the man pages which doesn't specify anything regarding zsh or how to troubleshoot my problem, which is, as I said, the variables not being set despite the "correct" command being ran.

I didn't specify I used zsh because it didn't work with bash either, so I thought the problem was with the xinitrc, not the shell. Thanks for the help!

Hu · Moderator Joined: 06 Mar 2007 Posts: 21602

Are these variables not set anywhere, or only not set in your terminal? Specifically, if you inspect the environment variables of the dwm process, are they set there? If no, then the problem is that they were not passed to dwm, so they cannot be passed to anything that dwm starts. If yes, then the variables are getting lost somewhere after dbus provided them.

As an aside, you can, and probably should, still use exec when triggering dbus-launch. Similarly, why are you running dwm out of /usr/local/bin?

swytch · n00b Joined: 16 Nov 2021 Posts: 8

> Similarly, why are you running dwm out of /usr/local/bin?

Good question. I used to exec dwm until yesterday, can't tell you why this time I provided the full path. If you're asking about the path, it's just the default path to install it from make install . I never bothered writing an ebuild, I have this on my todo list for 3 months now...

> if you inspect the environment variables of the dwm process

checking the process' proc/<pid>/environ show

Anon-E-moose · Posted: Wed Nov 17, 2021 12:02 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21602

Anon-E-moose · Posted: Wed Nov 17, 2021 5:05 pm Post subject:

Hu,

Running dbus-launch --sh-syntax returns

swytch · n00b Joined: 16 Nov 2021 Posts: 8

Hu · Moderator Joined: 06 Mar 2007 Posts: 21602

I suspect they are not truly children of init, but rather detached grandchildren of sxhkd. Probably what happens is that sxhkd forks into a process I will call sxhkd-wrapper. The wrapper then forks again. The grandchild executes the program you wanted. The wrapper then exits, and the kernel reparents the grandchild to init. This makes it look like init started the process. Despite this, their environment will come from the wrapper, which in turn inherited it from sxhkd. sxhkd or the wrapper might have modified the environment, including by dropping dbus variables, before executing the program you actually want. This double-fork+exec dance is fairly common when the parent (sxhkd) doesn't want to deal with having children hanging off it indefinitely. It only takes a few system calls, so if it happens, it is likely so quick that you cannot observe it without a tracing tool. Even a shell script likely wouldn't be fast enough to inspect the process list at the right time to see the extra layer, and a human has no chance of being fast enough.

swytch · n00b Joined: 16 Nov 2021 Posts: 8

I can't get info regarding the way env variables are handled. By looking at the code it doesn't look like they are dropped, but I'm no expert. Could they be dropped when changing parent ?

Hu · Moderator Joined: 06 Mar 2007 Posts: 21602

No. Environment variables are set when a process starts, and afterward can only be changed from within that process. Are the desired variables set in the long-lived sxhkd that receives your key presses? Or is there no such process, and dwm starts an sxhkd in response to a key press? Can you temporarily use some other launcher, to rule out that sxhkd is the guilty party?