Setting $DBUS_SESSION_BUS_*

[swytch]

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]

DBUS_SESSION_BUS_ADDRESS
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

[swytch]

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

[Anon-E-moose]

[swytch]

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]

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.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

[swytch]

I have

[Anon-E-moose]

Probably doesn't work because you're using zsh. It behaves differently than bash.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

[Anon-E-moose]

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-*
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

[swytch]

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]

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]

> 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]

[Hu]

[Anon-E-moose]

Hu,

Running dbus-launch --sh-syntax returns

[swytch]

[Hu]

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]

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]

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?