[systemd] Help on Automatic Symlink

DaveCode · 2013-11-01 08:21:26

It seems Arch makes a file ~/.local/share/systemd/user even if XDG variables point elsewhere. (This box has no ~/.local folder.)

The system creates this file "user" as a broken symlink to nonexistent ~/.config/systemd/user. There is not even a ~/.config/systemd folder on this box. Arch or systemd makes the nested folders and then the broken symlink, if I am following.

So I am trying to determine how/where/when this symlink happens. It reappears with each reboot. Is it an Arch issue or systemd behavior? What config files will alter it, if not the XDG variables?

Thanks

qinohe · 2013-11-01 09:30:57

It seems like standard systemd behavior, have a look at http://cgit.freedesktop.org/systemd/sys … h-lookup.c around line 100 and down.

DaveCode · 2013-11-02 00:37:45

Thank you very much, qinohe. That was good sleuthing.

I think the code there intends a different result than I see. I suspect a C syntax bug or even a compiler bug. The goto statement has been massively deprecated in C for donkey's years. It may not get all the unit testing that it should. I'm surprised to see it in systemd at all.

Anyway I asked the experts.

cfr · 2013-11-02 02:28:06

Is XDG_DATA_HOME supposed to be set? It's empty here - and systemd also links to the non-existent destination - I just never noticed before.

qinohe · 2013-11-02 07:12:36

DaveCode wrote:

Thank you very much, qinohe. That was good sleuthing.
I think the code there intends a different result than I see. I suspect a C syntax bug or even a compiler bug. The goto statement has been massively deprecated in C for donkey's years. It may not get all the unit testing that it should. I'm surprised to see it in systemd at all.
Anyway I asked the experts.

You're welcome,, well mind you that I don't speak 'C' yet, I'm on lesson 7 on CS, that's in the beginning, however, that code I referred to seamed very clear to me.
I didn't know 'goto' was deprecated, for instance

cfr wrote:

Is XDG_DATA_HOME supposed to be set? It's empty here - and systemd also links to the non-existent destination - I just never noticed before.

The code says

We look in both the config and the data dirs because we
want to encourage that distributors ship their unit files
as data, and allow overriding as configuration.

Maybe this base dir.specs shed some light http://standards.freedesktop.org/basedi … c-0.6.html

falconindy · 2013-11-02 13:24:36

goto deprecated? Absolute nonsense.

msthev · 2013-11-02 14:39:39

@OP
As pointed in one of the mails, the user@ service is started without XDG_DATA_HOME set. That's why it uses the default values ($HOME/.config and $HOME/.local/share).
Assuming you set your $XDG_DATA_HOME in $HOME/.profile, here is a possible solution:

$ cat /etc/systemd/system/user@.service
.include /usr/lib/systemd/system/user@.service

[Service]
Environment=SHELL=%s
Environment=XDG_RUNTIME_DIR=/run/user/%I
ExecStart=
ExecStart=/etc/systemd/systemd-user-env

$ cat /etc/systemd/systemd-user-env
#!/bin/sh

if [ -r /etc/profile ]; then
	. /etc/profile
fi

if [ -r "$HOME/.profile" ]; then
	. "$HOME/.profile"
fi

exec /usr/lib/systemd/systemd --user

$ stat -c %A /etc/systemd/systemd-user-env
-rwxr-xr-x

(This will also fix the "/bin/false" error).

About goto: it is used very widely e.g. in the kernel, and can produce more readable code *if used correctly*. It's not a matter of "eliminate all gotos", it's "use goto only where it makes sense"; use Google for examples and reasoning. So no, it is by no means deprecated.

qinohe · 2013-11-02 14:47:20

@falconindy & @ msthev, I thank you both.
msthev, thanks for explaining it.

cfr · 2013-11-02 22:20:41

I don't set XDG_DATA_HOME at all:

$ printenv | grep XDG
XDG_VTNR=7
XDG_SESSION_ID=1
XDG_SEAT=seat0
XDG_DATA_DIRS=/usr/share:/usr/share:/usr/local/share
XDG_RUNTIME_DIR=/run/user/1000
XDG_CURRENT_DESKTOP=KDE

I feel like I'm missing something here - that I somehow missed a step when I installed or updated Arch or something.

msthev · 2013-11-03 00:28:00

You didn't miss anything — these variables are not required. If they are not set, programs will (or at least should) just use default values. If you want to use paths other than default ones, then you can set those — it's good to just set/change 3 variables and be done.

cfr · 2013-11-03 01:37:43

So the three would be

XDG_DATA_HOME # defaults to ${HOME}/.local/share
XDG_CONFIG_HOME # defaults to ${HOME}/.config
XDG_CACHE_HOME # defaults to ${HOME}/.cache

But then also:

XDG_RUNTIME_DIR # defaults to /run/user/<user's id>
XDG_DATA_DIRS # defaults to /usr/share:/usr/share:/usr/local/share on my system, I think
XDG_CONFIG_DIRS # defaults to /etc/xdg

cwgtex · 2014-02-22 04:21:48

msthev wrote:

As pointed in one of the mails, the user@ service is started without XDG_DATA_HOME set. That's why it uses the default values ($HOME/.config and $HOME/.local/share).

Thank you so much for this clarification! I already had my XDG_*_HOME variables set in /etc/profile.d/custom.sh, but ~/.local was still being created. Using the info you provided, plus some research, I was able to come up with an alternate solution that works well for me.

mkdir -p /etc/systemd/system/user@.service.d
cat >> /etc/systemd/system/user@.service.d/env.conf << EOF
[Service]
Environment=XDG_CONFIG_HOME=%h/.xdg/config
Environment=XDG_CACHE_HOME=%h/.xdg/cache
Environment=XDG_DATA_HOME=%h/.xdg/data
EOF

Works like a charm. I was finally able to delete ~/.local and keep it that way.

DaveCode · 2014-03-01 04:31:30

The ideas here look good. A different way is adding lines in /etc/security/pam_env.conf

XDG_CACHE_HOME  DEFAULT=/tmp/XDG_CACHE_HOME_@{PAM_USER}
XDG_DATA_HOME   DEFAULT=/tmp/XDG_DATA_HOME_@{PAM_USER}

GOTO debates never die but deprecation is common knowledge in CS departments and industry at large as far as I can tell.

Everyone has used the odd GOTO, me too. They are no surprise in a kernel. They're legacy from assembly and C was conceived as "portable assembly." Kernels run the metal so one expects quasi-asm style. If you're writing kernels, help yourself, but avoid Linus's awful monolithic design. Remember too that many eyeballs worldwide test/debug Linux, so GOTO risk is heavily mitigated.

Google the recent "goto fail" bug in Apple's phone and desktop OSes. Here you have full-time paid staff goofing royally with GOTO. It's 2014 and we're partying like it's 1979.

Arch Linux

#1 2013-11-01 08:21:26

[systemd] Help on Automatic Symlink

#2 2013-11-01 09:30:57

Re: [systemd] Help on Automatic Symlink

#3 2013-11-02 00:37:45

Re: [systemd] Help on Automatic Symlink

#4 2013-11-02 02:28:06

Re: [systemd] Help on Automatic Symlink

#5 2013-11-02 07:12:36

Re: [systemd] Help on Automatic Symlink

#6 2013-11-02 13:24:36

Re: [systemd] Help on Automatic Symlink

#7 2013-11-02 14:39:39

Re: [systemd] Help on Automatic Symlink

#8 2013-11-02 14:47:20

Re: [systemd] Help on Automatic Symlink

#9 2013-11-02 22:20:41

Re: [systemd] Help on Automatic Symlink

#10 2013-11-03 00:28:00

Re: [systemd] Help on Automatic Symlink

#11 2013-11-03 01:37:43

Re: [systemd] Help on Automatic Symlink

#12 2014-02-22 04:21:48

Re: [systemd] Help on Automatic Symlink

#13 2014-03-01 04:31:30

Re: [systemd] Help on Automatic Symlink

Board footer