On Tue, Jul 16, 2024 at 22:21:23 +0700, Max Nikulin wrote: > Greg, do you have an example when Environment= in service.d works, but an > environment.d file does not?
Oh gods, there's MORE shit to worry about?? Of course there is. Bloody hell. In previous years, I remember exploring environment.d and discarding it, because it never achieved the goals that I had in mind. At that time, I was trying to find a shell-agnostic and login-style-agnostic way to set environment variables for all login sessions (console, ssh, DM). environment.d is not that. But in this particular investigation, we're "only" trying to find a way to configure the user environment for programs started by Desktop Environments. So, back to the laboratory.... Given the existence of the following files: -rw-r--r-- 1 greg greg 66 Jul 16 11:43 .config/environment.d/foo.conf -rw-r--r-- 1 greg greg 51 Jul 15 23:24 .config/systemd/user/service.d/env.conf -rw-r--r-- 1 greg greg 21 Jul 15 23:39 .config/systemd/user/service.d/umask.conf And given that "systemctl --user daemon-reload" has been performed since they were last edited, what I'm seeing is that the contents of the environment.d file are applied *first*, and then the contents of the service.d files are applied *second*, overriding whatever was in the environment.d file. Also, and this is *highly* noteworthy, the syntaxes are different. In particular, expansions like %h are performed in the service.d files, but *not* in the environment.d files. On the other hand, environment.d(5) says you can use a limited subset of shell expansion syntax. It might be worth investigating exactly what variables are available for expansion at that time, but at first glance, it looks like service.d with its %h is probably going to be more useful. For anyone reading this in the archives, out of context, please note that the contents of these files *do not* apply to user logins. They only apply to programs started by the systemd --user daemon.
