Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME
On Sat, Nov 02, 2013 at 01:43:51AM +0200, Mantas Mikulėnas wrote: > On Sat, Nov 2, 2013 at 1:37 AM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Fri, Nov 01, 2013 at 11:02:30PM +, systemdki...@yopmail.com wrote: > >> Might some expert address: > >> > >> https://bbs.archlinux.org/viewtopic.php?id=172220 > >> > >> It seems systemd pushes hard-wired paths irrespective of XDG vars, a > >> possible bug. > >> > >> On this box XDG_DATA_HOME and XDG_CACHE_HOME point outside $HOME, while > >> XDG_CONFIG_HOME is the default ~/.config folder. XDG_DATA_DIRS is the > >> default, > >> /usr/local/share/:/usr/share/ > > Looking at the code, it seems that systemd will create the symlink > > in ~/.local/share/systemd/user only if $XDG_DATA_HOME is not set. > > Are you sure that systemd is actually running with this variable set? > > > >> No file ~/.config/systemd/user exists. Still systemd insists on its > >> symlink in .local and will manufacture all the parent dirs just to > >> create that broken symlink to a nonexistent file. > > Hm, this might be an actual bug. I guess that systemd should not create > > the link if the destination doesn't exist. > > > >> I'd like reliable ways to tell systemd how to use, or not use $HOME. If > >> another way than XDG vars wil serve pray tell. > > This should work. > > I'm curious why the symlink is created at all... or in other words, > why systemd looks in /usr/share and ~/.local/share for user units in > the first place? It is neither documented in systemd.unit(5), nor > consistent with the system unit paths, nor makes much sense since > AFAIK the units are "configuration", not data? It is documented in the source in comments. Basically, those dirs are a fallback for the case where $XDG_CONFIG_HOME is not set, but to avoid having two dirs with esentially the same semantics, they are symlinked to be one and the same. Maybe it's just too much magic. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help on Automatic Symlink XDG_DATA_HOME
On Sat, Nov 02, 2013 at 02:54:20AM +, systemdki...@yopmail.com wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > > 'systemctl --user show-environment' will show what's set > > I get errors as normal user and root. > > $ systemctl --user show-environment > Failed to issue method call: Process /bin/false exited with status 1 So something is broken. > $ su - > Password: > # systemctl --user show-environment > Failed to get D-Bus connection: Unable to autolaunch a dbus-daemon > without a $DISPLAY for X11 Running systemctl --user under root is even more confusing, because it's not clear if you'd get the root instance or the user instance. > > systemd is executed by systemd > > with a standard set of variables > > Might sysd avoid/defer possibly wrong values until they are reliable? Not really. The design is that systemd (PID 1) launches user@username.service, which spawns systemd --user instance. This --user instance launches some services, including possibly at some point, your session. A shell is not involved anywhere in this process... Reading stuff from /etc/profile* is possibly only if you insert a shell somewhere in this sequence, which is contrary to the design. > Might it offer a config file for admins to override assumptions? Note my > XDG vars need $USER, so: > export XDG_DATA_HOME="/tmp/user_data_for_$USER" > > > /etc/profile* is unfortunately shell-only, so it's not something > > that systemd can use directly. I think that adding a custom pam > > module would be a better option here (c.f. pam_env(8)). > > Everything else works swell with /etc/profile* values, and, for that > matter, even systemd does after login. KDE works in its entirety. Read > on XDG_RUNTIME_DIR. tightly bound to login. > http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html Right, they are all started much later, and through a shell. > If I need PAM trickery then I'd rather drop a one-line script into > /etc/profile.d to delete the symlink and call it a wrap. We might even drop the creation of the symlink from systemd, but this won' solve your real problem: that systemd --user runs with different XDG_* settings than the rest of your session. Fix that, and the symlink issue will fix itself too. > But philosophically, would it be fair to say: > > "All vars can, and should, be set or changed in /etc/profile.d, except > XDG vars, which only for the sake of systemd should be set elsewhere." > > Is that idea documented or proposed anywhere, or desirable design? Isn't > the issue more about sysd bootstrapping glitches? Like I said above, /etc/profile* are a bunch of shell scripts. This means that XDG_ stuff must be set elsewhere. Otherwise systemd --user and anything spawned by it will have wrong settings. > Thanks for the feedback in any case. Sounds like a cleanup script is the > fast answer. Maybe in future sysd can offer an admin config file for XDG > vars. > > Glad I asked, help was appreciated and very rapid. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-login: Fix typo
On Fri, 2013-11-01 at 00:24 +0100, Bastien Nocera wrote: > s/sessio,/session,/ Looks like this got lost in the other mailing list noise; just pushed now. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Need advice on daemon's architecture
Hello All! I'm working on a system service which uses systemd intensively. Right now it's socket-activated, with main service of type "simple". I recently added support for querying and publishing some internals via D-Bus, so it has a D-Bus name now. Does it add anything if I change type of a main service to "dbus" thus allowing systemd to know for sure if my service is fully initialized? -- With best regards, Peter Lemenkov. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
