[SOLVED] XDG variables are not set automatically

geo909 · 2016-01-13 23:43:38

Hi all,

I use a bare i3 window manager. Today I did a little bit of clean up, I removed a lot of unused applications, which included gnome-desktop (I'm not sure why I had installed gnome-desktop in the first place). After rebooting, I had a couple of issues, and I found out that they were all related to some XDG* variables being empty. For example

jorge@flamingo:~$ echo $XDG_VTNR

jorge@flamingo:~$ echo $XDG_RUNTIME_DIR 

jorge@flamingo:~$

How can I get the system to set those variables automatically? I already set

export XDG_RUNTIME_DIR=/run/user/$UID

in my /etc/profile, but I'm not sure to what to set $XDG_VTNR, and most importantly I'm guessing that I shouldn't be setting those manually.

Anybody has an idea here?

Many thanks in advance.

PS. I ran xdg-user-dirs-udate but it didn't help.
PS2. Same problem with https://bbs.archlinux.org/viewtopic.php?id=206321j, but there is no solution in that thread

Last edited by geo909 (2016-01-16 19:01:24)

graysky · 2016-01-13 23:49:43

Installing simply base and openssh into an lxc (no Xorg of WMs), XDG_RUNTIME_DIR was setup for me. I believe systemd does this. Did you tweak it in any way?
From the ssh connection to the container:

% echo $XDG_RUNTIME_DIR
/run/user/1000

Last edited by graysky (2016-01-13 23:50:14)

geo909 · 2016-01-13 23:53:02

graysky wrote:

Installing simply base and openssh into an lxc (no Xorg of WMs), XDG_RUNTIME_DIR was setup for me. I believe systemd does this. Did you tweak it in any way?
From the ssh connection to the container:
% echo $XDG_RUNTIME_DIR
/run/user/1000

No, I don't remember tweaking anything like this. The most relevant thing I can think of is that I removed a lot of pacakges during a clean up, including a pacman -Rsc gnome-desktop..

Last edited by geo909 (2016-01-13 23:54:19)

esa · 2016-01-14 00:53:42

Try:

.bashrc (or the rc of your shell)

source ~/.config/user-dirs.dirs

hth

Trilby · 2016-01-14 01:09:38

esa, those are not relevant for this. That file is where one can set XDG desktop paths for things like documents, desktop, etc. That has nothing to do with systemd setting the proper session variables.

geo909 · 2016-01-14 01:09:50

esa wrote:

Try:
.bashrc (or the rc of your shell)
source ~/.config/user-dirs.dirs
hth

Thanks esa, but the contents of that file are

XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Tmp"
XDG_PUBLICSHARE_DIR="$HOME/"
XDG_DOCUMENTS_DIR="$HOME/Archive"
XDG_TEMPLATES_DIR="$HOME/Templates"
XDG_MUSIC_DIR="$HOME/Music"
XDG_PICTURES_DIR="$HOME/Pictures"
XDG_VIDEOS_DIR="$HOME/Videos"

so these do not include the XDG* variables I was talking about.

geo909 · 2016-01-14 05:03:37

Another thing is that when I try to let's say reboot, I get:

jorge@flamingo:~$ systemctl reboot 
==== AUTHENTICATING FOR org.freedesktop.login1.set-wall-message ===
Authentication is required to set a wall message
Multiple identities can be used for authentication:
 1.  jorge
 2.  testuser
Choose identity to authenticate as (1-2):

Before, I would never get something like that, the system would simply reboot without any message or prompt.

Is that related to the XDG issue? Does the above gives any hint of what may be missing or went wrong?

Trilby · 2016-01-14 12:23:49

What's the output of `loginctl session-status`?

geo909 · 2016-01-14 14:16:04

Trilby wrote:

What's the output of `loginctl session-status`?

Hmm.. I get a pam_systemd(login:session): Failed to create session: Connection timed out.. I've been reading around and it seems that pam should be responsible for setting these variables, so I assume this is the culprit. Or just a symptom?

jorge@flamingo:~$ loginctl session-status 
c1 - jorge (1000)
           Since: Thu 2016-01-14 08:56:24 EST; 15min ago
          Leader: 279 (login)
            Seat: seat0; vc1
             TTY: tty1
         Service: login; type tty; class user
           State: closing
            Unit: session-c1.scope
                  ├─ 279 login -- jorge     
                  ├─ 441 -bash
                  ├─1066 /bin/sh /usr/bin/startx
                  ├─1091 xinit /home/jorge/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -auth /tmp/serverau
                  ├─1092 /usr/lib/xorg-server/Xorg -nolisten tcp :0 vt1 -auth /tmp/serverauth.OcLeVulWVS
                  ├─1101 xf86-video-intel-backlight-helper acpi_video0
                  ├─1104 i3
                  ├─1135 clipit
                  ├─1136 python3 /usr/bin/redshift-gtk
                  ├─1137 conky -c /home/jorge/Applications/Standalone/todo.txt/conky/conkyrc_gtd
                  ├─1138 conky -c /home/jorge/Applications/Configuration Files/conkyrc_gcalendar
                  ├─1141 xbindkeys
                  ├─1235 /usr/bin/redshift -v
                  ├─1237 i3bar --bar_id=bar-0 --socket=/run/user/1000/i3/ipc-socket.1104
                  ├─1240 i3status
                  ├─3266 firefox
                  ├─7694 lxterminal
                  ├─7695 /bin/bash
                  ├─9263 /bin/bash
                  ├─9272 loginctl session-status
                  └─9273 loginctl session-status

Jan 14 08:56:24 flamingo systemd[1]: Started Session c1 of user jorge.
Jan 14 08:56:49 flamingo login[279]: pam_systemd(login:session): Failed to create session: Connection time
Jan 14 08:56:49 flamingo login[279]: LOGIN ON tty1 BY jorge
lines 1-33/33 (END)




c1 - jorge (1000)
           Since: Thu 2016-01-14 08:56:24 EST; 15min ago
          Leader: 279 (login)
            Seat: seat0; vc1
             TTY: tty1
         Service: login; type tty; class user
           State: closing
            Unit: session-c1.scope
                  ├─ 279 login -- jorge     
                  ├─ 441 -bash
                  ├─1066 /bin/sh /usr/bin/startx
                  ├─1091 xinit /home/jorge/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -auth /tmp/serverauth.OcLeVulWVS
                  ├─1092 /usr/lib/xorg-server/Xorg -nolisten tcp :0 vt1 -auth /tmp/serverauth.OcLeVulWVS
                  ├─1101 xf86-video-intel-backlight-helper acpi_video0
                  ├─1104 i3
                  ├─1135 clipit
                  ├─1136 python3 /usr/bin/redshift-gtk
                  ├─1137 conky -c /home/jorge/Applications/Standalone/todo.txt/conky/conkyrc_gtd
                  ├─1138 conky -c /home/jorge/Applications/Configuration Files/conkyrc_gcalendar
                  ├─1141 xbindkeys
                  ├─1235 /usr/bin/redshift -v
                  ├─1237 i3bar --bar_id=bar-0 --socket=/run/user/1000/i3/ipc-socket.1104
                  ├─1240 i3status
                  ├─3266 firefox
                  ├─7694 lxterminal
                  ├─7695 /bin/bash
                  ├─9263 /bin/bash
                  ├─9272 loginctl session-status
                  └─9273 loginctl session-status

Jan 14 08:56:24 flamingo systemd[1]: Started Session c1 of user jorge.
Jan 14 08:56:49 flamingo login[279]: pam_systemd(login:session): Failed to create session: Connection timed out
Jan 14 08:56:49 flamingo login[279]: LOGIN ON tty1 BY jorge

EDIT: Another person seems to have a similar problem. See post #698 here:
https://bbs.archlinux.org/viewtopic.php … 8#p1595318
I wonder if it is a more general problem..

Last edited by geo909 (2016-01-14 14:51:51)

Trilby · 2016-01-14 15:08:23

Can you / have you tried the same loginctl command from a tty?

geo909 · 2016-01-14 15:31:12

Trilby wrote:

Can you / have you tried the same loginctl command from a tty?

So, what is happening is that in every other tty except tty1, no problem appears in the loginctl output and the XDG variables are all set.
E.g. in tty2 I get:

jorge@flamingo:~$ export -p | grep XDG
declare -X XDG_RUNTIME_DIR="/run/user/1000"
declare -X XDG_SEAT="seat0"
declare -X XDG_SESSION_ID="c2"
declare -X XDG_VTNR="2"

None of these are set in tty1.

Also in tty2 loginctl session-status gives:

c2 - jorge (1000)
	   Since: Thu 2016-01-14 10:21:35 EST; 9min ago
	  Leader: 975 (login)
	    Seat: seat0; vc2
	     TTY: tty2
	 Service: login; type tty; class user
	   State: active
	    Unit: session-c2.scope
		  ├─ 975 login -- jorge     
		  ├─ 981 -bash
		  └─6106 loginctl session-status

Jan 14 10:21:35 flamingo systemd[1]: Started Session c2 of user jorge.
Jan 14 10:21:35 flamingo login[975]: LOGIN ON tty2 BY jorge

Last edited by geo909 (2016-01-14 15:33:13)

Trilby · 2016-01-14 17:29:13

Thanks. In tty1 is that only in X (e.g., do you have X autostart in tty1) or do you get the same problematic output in tty1 before/without X?

Have you set up autologin to tty1 similar to this:
https://wiki.archlinux.org/index.php/Au … al_console

geo909 · 2016-01-14 21:06:36

Trilby wrote:

Thanks. In tty1 is that only in X (e.g., do you have X autostart in tty1) or do you get the same problematic output in tty1 before/without X?

I get the same problematic output before or without X.

Also, I autostart X in tty1 according to
https://wiki.archlinux.org/index.php?ti … X_at_login

jorge@flamingo:~$ cat .bash_profile 
[[ -f ~/.bashrc ]] && . ~/.bashrc

# Automatically start x:
[[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && exec startx

(Although of course this does not work currently that XDG_VTNR is not set.)

Trilby wrote:

Have you set up autologin to tty1 similar to this:
https://wiki.archlinux.org/index.php/Au … al_console

Indeed..

jorge@flamingo:~$ cat /etc/systemd/system/getty@tty1.service.d/autologin.conf 
[Service]
ExecStart=
ExecStart=-/usr/bin/agetty --autologin jorge --noclear %I 38400 linux
Type=simple

Last edited by geo909 (2016-01-14 21:08:18)

Trilby · 2016-01-14 21:57:41

That all looks good. But clearly something is being initialized differently with your tty1 versus the others. Perhaps temporarily removing the autologin on tty1 could provide some more information.

If it works without autologin, then either autologin isn't working as it should, or there may be a boot-time race condition - perhaps this could be followed by adding a delay to the autologin to test between these alternatives. If it still doesn't work with autologin disabled ... I'm not sure what that'd mean, but we'd rule out the former two possibilities.

Do you have anything in your shell profile or shellrc that makes any reference to the tty number (XDG_VTNR other than the autostarting of X, or and call to `tty`)?

graysky · 2016-01-14 22:51:11

Just for kicks, can you do a fresh install to a clean partition installing just base, chroot in, create your users, blah blah, boot into it and repeat the echo lines? Does it work then?

geo909 · 2016-01-15 00:04:58

Trilby wrote:

That all looks good. But clearly something is being initialized differently with your tty1 versus the others. Perhaps temporarily removing the autologin on tty1 could provide some more information.
If it works without autologin, then either autologin isn't working as it should, or there may be a boot-time race condition - perhaps this could be followed by adding a delay to the autologin to test between these alternatives. If it still doesn't work with autologin disabled ... I'm not sure what that'd mean, but we'd rule out the former two possibilities.

Ok, I left only the following in my autologin.conf:

[Service]
ExecStart=-/usr/bin/agetty --noclear %I 38400 linux
Type=simple

Nothing has changed though, the problem persists.

What do you mean by a "boot-time race condition"? Could you tell me how to add a delay in the autologin and what to test?

Do you have anything in your shell profile or shellrc that makes any reference to the tty number (XDG_VTNR other than the autostarting of X, or and call to `tty`)?

No, I don't think so. By shellrc, you mean bashrc if I run bash, right? If so, there's nothing in there refering to those.

graysky wrote:

Just for kicks, can you do a fresh install to a clean partition installing just base, chroot in, create your users, blah blah, boot into it and repeat the echo lines? Does it work then?

Well.. I really do not want to appear lazy when others are offering their precious time helping me, but this looks like way too much time for me right now. Let's see if we can solve it in another way soon somehow, and if not, I'll go on and do that.

Last edited by geo909 (2016-01-15 00:07:33)

geo909 · 2016-01-15 00:10:42

Oh, wait a minute!! I remember now that I removed some entries from /etc/xdg/autostart related to gnome and nautilus, or something, when I was "cleaning up" (or "breaking my system", maybe I should say, don't ask).

Does it look like something is missing here?

jorge@flamingo:/etc/xdg/autostart$ cl
total 108K
-rw-r--r-- 1 root root  305 Nov 10 16:40 at-spi-dbus-bus.desktop
-rw-r--r-- 1 root root  831 Apr 23  2014 clipit-startup.desktop
-rw-r--r-- 1 root root 8.0K Oct 27 16:36 gnome-keyring-pkcs11.desktop
-rw-r--r-- 1 root root 7.5K Oct 27 16:36 gnome-keyring-secrets.desktop
-rw-r--r-- 1 root root 6.2K Oct 27 16:36 gnome-keyring-ssh.desktop
-rw-r--r-- 1 root root 7.6K Oct  3  2013 gsettings-data-convert.desktop
-rw-r--r-- 1 root root 5.6K Dec 25 20:27 nm-applet.desktop
-rw-r--r-- 1 root root 4.1K Nov 25 17:42 tracker-extract.desktop
-rw-r--r-- 1 root root 4.3K Nov 25 17:42 tracker-miner-apps.desktop
-rw-r--r-- 1 root root 5.2K Nov 25 17:42 tracker-miner-fs.desktop
-rw-r--r-- 1 root root 4.9K Nov 25 17:42 tracker-miner-user-guides.desktop
-rw-r--r-- 1 root root 5.0K Nov 25 17:42 tracker-store.desktop
-rw-r--r-- 1 root root  12K Jul  1  2014 user-dirs-update-gtk.desktop
-rw-r--r-- 1 root root  499 Jan 27  2015 wicd-tray.desktop
-rw-r--r-- 1 root root  479 Aug  9 21:23 z-dispcalGUI-apply-profiles.desktop

Last edited by geo909 (2016-01-15 00:12:02)

Trilby · 2016-01-15 00:37:46

geo909 wrote:

Ok, I left only the following in my autologin.conf:

I was suggesting getting rid of it all together so you log in on tty1 like you would on any other tty.

I don't know what processes might be contributing to a race condition, but if the timing of the log in matters (e.g., tty1 auto-logs-in too quickly) then we'll know that's what it is and we can start hunting. But it's pointless to speculate before testing if that's what it is - which is why I asked you to disable the auto log in.

The files in /etc/xdg/ are not relevant for this.

graysky · 2016-01-15 00:55:11

Dude, you can spin up a new arch install in literally 5 minutes. Maybe less.

geo909 · 2016-01-15 05:27:26

Trilby wrote:

geo909 wrote:
Ok, I left only the following in my autologin.conf:
I was suggesting getting rid of it all together so you log in on tty1 like you would on any other tty.
I don't know what processes might be contributing to a race condition, but if the timing of the log in matters (e.g., tty1 auto-logs-in too quickly) then we'll know that's what it is and we can start hunting. But it's pointless to speculate before testing if that's
what it is - which is why I asked you to disable the auto log in.

Ah, got it, I misunderstood what disabling meant. So I completely removed the autologin.conf file from that folder, and the problem persists.

I have to also note that the system takes a lot of time to start up.. Even when I give my username and password, I have to wait about 30 seconds from the moment I press enter until the prompt appears.

graysky wrote:

Dude, you can spin up a new arch install in literally 5 minutes. Maybe less.

Less than 5 minutes?! Not me, honestly.. I'm not that familiar, and I'd need to do some reading. Plus I have all sorts of work to do on my laptop these days and I cannot risk to play with partitioning right now..

graysky · 2016-01-15 11:56:23

geo909 wrote:

Less than 5 minutes?! Not me, honestly.. I'm not that familiar, and I'd need to do some reading. Plus I have all sorts of work to do on my laptop these days and I cannot risk to play with partitioning right now..

Make a spare partition (let's assume /dev/sda4) or do it on a spare USB you have lying around and update your boot loader, then:

mount /dev/sda4 /mnt/mini
pacstrap -i /mnt/mini base
echo "LABEL=mini / ext4 defaults,relatime 0 1" >> /mnt/mini/etc/fstab
echo mini > /mnt/mini/etc/hostname
sed -i 's/#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /mnt/mini/etc/locale.gen
echo "LANG=en_US.UTF-8" > /mnt/mini/etc/locale.conf

arch-chroot /mnt/mini /bin/bash
passwd
locale-gen
useradd -m -g users -G wheel -s /bin/zsh geo909
passwd geo909
exit
reboot

My point is that something on your current system is jacked up; the above experiment should prove that.

Last edited by graysky (2016-01-15 11:57:19)

geo909 · 2016-01-15 19:17:59

graysky wrote:

geo909 wrote:
Less than 5 minutes?! Not me, honestly.. I'm not that familiar, and I'd need to do some reading. Plus I have all sorts of work to do on my laptop these days and I cannot risk to play with partitioning right now..
Make a spare partition (let's assume /dev/sda4) or do it on a spare USB you have lying around and update your boot loader, then:
mount /dev/sda4 /mnt/mini
pacstrap -i /mnt/mini base
echo "LABEL=mini / ext4 defaults,relatime 0 1" >> /mnt/mini/etc/fstab
echo mini > /mnt/mini/etc/hostname
sed -i 's/#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /mnt/mini/etc/locale.gen
echo "LANG=en_US.UTF-8" > /mnt/mini/etc/locale.conf

arch-chroot /mnt/mini /bin/bash
passwd
locale-gen
useradd -m -g users -G wheel -s /bin/zsh geo909
passwd geo909
exit
reboot
My point is that something on your current system is jacked up; the above experiment should prove that.

That was quick indeed, thanks alot. I had something else in mind when I was thinking of partitioning and installing arch from scratch.

So I followed all that precisely (except that I also installed zsh). I used a usb key formatted to ext4. Then I rebooted and:

jorge@flamingo:~$ sudo arch-chroot /mnt/mini/
sh-4.3# su geo909
flamingo% export -p | grep XDG
flamingo%

So the XDG variables are not set!

EDIT: Same for the root in mini:

sh-4.3# whoami
root
sh-4.3# echo $XDG_VTNR

sh-4.3#

Last edited by geo909 (2016-01-15 19:21:08)

graysky · 2016-01-15 19:52:14

The idea is for you to boot into the freshly partitioned install and then test... and my bad, you didn't need zsh (my shell) for the test.

EDIT: It should look like this:

$ export -p | grep XDG
declare -x XDG_RUNTIME_DIR="/run/user/1000"
declare -x XDG_SEAT="seat0"
declare -x XDG_SESSION_ID="c1"
declare -x XDG_VTNR="1"

Once you prove to yourself that the packages work, you'll either need to 1) figure out what is broken on your current system and fix it or 2) build a new system and copy your /home/foo over and whatever else from /etc /usr/local/bin etc.

Last edited by graysky (2016-01-15 20:04:16)

geo909 · 2016-01-15 20:08:39

graysky wrote:

The idea is for you to boot into the freshly partitioned install and then test... and my bad, you didn't need zsh (my shell) for the test.
EDIT: It should look like this:
$ export -p | grep XDG
declare -x XDG_RUNTIME_DIR="/run/user/1000"
declare -x XDG_SEAT="seat0"
declare -x XDG_SESSION_ID="c1"
declare -x XDG_VTNR="1"

Yes, I did that, see the last part of my previous post: the output was nothing, so the variables were not set in the chrooted environment.. Any thoughts on that?

EDIT: I just saw your conclusion. So if people in this thread run out of ideas I may have to do a reinstallation. It takes about 5 minutes anyway
EDIT2: I'm a bit confused. The fact that in a fresh install like that the variables are not set, wouldn't it mean that there is something wrong irrelevant to my system?

Last edited by geo909 (2016-01-15 20:10:59)

graysky · 2016-01-15 20:32:18

@geo909 - I missed that... if you BOOTED into your new system and got nulls, something is seriously wrong. Are you certain you booted to the correct partition? I have verified this both in a lxc and a live system.

Arch Linux

#1 2016-01-13 23:43:38

[SOLVED] XDG variables are not set automatically

#2 2016-01-13 23:49:43

Re: [SOLVED] XDG variables are not set automatically

#3 2016-01-13 23:53:02

Re: [SOLVED] XDG variables are not set automatically

#4 2016-01-14 00:53:42

Re: [SOLVED] XDG variables are not set automatically

#5 2016-01-14 01:09:38

Re: [SOLVED] XDG variables are not set automatically

#6 2016-01-14 01:09:50

Re: [SOLVED] XDG variables are not set automatically

#7 2016-01-14 05:03:37

Re: [SOLVED] XDG variables are not set automatically

#8 2016-01-14 12:23:49

Re: [SOLVED] XDG variables are not set automatically

#9 2016-01-14 14:16:04

Re: [SOLVED] XDG variables are not set automatically

#10 2016-01-14 15:08:23

Re: [SOLVED] XDG variables are not set automatically

#11 2016-01-14 15:31:12

Re: [SOLVED] XDG variables are not set automatically

#12 2016-01-14 17:29:13

Re: [SOLVED] XDG variables are not set automatically

#13 2016-01-14 21:06:36

Re: [SOLVED] XDG variables are not set automatically

#14 2016-01-14 21:57:41

Re: [SOLVED] XDG variables are not set automatically

#15 2016-01-14 22:51:11

Re: [SOLVED] XDG variables are not set automatically

#16 2016-01-15 00:04:58

Re: [SOLVED] XDG variables are not set automatically

#17 2016-01-15 00:10:42

Re: [SOLVED] XDG variables are not set automatically

#18 2016-01-15 00:37:46

Re: [SOLVED] XDG variables are not set automatically

#19 2016-01-15 00:55:11

Re: [SOLVED] XDG variables are not set automatically

#20 2016-01-15 05:27:26

Re: [SOLVED] XDG variables are not set automatically

#21 2016-01-15 11:56:23

Re: [SOLVED] XDG variables are not set automatically

#22 2016-01-15 19:17:59

Re: [SOLVED] XDG variables are not set automatically

#23 2016-01-15 19:52:14

Re: [SOLVED] XDG variables are not set automatically

#24 2016-01-15 20:08:39

Re: [SOLVED] XDG variables are not set automatically

#25 2016-01-15 20:32:18

Re: [SOLVED] XDG variables are not set automatically

Board footer