Re: [systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
Am 14.05.19 um 08:35 schrieb Ulrich Windl: >> stop it - if you would have read IT news (golem/heise) the last 7 years >> or so you would know about /run and why it is a top-directory >> >> https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard >> >> /run >> >> Run-time variable data: Information about the running system since last >> boot, e.g., currently logged-in users and running daemons. Files under >> this directory must be either removed or truncated at the beginning of >> the boot process; but this is not necessary on systems that provide this >> directory as a temporary filesystem (tmpfs). > > I knew that. It doesn't answer _why_ /var/run is obsolete because the runtime dirctory is needed at early boot and /var is not available at that point of time when it's a seperate mount-point which could even live on NFS and so comes up very late after network and friends? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
On Di, 14.05.19 16:07, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > Hmm, like this:? > > systemd-analyze verify /run/systemd/generator.late/iotwatch.target > Failed to open /dev/tty0: Permission denied This is mostly a cosmetical message you can safely ignore. Moreover this has long been fixed and is not displayed on any current systemd version. > Or more like this (in the user directory):? > > systemd-analyze verify systemd/iotwatch.target.in > Failed to open /dev/tty0: Permission denied > Failed to load systemd/iotwatch.target.in: Invalid argument That's not a valid unit file name. On systemd unit files are named in a very strict fashion, and this is documented. A service unit file name must be suffixed with ".service" and a target unit file name must be suffixed with ".target". The suffix ".target.in" is not valid for a unit file. Yes, the error message could be better. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
>>> František Šumšal schrieb am 14.05.2019 um 15:46 in Nachricht : > On 5/14/19 8:39 AM, Ulrich Windl wrote: > František Šumšal schrieb am 13.05.2019 um 17:13 in >> Nachricht <064ac942-a4d7-b547-0705-22f3262f5...@sumsal.cz>: >>> On 5/13/19 8:20 AM, Ulrich Windl wrote: >>> >>> That's actually not true. The argument for `systemd-analyze verify` is a >>> file name, >>> so you verify an arbitrary file for correctness: >> >> So it seems it improved since v228. I filed an enhancement request for >> OpenSUSE to upgrade systemd yesterday, BTW... > > It has always worked this way, iirc, i.e. it was meant to be used for > offline unit verification, so it should definitely work with systemd v228. Hmm, like this:? > systemd-analyze verify /run/systemd/generator.late/iotwatch.target Failed to open /dev/tty0: Permission denied Or more like this (in the user directory):? > systemd-analyze verify systemd/iotwatch.target.in Failed to open /dev/tty0: Permission denied Failed to load systemd/iotwatch.target.in: Invalid argument > systemd --version systemd 228 +PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN Regards, Ulrich > > Reference: > https://github.com/systemd/systemd/commit/8b835fccdad78d89f9cc64f9b02059fb75 > ffbab1 > >> >>> >>> $ cat > test.service << EOF [Unit] Description=test unit [Service] ExecStrt=/bin/true EOF >>> $ systemd-analyze verify test.service >>> File /usr/lib/systemd/system/systemd-udevd.service:26 configures an IP >>> firewall (IPAddressDeny=any), but the local system does not support >>> BPF/cgroup based firewalling. >>> Proceeding WITHOUT firewalling in effect! (This warning is only shown for >>> the first loaded unit using IP firewalling.) >>> /tmp/./test.service:4: Unknown lvalue 'ExecStrt' in section 'Service' >>> test.service: Service lacks both ExecStart= and ExecStop= setting. >> Refusing. >>> Unit test.service has a bad unit file setting. >>> $ systemctl status test.service >>> Unit test.service could not be found. >>> >>> >>> -- >>> GPG key ID: 0xFB738CE27B634E4B >> >> >> > > > -- > GPG key ID: 0xFB738CE27B634E4B ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
On 5/14/19 8:39 AM, Ulrich Windl wrote: František Šumšal schrieb am 13.05.2019 um 17:13 in > Nachricht <064ac942-a4d7-b547-0705-22f3262f5...@sumsal.cz>: >> On 5/13/19 8:20 AM, Ulrich Windl wrote: >> >> That's actually not true. The argument for `systemd-analyze verify` is a >> file name, >> so you verify an arbitrary file for correctness: > > So it seems it improved since v228. I filed an enhancement request for > OpenSUSE to upgrade systemd yesterday, BTW... It has always worked this way, iirc, i.e. it was meant to be used for offline unit verification, so it should definitely work with systemd v228. Reference: https://github.com/systemd/systemd/commit/8b835fccdad78d89f9cc64f9b02059fb75ffbab1 > >> >> $ cat > test.service << EOF >>> [Unit] >>> Description=test unit >>> >>> [Service] >>> ExecStrt=/bin/true >>> EOF >> $ systemd-analyze verify test.service >> File /usr/lib/systemd/system/systemd-udevd.service:26 configures an IP >> firewall (IPAddressDeny=any), but the local system does not support >> BPF/cgroup based firewalling. >> Proceeding WITHOUT firewalling in effect! (This warning is only shown for >> the first loaded unit using IP firewalling.) >> /tmp/./test.service:4: Unknown lvalue 'ExecStrt' in section 'Service' >> test.service: Service lacks both ExecStart= and ExecStop= setting. > Refusing. >> Unit test.service has a bad unit file setting. >> $ systemctl status test.service >> Unit test.service could not be found. >> >> >> -- >> GPG key ID: 0xFB738CE27B634E4B > > > -- GPG key ID: 0xFB738CE27B634E4B signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
On Di, 14.05.19 08:35, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >>> Reindl Harald schrieb am 13.05.2019 um 08:25 in > Nachricht <19612492-4b1e-0d87-5360-a67893873...@thelounge.net>: > > > > > Am 13.05.19 um 08:20 schrieb Ulrich Windl: > >>> Note that "/var/run" is a legacy alias for "/run". It's highly > >>> recommended not to use the former anymore. > >> > >> It it because you don't like sub-directories, or is it to save four bytes? > >> ;-) > > > > > > stop it - if you would have read IT news (golem/heise) the last 7 years > > or so you would know about /run and why it is a top-directory > > > > https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard > > > > /run > > > > Run-time variable data: Information about the running system since last > > boot, e.g., currently logged-in users and running daemons. Files under > > this directory must be either removed or truncated at the beginning of > > the boot process; but this is not necessary on systems that provide this > > directory as a temporary filesystem (tmpfs). > > I knew that. It doesn't answer _why_ /var/run is obsolete. That decision was made 8 years ago. See here for the longer explanation: https://lwn.net/Articles/436012/ And since propagated into most distributions, including many which don't even like systemd. The FHS also says so now, as I learnt recently. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
Hello all, Ulrich Windl [2019-05-14 8:35 +0200]: > I knew that. It doesn't answer _why_ /var/run is obsolete. The short reason is that /var can be on a separate partition, so it's not available during early mount or late shutdown, or in a rescue environment with only the root fs mounted. Some adventurous people even have it on NFS. Martin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
On Tue, May 14, 2019 at 9:35 AM Ulrich Windl wrote: > > I knew that. It doesn't answer _why_ /var/run is obsolete. > /var/run needs /var which is not guaranteed to be there when you need it which complicates things. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
>>> František Šumšal schrieb am 13.05.2019 um 17:13 in Nachricht <064ac942-a4d7-b547-0705-22f3262f5...@sumsal.cz>: > On 5/13/19 8:20 AM, Ulrich Windl wrote: > >>> "systemd‑analyze verify" exists. Since a long long time. >> >> Not really: You can't verify a unit file while it's not "installed". Comare > it >> to validating an XML file, for example. >> > > That's actually not true. The argument for `systemd-analyze verify` is a > file name, > so you verify an arbitrary file for correctness: So it seems it improved since v228. I filed an enhancement request for OpenSUSE to upgrade systemd yesterday, BTW... > > $ cat > test.service << EOF >> [Unit] >> Description=test unit >> >> [Service] >> ExecStrt=/bin/true >> EOF > $ systemd-analyze verify test.service > File /usr/lib/systemd/system/systemd-udevd.service:26 configures an IP > firewall (IPAddressDeny=any), but the local system does not support > BPF/cgroup based firewalling. > Proceeding WITHOUT firewalling in effect! (This warning is only shown for > the first loaded unit using IP firewalling.) > /tmp/./test.service:4: Unknown lvalue 'ExecStrt' in section 'Service' > test.service: Service lacks both ExecStart= and ExecStop= setting. Refusing. > Unit test.service has a bad unit file setting. > $ systemctl status test.service > Unit test.service could not be found. > > > -- > GPG key ID: 0xFB738CE27B634E4B ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
>>> Reindl Harald schrieb am 13.05.2019 um 08:25 in Nachricht <19612492-4b1e-0d87-5360-a67893873...@thelounge.net>: > > Am 13.05.19 um 08:20 schrieb Ulrich Windl: >>> Note that "/var/run" is a legacy alias for "/run". It's highly >>> recommended not to use the former anymore. >> >> It it because you don't like sub-directories, or is it to save four bytes? >> ;-) > > > stop it - if you would have read IT news (golem/heise) the last 7 years > or so you would know about /run and why it is a top-directory > > https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard > > /run > > Run-time variable data: Information about the running system since last > boot, e.g., currently logged-in users and running daemons. Files under > this directory must be either removed or truncated at the beginning of > the boot process; but this is not necessary on systems that provide this > directory as a temporary filesystem (tmpfs). I knew that. It doesn't answer _why_ /var/run is obsolete. > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
