Setting environment variables from dinit services

[softexpert]

Hello @davmac314 ,

I hope you are well!

While tinkering with my Artix system, I realized that whenever I start a user service that will create a socket, I am unable to update an environment variable that is valid for the entire duration of the user session.

Perhaps there is already a way of doing this, but so far I could not find it.

Taking a concrete example, after starting the dbus user service, I need to set the value of DBUS_SESSION_BUS_ADDRESS with the actual socket path (usually unix:path=/run/user/1000/bus)

The content of dbus service file is:

# dbus session bus user service

type               = process
command            = /usr/lib/dinit/user/dbus --print-address=4
ready-notification = pipefd:4

The hacky way is to set the value of DBUS_SESSION_BUS_ADDRESS outside of the dinit service mechanism, but it would be great to achieve this dynamically through standard dinit features.

Is there a solution for this problem?

Thank you in advance for any feedback!

[softexpert]

Adding more context to the example provided.

The content of /usr/lib/dinit/user/dbus is:

#!/bin/sh

export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/`id -u`/bus"

# export into activation environment to make it visible to other services
dinitctl setenv DBUS_SESSION_BUS_ADDRESS || :

exec dbus-daemon --session --address="$DBUS_SESSION_BUS_ADDRESS" "$@"

After the user session is started, DBUS_SESSION_BUS_ADDRESS remains empty, although dinitctl --user list shows dbus is started.

[{+}     ] dbus (pid: 1507)

The socket is created:

❯ ls -la /run/user/1000/bus
srwxrwxrwx 1 username username 0 Jul 18 08:06 /run/user/1000/bus

It would be great to have a specific instruction set in the service description file that ensures the provided environment variable is set after the process is started, using some output the process has produced.

Is this feasible or the approach is wrong?

edited to add more context.

[davmac314]

DBUS_SESSION_BUS_ADDRESS remains empty

How did you check that?

It seems to work for me, tested with:

dragon:~/.config/dinit.d$ cat set-funky
type = process
command = /home/davmac/.config/dinit.d/set-funky.sh
ready-notification = pipefd:4
dragon:~/.config/dinit.d$ 
dragon:~/.config/dinit.d$ cat set-funky.sh 
#!/bin/sh
export FUNKY=funky_is_set
dinitctl setenv FUNKY || :
echo "ready!" >&4
sleep 100
dragon:~/.config/dinit.d$ 
dragon:~/.config/dinit.d$ 
dragon:~/.config/dinit.d$ cat print-funky 
type = scripted
command = sh -c "echo $$FUNKY"
log-type = buffer
depends-on: set-funky
dragon:~/.config/dinit.d$ 
dragon:~/.config/dinit.d$ 
dragon:~/.config/dinit.d$ dinitctl list
[[+]     ] boot
dragon:~/.config/dinit.d$ dinitctl start print-funky 
Service 'print-funky' started.
dragon:~/.config/dinit.d$ 
dragon:~/.config/dinit.d$ dinitctl catlog print-funky 
funky_is_set
dragon:~/.config/dinit.d$ 

That said, for DBUS_SESSION_BUS_ADDRESS it really should be set to something specific by the user session launcher (turnstile or other PAM module for example). Trying to let the daemon choose an address is brittle.

[softexpert]

Edit: if your terminal is running inside a graphical session that is being managed by dinit and which is started after the dbus service (i.e. has a dependency on it) then it should work. I'm guessing this is not the case for you though?

My user-level dinit instance is launched after the start of the graphical session (using userspawn).

If I understand correctly, it would be necessary to have the login manager start the user-level dinit instance and have this new dinit instance launch the graphical session - thus being able to share the environment variables with it?

[davmac314]

If I understand correctly, it would be necessary to have the login manager start the user-level dinit instance and have this new dinit instance launch the graphical session - thus being able to share the environment variables with it?

Yes. And I think that's exactly what happens in Chimera (using turnstile).

[softexpert]

Yes. And I think that's exactly what happens in Chimera (using turnstile).

That's a tough one.

I think the need is closely related to #565.

We need a system agnostic way of detecting when a user session is about to open and delegate to dinit the responsibility of starting the user-level instance and starting the graphical session.
This would make it possible to set environment variables at the session level.

[davmac314]

We need a system agnostic way [...] This would make it possible to set environment variables at the session level.

Or, not rely on things like socket paths being chosen non-deterministically and so avoid the need to have user services set session-level environment variables. That would be my favoured approach, where possible; it's far less brittle.

There's no system-agnostic way to detect when a user session is about to open. On Linux you can use PAM, assuming that the login utilities support it (eg busybox login utilities can be built without support for PAM). It seems you can also use the (e)logind interface, if that's available (it probably relies on PAM under the hood anyway). Neither are guaranteed, even on a Linux system.

[softexpert]

We need a system agnostic way [...] This would make it possible to set environment variables at the session level.

Or, not rely on things like socket paths being chosen non-deterministically and so avoid the need to have user services set session-level environment variables. That would be my favoured approach, where possible; it's far less brittle.

There's no system-agnostic way to detect when a user session is about to open. On Linux you can use PAM, assuming that the login utilities support it (eg busybox login utilities can be built without support for PAM). It seems you can also use the (e)logind interface, if that's available (it probably relies on PAM under the hood anyway). Neither are guaranteed, even on a Linux system.

I understand a bit better now the situation, thank you for the explanation!

So, the most reliable (and system-agnostic) approach is to define as early as possible the environment variables and use them as parameters when launching the services.