[SOLVED] XDG variables are not set automatically

Trilby · 2016-01-15 20:55:45

This is very odd. I'm grasping at straws now, but I do have one other diagnostic suggestion. First, make sure that all autologin stuff is completely disabled, so when you boot you are just prompted for a username at the tty - this is likely already the case on your new usb system.

Start up, but before trying to log in to tty switch to tty2 (Alt-F2) then log in to tty2 without having logged in to tty1.

Then check the variables. If they are defined, then whatever the problem is it is somehow specific to tty1 on your machine. If they are not defined (which is my tentative suspicion) then the variables are not defined in the first tty to be logged in, but are in subsequent ttys (this should be further confirmed by loggin in to tty1 after tty2 is logged in, are the variables then defined in tty1).

In either case, I'm not sure where we'd go next. But differentiating between these two possibilities can at least narrow down where we should look.

geo909 · 2016-01-15 21:54:23

Trilby wrote:

This is very odd. I'm grasping at straws now, but I do have one other diagnostic suggestion. First, make sure that all autologin stuff is completely disabled, so when you boot you are just prompted for a username at the tty - this is likely already the case on your new usb system.

Sorry guys, I misunderstood! I did not boot to the usb stick, I just chrooted on it. I'm now trying to boot from it, but I can't install grub.. I tried grub-install --target=i386-pc --recheck --debug --boot-directory=/media/sdb1/boot /dev/sdb1 and got in the end:

(...)
grub-install: info: Scanning for mdraid09_be devices on disk hostdisk//dev/sda.
grub-install: info: Scanning for mdraid09 devices on disk hostdisk//dev/sda.
grub-install: info: Scanning for dmraid_nv devices on disk hostdisk//dev/sda.
grub-install: info: Scanning for ldm devices on disk hostdisk//dev/sda.
grub-install: info: scanning hostdisk//dev/sda for LDM.
grub-install: info: no LDM signature found.
grub-install: info: Scanning for lvm devices on disk hostdisk//dev/sda.
grub-install: info: no LVM signature found.
grub-install: info: Partition 0 starts from 2048.
grub-install: info: drive = 0.
grub-install: info: the size of hostdisk//dev/sda is 1953525168.
grub-install: info: guessed root_dev `hostdisk//dev/sda' from dir `/media/sdb1/boot/grub/i386-pc'.
grub-install: info: setting the root device to `hostdisk//dev/sda,msdos1'.
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: error: embedding is not possible, but this is required for cross-disk install.

Trilby wrote:

Start up, but before trying to log in to tty switch to tty2 (Alt-F2) then log in to tty2 without having logged in to tty1.
Then check the variables. If they are defined, then whatever the problem is it is somehow specific to tty1 on your machine. If they are not defined (which is my tentative suspicion) then the variables are not defined in the first tty to be logged in, but are in subsequent ttys (this should be further confirmed by loggin in to tty1 after tty2 is logged in, are the variables then defined in tty1).
In either case, I'm not sure where we'd go next. But differentiating between these two possibilities can at least narrow down where we should look.

I disabled autologin completely, and logged in on tty2 first. Indeed you were right, the XDG variables were not set on tty2 in that case.

If you ran out of ideas, I think I'll go on and do a clean install. Maybe it'll take less time that all the hunting you guys have been doing for me.

graysky · 2016-01-15 22:28:51

Grub on the usb can be a pain in the ass depending on your BIOS. If you don't have a massively elaborate installation, it might be fun for you to just reinstall use it as an opportunity to slim down the system or whatever. My advice if that is so, just boot to a live environment, mount your root partition and just

mkdir /old
mv /* /old

Then do the install and cherry pick or diff key files as you setup the new system. Don't delete /old until you are satisfied that everything is good. ALWAYS backup key data before doing anything. Let us know how it goes.

geo909 · 2016-01-15 22:44:27

graysky wrote:

Grub on the usb can be a pain in the ass depending on your BIOS. If you don't have a massively elaborate installation, it might be fun for you to just reinstall use it as an opportunity to slim down the system or whatever. My advice if that is so, just boot to a live environment, mount your root partition and just
mkdir /old
mv /* /old
Then do the install and cherry pick or diff key files as you setup the new system. Don't delete /old until you are satisfied that everything is good. ALWAYS backup key data before doing anything. Let us know how it goes.

Okay, I think I'll do just that sometime soon.

If you don't have any other suggestions, thank you guys for your time, I really appreciate it.

Whatever the problem was, shall remain a mystery forevermore.

geo909 · 2016-01-16 17:26:45

One last thing. I think pretty much at the same time as when the problem appeared, logging in (i.e. right after submitting the password) became extremely slow. From the time that I hit enter after giving the password, it takes 30 seconds to get to the command prompt. Maybe these are related. Is there any way to see what is happening during that time?

Not sure if it helps, but here is my systemd-analyze-blame

jorge@flamingo:~$ systemd-analyze blame
     1min 9.124s updatedb.service
     1min 3.143s user@1000.service
         11.799s man-db.service
          8.783s wicd.service
          8.022s systemd-journald.service
          6.489s dev-sda1.device
          3.354s shadow.service
          2.926s systemd-journal-flush.service
          2.584s logrotate.service
          2.262s lm_sensors.service
          1.952s systemd-user-sessions.service
          1.893s alsa-restore.service
          1.167s systemd-udevd.service
          1.038s colord.service
           988ms dev-mqueue.mount
           872ms sys-kernel-debug.mount
           849ms tmp.mount
           814ms systemd-remount-fs.service
           814ms dev-hugepages.mount
           787ms systemd-vconsole-setup.service
           617ms systemd-tmpfiles-setup-dev.service
           551ms sys-kernel-config.mount
           521ms systemd-backlight@backlight:acpi_video0.service
           476ms systemd-sysctl.service
           413ms systemd-logind.service
           343ms systemd-tmpfiles-setup.service
           321ms systemd-modules-load.service
           306ms swapfile.swap
           286ms systemd-rfkill.service
           207ms systemd-udev-trigger.service
           177ms kmod-static-nodes.service
           173ms systemd-random-seed.service
            16ms systemd-update-utmp.service
             3ms sys-fs-fuse-connections.mount

Also:

jorge@flamingo:~$ systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @21.647s
└─multi-user.target @21.647s
  └─wicd.service @12.864s +8.783s
    └─basic.target @12.801s
      └─sockets.target @12.801s
        └─dbus.socket @12.801s
          └─sysinit.target @12.776s
            └─systemd-update-utmp.service @12.760s +16ms
              └─systemd-tmpfiles-setup.service @12.415s +343ms
                └─systemd-journal-flush.service @9.486s +2.926s
                  └─systemd-journald.service @1.463s +8.022s
                    └─systemd-journald.socket @1.287s
                      └─-.mount @1.156s
                        └─system.slice @1.287s
                          └─-.slice @1.156s

Last edited by geo909 (2016-01-16 17:30:26)

Trilby · 2016-01-16 17:37:40

*headdesk* This would have been good to know at the start.

The problem should be indicated in the output from `systemctl status user@1000`

geo909 · 2016-01-16 18:00:06

Trilby wrote:

*headdesk* This would have been good to know at the start.
The problem should be indicated in the output from `systemctl status user@1000`

Oh sorry.. I did mention it (see post #20) but it got burried under all the posts.

Here we go:

jorge@flamingo:~$ systemctl status -l user@1000 
● user@1000.service - User Manager for UID 1000
   Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor preset: disabled)
   Active: active (running) since Sat 2016-01-16 12:16:02 EST; 42min ago
 Main PID: 681 (systemd)
   Status: "Startup finished in 1min 3.122s."
    Tasks: 36 (limit: 512)
   CGroup: /user.slice/user-1000.slice/user@1000.service
           ├─gvfs-daemon.service
           │ ├─877 /usr/lib/gvfs/gvfsd
           │ └─896 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
           ├─dbus.service
           │ ├─  874 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
           │ ├─  882 /usr/lib/at-spi2-core/at-spi-bus-launcher
           │ ├─  887 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
           │ ├─  892 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
           │ ├─ 1049 /usr/lib/GConf/gconfd-2
           │ ├─16460 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
           │ ├─16462 /usr/lib/gnome-online-accounts/goa-daemon
           │ └─16476 /usr/lib/gnome-online-accounts/goa-identity-service
           ├─gvfs-metadata.service
           │ └─13174 /usr/lib/gvfs/gvfsd-metadata
           └─init.scope
             ├─681 /usr/lib/systemd/systemd --user
             └─683 (sd-pam)  

Jan 16 12:43:11 flamingo dbus-daemon[874]: Activating service name='org.freedesktop.secrets'
Jan 16 12:43:11 flamingo dbus-daemon[874]: Activating service name='org.gnome.OnlineAccounts'
Jan 16 12:43:11 flamingo gnome-keyring-daemon[16460]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
Jan 16 12:43:11 flamingo org.freedesktop.secrets[874]: ** Message: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
Jan 16 12:43:11 flamingo dbus-daemon[874]: Successfully activated service 'org.freedesktop.secrets'
Jan 16 12:43:12 flamingo org.gnome.OnlineAccounts[874]: goa-daemon-Message: goa-daemon version 3.18.2.1 starting
Jan 16 12:43:12 flamingo dbus-daemon[874]: Activating service name='org.gnome.Identity'
Jan 16 12:43:12 flamingo dbus-daemon[874]: Successfully activated service 'org.gnome.OnlineAccounts'
Jan 16 12:43:12 flamingo org.gnome.OnlineAccounts[874]: (goa-daemon:16462): goa-daemon-CRITICAL **: Error preparing AM: The name org.freedesktop.Telepathy.AccountManager was not provided by any .service files
Jan 16 12:43:12 flamingo dbus-daemon[874]: Successfully activated service 'org.gnome.Identity'

Trilby · 2016-01-16 18:14:54

There is a lot of stuff in there - and several errors. Start disabling user services until you find the one causing the problem - I'm not familiar with most of those.

Alternatively you could disable all of that stuff and enable one thing at a time.

Or lastly, you could remember which service you added right before the problem started.

geo909 · 2016-01-16 18:19:18

Trilby wrote:

There is a lot of stuff in there - and several errors. Start disabling user services until you find the one causing the problem - I'm not familiar with most of those.
Alternatively you could disable all of that stuff and enable one thing at a time.
Or lastly, you could remember which service you added right before the problem started.

You mean disable the services under systemd-analyze blame, right? Or something to do with the user@1000.service?

Trilby · 2016-01-16 18:28:05

The user services: all those in the last output, which can also be found in ~/.config/systemd/user

Scimmia · 2016-01-16 18:30:36

He only has 3 user services, and they're all pretty normal.

Trilby · 2016-01-16 18:32:08

How is it normal to have several error messages and take over a minute? The long delay started with the problem - they are almost certainly connected. The long delay (and the main problem too) is likely caused by some of the errors in the user services.

This too can be tested by login in as root on the first tty after booting. Is XDG_VTNR defined there? If it is, this supports my suspicion.

Scimmia · 2016-01-16 18:33:17

Error messages for dbus services are pretty normal as well.

Trilby · 2016-01-16 18:35:06

Ok, do you have any other ideas? It's easy to test my theory - why ignore it.

F*** it, I don't care, do whatever you all want.

Scimmia · 2016-01-16 18:47:12

First thing I would try is making a new, fresh user with no extra configuration and see if you have the same issue.

Also, reinstall the filesystem package to get rid of any changes to /etc/profile, and delete anything in /etc/profile.d/ that doesn't belong to a package.

Edit: crap, /etc/profile is in the backup array. You'll have to restore it manually.

Last edited by Scimmia (2016-01-16 18:51:14)

geo909 · 2016-01-16 18:50:48

It's certainly a problem with user services. When I log in as root as Trilby suggested, there is no delay and all the XDG variables are set.

Anyway, I'll try to check what's going on with the user services.

Trilby, thanks a lot for your time so far, don't spend any more on that. Worse case scenario I'll do a clean intall.

Scimmia · 2016-01-16 18:52:16

That means that there's a problem with your user configuration, not necessarily with the systemd user services.

Trilby · 2016-01-16 18:57:47

Scimmia wrote:

That means that there's a problem with your user configuration, not necessarily with the systemd user services.

Gee, if only there were a trivial way of testing precisely this that hadn't just recently been ridiculed.

geo909 · 2016-01-16 18:59:27

Problem solved! It was the profile-sync-daemon. Removing it solved both the startup delay and all the XDG variables are set.

I think I'll bring this up in the profile-sync-daemon thread instead of continuing here.

Thanks again Trilby and everybody for your help.

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

Scimmia · 2016-01-16 19:03:34

Trilby wrote:

Scimmia wrote:
That means that there's a problem with your user configuration, not necessarily with the systemd user services.
Gee, if only there were a trivial way of testing precisely this that hadn't just recently been ridiculed.

Who ridiculed it? If pointing out that the 3 services listed are normal is now ridicule, we're at an impasse.

Last edited by Scimmia (2016-01-16 19:05:49)

Arch Linux

#26 2016-01-15 20:55:45

Re: [SOLVED] XDG variables are not set automatically

#27 2016-01-15 21:54:23

Re: [SOLVED] XDG variables are not set automatically

#28 2016-01-15 22:28:51

Re: [SOLVED] XDG variables are not set automatically

#29 2016-01-15 22:44:27

Re: [SOLVED] XDG variables are not set automatically

#30 2016-01-16 17:26:45

Re: [SOLVED] XDG variables are not set automatically

#31 2016-01-16 17:37:40

Re: [SOLVED] XDG variables are not set automatically

#32 2016-01-16 18:00:06

Re: [SOLVED] XDG variables are not set automatically

#33 2016-01-16 18:14:54

Re: [SOLVED] XDG variables are not set automatically

#34 2016-01-16 18:19:18

Re: [SOLVED] XDG variables are not set automatically

#35 2016-01-16 18:28:05

Re: [SOLVED] XDG variables are not set automatically

#36 2016-01-16 18:30:36

Re: [SOLVED] XDG variables are not set automatically

#37 2016-01-16 18:32:08

Re: [SOLVED] XDG variables are not set automatically

#38 2016-01-16 18:33:17

Re: [SOLVED] XDG variables are not set automatically

#39 2016-01-16 18:35:06

Re: [SOLVED] XDG variables are not set automatically

#40 2016-01-16 18:47:12

Re: [SOLVED] XDG variables are not set automatically

#41 2016-01-16 18:50:48

Re: [SOLVED] XDG variables are not set automatically

#42 2016-01-16 18:52:16

Re: [SOLVED] XDG variables are not set automatically

#43 2016-01-16 18:57:47

Re: [SOLVED] XDG variables are not set automatically

#44 2016-01-16 18:59:27

Re: [SOLVED] XDG variables are not set automatically

#45 2016-01-16 19:03:34

Re: [SOLVED] XDG variables are not set automatically

Board footer