# 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 :

```

...

exec dwm

```

to

```

...

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

```

But the problem is not solved, and I still cannot  run

```
$ echo $DBUS_SESSION_BUS_ADDRESS
```

Any idea of what I'm doing wrong ?

EDIT: running 

```
 eval $(dbus-launch --sh-syntax)
```

 from a terminal does solve the problem, but then I have to manually run this each time

EDIT2: changed the title, which was misleadingLast edited by swytch on Tue Nov 16, 2021 10:16 pm; edited 2 times in total

----------

## Anon-E-moose

DBUS_SESSION_BUS_ADDRESS

----------

## swytch

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

```
 $ echo $DBUS 
```

----------

## Anon-E-moose

```
$ set|grep DBUS

DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-e4e87bFNuK,guid=6be7b55c85518c0cc1ed391261938a22
```

From within the session.

Edit to add: man is your friend -- man dbus-launch

 *Quote:*   

> To start a D-Bus session within a text-mode session, do not use dbus-launch. Instead, see dbus-run-session(1).

 

ETA2: I prefer dbus-run-session to dbus-launch, but that's just me.

dbus-run-session -- <some program>

----------

## 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.

----------

## swytch

I have 

```

# startx at session login

[ "$(tty)" = "/dev/tty1" ] && ! pgrep -x Xorg >/dev/null && startx "$XINITRC"

```

at the end of my .zlogin, to automatically run startx when login on tty1 (taken from the archwiki)

and in $XINITRC, I have

```

...

# default stuff, xrdb and xmodmap, sourcing xprofile

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

```

This piece of code is ran, since I am in my window manager, and of course I can see it with ps :

```

swytch    2097  0.0  0.0   4492  2084 tty1     S    Nov16   0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session /usr/local/bin/dwm

```

Still, the DBUS variables are not set, or at least not available when I fire up a terminal window (st, in my case) unless I run export $(dbus-launch)

It appears that something else has launched dbus, yet I don't know what it is. It's not launched through rc-update, that I am sure of.

```

swytch    1927  0.0  0.0   4492  2132 tty1     S    Nov16   0:00 dbus-launch --autolaunch=93a2856c1c5cc99ed3e7f04161338fd6 --binary-syntax --close-stderr

```

Since the PID is smaller than the command I set up, it means it is launched before; maybe this explains the issue?

----------

## Anon-E-moose

Probably doesn't work because you're using zsh. It behaves differently than bash.

----------

## 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-*

----------

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

```
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-10QppGL9Tj,guid=a94520113aeb1464580357cf6194cd0f
```

So the variable is set. It's just not available to anything else, it seems

I fixed it by putting 

```
eval $(dbus-launch --sh-syntax --exit-with-session)
```

 into .xprofile, and the variable is passed to child processes. Not all processes sadly, as if I try to st -e "neomutt" for instance, then neomutt cannot see the variables. I guess it's because the -e flags makes st executing neomutt instead of the shell, as per the man page:

```

-e command [ arguments ... ]

              st  executes command instead of the shell.

```

I don't know what it means to open a terminal window without a shell, but I know zsh is not launched, because my .zshrc is not sourced. Now the trick is to launch neomutt through a tmux session, and then it works. It's clunky, tho

----------

## Anon-E-moose

```
             ## test for an existing bus daemon, just to be safe

             if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then

                 ## if not found, launch a new one

                 eval `dbus-launch --sh-syntax`

                 echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS"

             fi
```

From the dbus-launch man page  NOTICE THE BACKTICKS ON eval

If you had put this in your .xinitrc file it should have solved your problems even if running zsh,

Edit to add:

 *Quote:*   

> and the variable is passed to child processes. Not all processes sadly,

 

Probably because you aren't "exporting" the variable after you create it.

----------

## Hu

 *swytch wrote:*   

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

 The forum has a quote tag for nicer quoting presentation, with attributions. *swytch wrote:*   

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

 I was asking about why you are using the out-of-Portage version, yes.  Gentoo already ships an ebuild for dwm, including one for a live ebuild, so there is no need to write your own. *swytch wrote:*   

> > if you inspect the environment variables of the dwm process
> 
> checking the process' proc/<pid>/environ  show 
> 
> ```
> ...

 Interesting.  Is the variable present in the immediate child processes of dwm?  If yes, what about their children, and so on down?  We need to find the first layer at which it is absent. *swytch wrote:*   

> I fixed it by putting 
> 
> ```
> eval $(dbus-launch --sh-syntax --exit-with-session)
> ```
> ...

 Right.  This only sets it in shells that evaluate that dotfile, and children who inherit it from such shells. *swytch wrote:*   

> Not all processes sadly, as if I try to st -e "neomutt" for instance, then neomutt cannot see the variables. I guess it's because the -e flags makes st executing neomutt instead of the shell, as per the man page:

 Correct.  You could try using st -e "/bin/sh -c 'eval $(dbus-launch --sh-syntax --exit-with-session); neomutt'. *swytch wrote:*   

> 
> 
> I don't know what it means to open a terminal window without a shell, but I know zsh is not launched, because my .zshrc is not sourced.

 Most terminal emulators can run any terminal-oriented program.  It's traditional to run a shell as the first level child so that you can run arbitrary other terminal programs from there, but if you like having a terminal that is always and only neomutt, and which exits when neomutt does, then running neomutt directly is fine. *swytch wrote:*   

> Now the trick is to launch neomutt through a tmux session, and then it works.

 This probably only works because tmux has the relevant environment variable set, and passes it down. *Anon-E-moose wrote:*   

> 
> 
> ```
>                  eval `dbus-launch --sh-syntax`
> ```
> ...

 Backticks are an older, and somewhat less readable (in my opinion), alternative to the use $( ... ) that OP is using.  OP's problem is not backticks versus nothing; the problem is that OP has found a way to run a program that either never tries to load the dbus variables, or that subsequently unsets them. *Anon-E-moose wrote:*   

> If you had put this in your .xinitrc file it should have solved your problems even if running zsh,

 Maybe.  If OP has a program in the chain that is unsetting environment variables, either explicitly these or indiscriminately by discarding all variables not an approved list, then setting the dbus variables in xinitrc would not help, because that program would just discard them from here too. *Anon-E-moose wrote:*   

>  *Quote:*   and the variable is passed to child processes. Not all processes sadly, Probably because you aren't "exporting" the variable after you create it.

 If the variable is not marked for export, then the shell should not pass it to any child process.  OP seems to be reporting that it is sometimes exported.  I would expect that when dbus-launch is invoked wit --sh-syntax, it ought to include export in the output tokens that it wants evaluated.

----------

## Anon-E-moose

Hu,

Running dbus-launch --sh-syntax returns

```
DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-gY6lBnOsjI,guid=65e298ea21c841e7a5a5273861953367';

export DBUS_SESSION_BUS_ADDRESS;

DBUS_SESSION_BUS_PID=30358;
```

running eval $( dbus-launch --sh-syntax ) sets

```
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-xrYXvsswgD,guid=c578a0ecea7e79539d574f29619533bd

DBUS_SESSION_BUS_PID=30439
```

Not sure exactly how he's using all this, but for programs like ssh, sudo and I'm sure others don't pass through a complete environment.

It's also possible that something is unsetting the DBUS vars, though I find that unlikely.

I don't use zsh so I'm not familiar with it, though they do export vars the same way bash does. 

So firing up dwm, by way of startx should have the DBUS vars, if the eval is done in .xinitrc.

You can also run it our of your login profile, it'll just always be there until killed.

Does  bring up a question though, he's checking to see the DBUS vars being set, is he checking to see if the dbus-launch program is still running.

----------

## swytch

 *Hu wrote:*   

> 
> 
> I was asking about why you are using the out-of-Portage version, yes.  Gentoo already ships an ebuild for dwm, including one for a live ebuild, so there is no need to write your own.

 

It's just that I found it easier to have my own git repo for suckless' tools that I use across my 2 machines. One is still running Arch. It's a 3 year-old repo, I just have to take the time to see what's the better way to manage it  :Very Happy: 

 *Hu wrote:*   

> 
> 
> Interesting.  Is the variable present in the immediate child processes of dwm? 

 

Okay this is leading somewhere. I run sxhkd to launch my programs through keybindings. This launches programs as childs of init instead of dwm, so of course they cannot see the variables! Now I don't know if it's supposed to work this way or not, because sxhkd is a child of dwm. I'll see if I find answers. Good job!

----------

## 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?

----------

