Session's environment variables

asked 2014-07-05 01:36:19 +0000

273 ●8 ●14 ●26

updated 2014-07-05 11:21:05 +0000

Related materials

As I can confirm after multiple failures, according to “How do I set an environmental variable for a GNOME session? (superuser.com)”, setting environment variables in a session is tricky, as there are multiple candidate places for this.

I had a look at “How do xsession, xinitrc and .i3/config play together?”, which is very valuable, but did not help.

Practical case

For the practical case, I need to properly set an SSH_AUTH_SOCK environment variable (which is set, except not with the expected value, by another process).

From a command line, I can do this, which gives me what I expect.

export $(gnome-keyring-daemon --start --components=ssh)

I tried this in ~/.config/i3/config:

exec --no-startup-id eval $(gnome-keyring-daemon --start --components=ssh)
exec --no-startup-id export $(gnome-keyring-daemon -s)

I tried this in ~/.profile:

if [ "$0" = "/etc/gdm/Xsession" ]; then
    eval $(gnome-keyring-daemon --start --components=ssh)
    export $(gnome-keyring-daemon -s)
fi

I tried this in a ~/.xsession:

 eval $(gnome-keyring-daemon --start --components=ssh)
 export $(gnome-keyring-daemon -s)

None works.

Question

Seems one can't set and export an environment variable from i3's config. If I'm wrong, what was wrong in my config? If I'm not wrong, what's the best practice to define environment variables for an i3 session?

Notes (update 1)

At least ~/.xsession does not seems to be sourced for me, running Ubnuntu 12.04, which uses LightDM for the login screen. Prior Ubuntu version used GDM and there are complaints on the web about GDM ignoring ~/.xsession too.

edit retag flag offensive close merge delete

Comments

-edit- Wanted to link to https://faq.i3wm.org/question/18/how-do-xsession-xinitrc-and-i3config-play-together/ but that link is already in the question.

joepd ( 2014-07-05 23:30:18 +0000 )edit

add a comment

2 answers

Sort by » oldest newest most voted

answered 2014-07-05 03:18:01 +0000

Hibou57

273 ●8 ●14 ●26

updated 2014-07-05 04:14:08 +0000

The safest way seems to be using ~/.profile, however, this requires some prior investigation, explained here.

This, posted in the question, was wrong:

if [ "$0" = "/etc/gdm/Xsession" ]; then
    eval $(gnome-keyring-daemon --start --components=ssh)
    export $(gnome-keyring-daemon -s)
fi

This appeared to be wrong due to the test. To figure what to do with ~/.profile within one's environment, a gentle trick is to first add this in ~/.profile:

LOG="$HOME/profile-invocations"
echo "-----" >>$LOG
echo "Caller: $0" >>$LOG
echo "DESKTOP_SESSION: $DESKTOP_SESSION" >>$LOG
echo "GDMSESSION: $GDMSESSION" >>$LOG

After a login, looking at ~/profile-invocations will tell what's the test to be used. For Ubuntu 12.04, the test have to be "$0" = "/usr/sbin/lightdm-session". Additionally, one may want to avoid redefining some things already defined by the current session prior to the invocation of ~/.profile. As an example, an Ubuntu session will have an already properly defined SSH_AUTH_SOCK which one may not want to override. An additional test on the $DESKTOP_SESSION seems recommended (I guess it's better to test $DESKTOP_SESSION than $GDMSESSION… if I'm wrong with this, tell me in comments).

Here is how I could solve the practical example case. I used this in ~/.profile:

if [ "$0" = "/usr/sbin/lightdm-session" -a "$DESKTOP_SESSION" = "i3" ]; then
    export $(gnome-keyring-daemon --start --components=ssh)
fi

Warning: for “i3 with debug log” sessions, this will be i3-with-shmlog instead of i3. So a bash regex for something like ^i3.*$, may be better. I still keep it as is here, for readability.

I just would like to know something cleaner than testing for a so much specific value of $0 to tell if ~/.profile is invoked for a graphical session login; would prefer a less environment specific test than "$0" = "/usr/sbin/lightdm-session" is. Anyway and so far, to get the test OK, one should do as suggested above, that is, first figuring how ~/.profile is invoked, logging its invocations in a file.

Notes (update 1)

Specifically for the example case, which is about properly setting up GNOME Keyring environment variables for use of GNOME Keyring in an i3 session, if one can determine gnome-keyring-daemon is already running when ~/.profile is invoked, one may change export $(gnome-keyring-daemon --start --components=ssh) into just export $(gnome-keyring-daemon -s)… no need to run a daemon initialisation twice.

edit flag offensive delete link

add a comment

answered 2014-07-28 07:58:29 +0000

lkraav
518 ●17 ●33 ●48

This discussion is actually quite gnome-keyring-daemon specific, and probably could use a title change. For just setting variables, above methods listed like .profile, .xsession are quite enough. You just have to inspect your display manager's startup scripts, this will tell you exactly what is run and when.

I've been fighting with gnome-keyring-daemon for several months now. Last night I figured an important piece out.

You need to run your gnome-keyring-daemon initialization after setting up the session. Key indicator to look for is whether "Passwords and Keys" (aka seahorse) app is properly able to show your login keyring.

WRONG WAY

.profile (loaded very early)

# this will mess GKR up, as it can't attach to a proper session which comes later
dex /etc/xdg/autostart/gnome-keyring-secrets.desktop
# also possible to autostart everything here, also not a good idea
# dex -a -e GNOME

.i3/config (loaded last)

exec --no-startup-id echo "$0: DESKTOP_AUTOSTART_ID $DESKTOP_AUTOSTART_ID, registering with org.gnome.SessionManager"
exec --no-startup-id dbus-send --session --print-reply=literal --dest=org.gnome.SessionManager "/org/gnome/SessionManager" org.gnome.SessionManager.RegisterClient "string:i3" "string:$DESKTOP_AUTOSTART_ID"

BETTER WAY

/etc/pam.d/some-or-other (login keyring, should be taken care of by your distro)

...
session  optional pam_gnome_keyring.so auto_start
...

https://wiki.gnome.org/Projects/Gnome... for PAM details.

.i3/config (loaded last)

exec --no-startup-id echo "$0: DESKTOP_AUTOSTART_ID $DESKTOP_AUTOSTART_ID, registering with org.gnome.SessionManager"
exec --no-startup-id dbus-send --session --print-reply=literal --dest=org.gnome.SessionManager "/org/gnome/SessionManager" org.gnome.SessionManager.RegisterClient "string:i3" "string:$DESKTOP_AUTOSTART_ID"
exec --no-startup-id dex -a -e GNOME

.bashrc (gets me the SSH agent)

...
export $( dex /etc/xdg/autostart/gnome-keyring-ssh.desktop )
...

I don't know yet why dex -a doesn't take care of setting SSH_AUTH_SOCK in the session environment, so all terminal invocations would inherit it automatically. It works properly when running pure GNOME session, so I assume there's some extra magic in the initialization somewhere. Or maybe you guys can help me figure that part out.

Either way, right now my automatically unlocked login keyring works + SSH agent works, all using GKR. When I was Doing It Wrong earlier, I had to be quite careful to launch things in the correct order after logging in. This is because GKR needs to be initialized in a certain sequence of events.

edit flag offensive delete link

Comments

Please, what is `dex`? Seems to not exists on Ubuntu. That said, what is launched from `.profile` needs indeed to be checked with care. As an example, starting `gnome-settings-daemon` from `.profile` was enough to get jammed for me.

Hibou57 ( 2014-07-28 12:55:57 +0000 )edit

https://github.com/jceb/dex to start desktop files. It's surely discussed in other posts here as well. You can of course start gnome-settings-daemon from .profile, but not all of it properly works then. You can't register session that early, $DESKTOP_AUTOSTART_ID doesn't exist during .profile run.

lkraav ( 2014-07-28 13:00:56 +0000 )edit

add a comment

Session's environment variables

Related materials

Practical case

Question

Notes (update 1)

Comments

2 answers

Notes (update 1)

Comments

Question Tools

Stats

Related questions