Bug#927911: systemd: Does not expand %h identifier in ExecStart
Am 26.04.19 um 03:56 schrieb Norbert Preining: > Hi > >> The man pages say that %h and %u are resolved to the root user if you >> are using the system instance (PID 1). >> That is consistent with the behaviour you are getting. >> If I missed a part which mentions the contrary, could you quote the >> relevant bits from the documentation, so it can be fixed? > > Unit files can be parameterized by a single argument called the > "instance name". The unit is then constructed based on a "template file" > which serves as the definition of multiple services or other units. > A template unit must have a single "@" at the end of the name (right > before the type suffix). The name of the full unit is formed by > inserting > the instance name between "@" and the unit type suffix. In the unit file > itself, the instance parameter may be referred to > using "%i" and other specifiers, see below. > ^^ > > There is no real indication what means "below", but the somehow for me > logical reference is the section > Specifiers > > Many settings resolve specifiers which may be used to write generic > unit files referring to runtime or unit parameters that are replaced > when the unit files are loaded. Specifiers must be known and resolvable > for the setting to be valid. The following specifiers are understood: > > Table 4. Specifiers available in unit files > ... > > In my reading that says: > You can use %i and other specifiers **as laid out in the secion > "Specifiers" in the Unit file** > > I searched all occurrences of % in the man page, and that is all that is > said. See [1] >> That said, I do acknowledge that the systemd.unit(5) man page could be >> clearer what effect it has on %h and %u when setting `User=` when > > I am not sure how this relates to my question. Section "SPECIFIERS" [1] in systemd.unit(5) says this about %h >│"%h" │ User home directory │ This is the > home directory of the user │ >│ │ │ running the > service manager instance. In │ >│ │ │ case of the > system manager this resolves │ >│ │ │ to "/root". > So, the documentation says that %h is expanded to the home directory of root user in your case (as you run the service as system service). The incorrect bit is, that the documentation says it is expanded to "/root" whereas really it is "/" for system services. In your case, you use "User=" and I think (please correct me if I'm wrong) you expected "%h" to be expanded to the home directory of that user specified via "User=" That's why I filed an upstream bug report - to fix the documentation to say "/" instead of "/root" - to be more explicit that setting "User=" has no effect on %h [1] https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Specifiers -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#927911: systemd: Does not expand %h identifier in ExecStart
Hi > The man pages say that %h and %u are resolved to the root user if you > are using the system instance (PID 1). > That is consistent with the behaviour you are getting. > If I missed a part which mentions the contrary, could you quote the > relevant bits from the documentation, so it can be fixed? Unit files can be parameterized by a single argument called the "instance name". The unit is then constructed based on a "template file" which serves as the definition of multiple services or other units. A template unit must have a single "@" at the end of the name (right before the type suffix). The name of the full unit is formed by inserting the instance name between "@" and the unit type suffix. In the unit file itself, the instance parameter may be referred to using "%i" and other specifiers, see below. ^^ There is no real indication what means "below", but the somehow for me logical reference is the section Specifiers Many settings resolve specifiers which may be used to write generic unit files referring to runtime or unit parameters that are replaced when the unit files are loaded. Specifiers must be known and resolvable for the setting to be valid. The following specifiers are understood: Table 4. Specifiers available in unit files ... In my reading that says: You can use %i and other specifiers **as laid out in the secion "Specifiers" in the Unit file** I searched all occurrences of % in the man page, and that is all that is said. > That said, I do acknowledge that the systemd.unit(5) man page could be > clearer what effect it has on %h and %u when setting `User=` when I am not sure how this relates to my question. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#927911: systemd: Does not expand %h identifier in ExecStart
Am 25.04.19 um 12:24 schrieb Norbert Preining: > Hi > >> From v228 >> https://github.com/systemd/systemd/blob/master/NEWS#L3926 > >> From v209 >> https://github.com/systemd/systemd/blob/master/NEWS#L6855 > > Ok, but the documentation o freedesktop.org and the man pages do not > mention that, and in fact mention the contrary ... The man pages say that %h and %u are resolved to the root user if you are using the system instance (PID 1). That is consistent with the behaviour you are getting. If I missed a part which mentions the contrary, could you quote the relevant bits from the documentation, so it can be fixed? That said, I do acknowledge that the systemd.unit(5) man page could be clearer what effect it has on %h and %u when setting `User=` when Which is why I filed the upstream bug report. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#927911: systemd: Does not expand %h identifier in ExecStart
Hi > From v228 > https://github.com/systemd/systemd/blob/master/NEWS#L3926 > From v209 > https://github.com/systemd/systemd/blob/master/NEWS#L6855 Ok, but the documentation o freedesktop.org and the man pages do not mention that, and in fact mention the contrary ... Nobody is supposed to wade through old NEWS, right? > Thanks. So with the above, what you should get is that %h is resolved to > /root, as you run that service as a system service. Or is %h not > expanded at all? No, it was expanded to "/" Apr 25 08:40:46 bulldog systemd[1]: Started OneDrive Free Client for norbert. Apr 25 08:40:46 bulldog onedrive[17137]: std.file.FileException@std/file.d(3011): //.config: Permission denied so %h/.config -> //.config Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#927911: systemd: Does not expand %h identifier in ExecStart
Am 25.04.19 um 11:33 schrieb Michael Biebl: > Am 25.04.19 um 11:28 schrieb Michael Biebl: >> Thanks. So with the above, what you should get is that %h is resolved to >> /root, as you run that service as a system service. Or is %h not >> expanded at all? > > Actually, I think systemd resolves %h for PID 1 to '/'. Would need to > double check though. > Re-reading the systemd.unit man page, it says for %u and %h that it resolves to the root user for the systemd manager instance. While this correctly describes the behaviour, it could be a bit clearer, documenting that setting `User=` has no effect. I've filed https://github.com/systemd/systemd/issues/12389 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#927911: systemd: Does not expand %h identifier in ExecStart
Am 25.04.19 um 11:28 schrieb Michael Biebl: > Thanks. So with the above, what you should get is that %h is resolved to > /root, as you run that service as a system service. Or is %h not > expanded at all? Actually, I think systemd resolves %h for PID 1 to '/'. Would need to double check though. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#927911: systemd: Does not expand %h identifier in ExecStart
Am 25.04.19 um 11:09 schrieb Norbert Preining: > Hi Michael, > > On Thu, 25 Apr 2019, Michael Biebl wrote: >> Looks like a duplicate of >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868269 > > Indeed. Interesting that systemd changed the behaviour but it is not > documented ... (well ... we know). > Well, there are the following paragraphs from the systemd NEWS file From v228 https://github.com/systemd/systemd/blob/master/NEWS#L3926 * In unit files the behaviour of %u, %U, %h, %s has changed. These specifiers will now unconditionally resolve to the various user database fields of the user that the systemd instance is running as, instead of the user configured in the specific unit via User=. Note that this effectively doesn't change much, as resolving of these specifiers was already turned off in the --system instance of systemd, as we cannot do NSS lookups from PID 1. In the --user instance of systemd these specifiers where correctly resolved, but hardly made any sense, since the user instance lacks privileges to do user switches anyway, and User= is hence useless. Moreover, even in the --user instance of systemd behaviour was awkward as it would only take settings from User= assignment placed before the specifier into account. In order to unify and simplify the logic around this the specifiers will now always resolve to the credentials of the user invoking the manager (which in case of PID 1 is the root user). From v209 https://github.com/systemd/systemd/blob/master/NEWS#L6855 * %h, %s, %U specifier support is not available anymore when used in unit files for PID 1. This is because NSS calls are not safe from PID 1. They stay available for --user instances of systemd, and as special case for the root user. >> Can you attach the full .service file please. > > Here is the .in version that is then configure-d into the .service file Thanks. So with the above, what you should get is that %h is resolved to /root, as you run that service as a system service. Or is %h not expanded at all? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#927911: systemd: Does not expand %h identifier in ExecStart
Hi Michael, On Thu, 25 Apr 2019, Michael Biebl wrote: > Looks like a duplicate of > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868269 Indeed. Interesting that systemd changed the behaviour but it is not documented ... (well ... we know). > Can you attach the full .service file please. Here is the .in version that is then configure-d into the .service file - [Unit] Description=OneDrive Free Client for %i Documentation=https://github.com/abraunegg/onedrive After=network-online.target Wants=network-online.target [Service] ExecStart=@prefix@/bin/onedrive --monitor --confdir=%h/.config/onedrive User=%i Group=users Restart=on-failure RestartSec=3 [Install] WantedBy=multi-user.target -- Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#927911: systemd: Does not expand %h identifier in ExecStart
Am 25.04.19 um 01:55 schrieb Norbert Preining: > Package: systemd > Version: 241-3 > Severity: important > > Hi > > it seems that the documentation of systemd is incorrect, or incomplete, > as it states that > suffix. In the unit file itself, the instance parameter may be referred > to using "%i" and other > specifiers, see below. > (man page of systemd.unit) > and down there %h is listed as home directory of the user. > > We use a systemd unit file that has onedrive@.service > ExecStart=/usr/bin/onedrive --monitor > --confdir=/home/%i/.config/onedrive > which works as expected. But the moment I change it to > ExecStart=/usr/bin/onedrive --monitor --confdir=%h/.config/onedrive > it breaks because %h is not expanded. Looks like a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868269 Can you attach the full .service file please. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#927911: systemd: Does not expand %h identifier in ExecStart
Package: systemd Version: 241-3 Severity: important Hi it seems that the documentation of systemd is incorrect, or incomplete, as it states that suffix. In the unit file itself, the instance parameter may be referred to using "%i" and other specifiers, see below. (man page of systemd.unit) and down there %h is listed as home directory of the user. We use a systemd unit file that has onedrive@.service ExecStart=/usr/bin/onedrive --monitor --confdir=/home/%i/.config/onedrive which works as expected. But the moment I change it to ExecStart=/usr/bin/onedrive --monitor --confdir=%h/.config/onedrive it breaks because %h is not expanded. Best Norbert -- Package-specific info: -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.0.9 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-4 ii libapparmor1 2.13.2-10 ii libaudit11:2.8.4-2 ii libblkid12.33.1-0.1 ii libc62.28-8 ii libcap2 1:2.25-2 ii libcryptsetup12 2:2.1.0-2 ii libgcrypt20 1.8.4-5 ii libgnutls30 3.6.7-2 ii libgpg-error01.35-1 ii libidn11 1.33-2.2 ii libip4tc01.8.2-4 ii libkmod2 26-1 ii liblz4-1 1.8.3-1 ii liblzma5 5.2.4-1 ii libmount12.33.1-0.1 ii libpam0g 1.3.1-5 ii libseccomp2 2.3.3-4 ii libselinux1 2.8-1+b1 ii libsystemd0 241-3 ii mount2.33.1-0.1 ii util-linux 2.33.1-0.1 Versions of packages systemd recommends: ii dbus1.12.12-1 ii libpam-systemd 241-3 Versions of packages systemd suggests: ii policykit-10.105-25 ii systemd-container 241-3 Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.133 ii udev 241-3 -- no debconf information
