[systemd-devel] Antw: Re: Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
>>> Lennart Poettering schrieb am 14.05.2019 um 16:15 in Nachricht <20190514141520.GA22136@gardel-login>: > 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. So the type to check is deduced from the name? my "target.in" is the template used by the generator to create the real target Usually I wouldn't associate "Inavalid argument" with "syntax error". I'd prefer "unknown suffix" over "Invalid argument". There's less room for speculation then... > > Yes, the error message could be better. +1 ;-) > > Lennart > > ‑‑ > Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "bad" status for genersated target; why?
14.05.2019 16:39, Ulrich Windl пишет: > Hi! > > Developing my first systemd service I have some problems I don't understand: > After installation, I get this status: > # systemctl status iotwatch.target ● iotwatch.target - iotwatch I/O > performance monitor >Loaded: loaded (/run/systemd/generator.late/iotwatch.target; bad; vendor > preset: disabled) >Active: inactive (dead) > Docs: man:iotwatch@.service(8) >man:iotwatch-generator(8) > > Why "bad"? Again - this has improved in current version which now tells you that unit is generated. > # ll /run/systemd/generator.late/iotwatch.target > -rw-r--r-- 1 root root 281 May 14 15:24 > /run/systemd/generator.late/iotwatch.target > # systemctl is-enabled iotwatch.target > Failed to get unit file state for iotwatch.target: No such file or directory > > Here we are again: Where should the file be? > Aren't targets allowed to be generated? > Targets are allowed to be generated but generated units cannot be enabled/disabled. The rationale probably is that if you create unit file you can just as well create symlink to this unit file. Also "systemctl dameon-reload" removes and re-creates all generated units, so any symlink to such unit outside of generated subdirectories potentially becomes invalid. Documentation could be better indeed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] ask-password: prevent buffer overrow when reading from keyring
On Mo, 13.05.19 16:58, Thadeu Lima de Souza Cascardo (casca...@canonical.com) wrote: > When we read from keyring, a temporary buffer is allocated in order to > determine the size needed for the entire data. However, when zeroing that > area, > we use the data size returned by the read instead of the lesser size allocate > for the buffer. > > That will cause memory corruption that causes systemd-cryptsetup to crash > either when a single large password is used or when multiple passwords have > already been pushed to the keyring. > > Signed-off-by: Thadeu Lima de Souza Cascardo > Converted to a github PR: https://github.com/systemd/systemd/pull/12566 Looks great! Thanks! 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)
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
[systemd-devel] "bad" status for genersated target; why?
Hi! Developing my first systemd service I have some problems I don't understand: After installation, I get this status: # systemctl status iotwatch.target ● iotwatch.target - iotwatch I/O performance monitor Loaded: loaded (/run/systemd/generator.late/iotwatch.target; bad; vendor preset: disabled) Active: inactive (dead) Docs: man:iotwatch@.service(8) man:iotwatch-generator(8) Why "bad"? # ll /run/systemd/generator.late/iotwatch.target -rw-r--r-- 1 root root 281 May 14 15:24 /run/systemd/generator.late/iotwatch.target # systemctl is-enabled iotwatch.target Failed to get unit file state for iotwatch.target: No such file or directory Here we are again: Where should the file be? Aren't targets allowed to be generated? Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] interacting with logind to detect user idle time
On Di, 14.05.19 11:32, Germano Massullo (germano.massu...@gmail.com) wrote: > Il giorno lun 13 mag 2019 alle ore 10:00 Lennart Poettering > ha scritto: > > Note that it only works correctly on desktops that support it. > > Thank you for your reply. Why does it work only on desktop > environments that support it? I believed that it provides idle infos > to the D.E. not viceversa > According to this seems that it would not be able to detect user idle > time on headless systems where users generally operate by SSH. Desktop environments need to tell us when the user last did something, if they don#t we really don't know. For tty logins we can watch the last access time of the tty to know when the user last did something. inotify will notify us about that nicely. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] interacting with logind to detect user idle time
Il giorno lun 13 mag 2019 alle ore 10:00 Lennart Poettering ha scritto: > Note that it only works correctly on desktops that support it. Thank you for your reply. Why does it work only on desktop environments that support it? I believed that it provides idle infos to the D.E. not viceversa According to this seems that it would not be able to detect user idle time on headless systems where users generally operate by SSH. Have a nice day ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Can I enable/disable a target?
On Di, 14.05.19 11:02, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > $ find /i/dont/exist > > find: ‘/i/dont/exist’: No such file or directory > > I was talking about this: > v04:~> find /var -name no-such-file 2>&1 | grep -v ': Permission denied' > > it outputs nothing if no file was found. And it's similar to systemd: It looks > for a file in different places, but eventually did not find it. Also: In your > example above the "No such file or directory" is specific to /i/dont/exist, > while in systemd it's unspecific (which is confusing IMHO when no file name is > associated dire4ctly with it). We try a few places and then propagate the error we last saw. I'd argue that is good behaviour actually. I mean, I am not saying that our message output couldn't be improved, but I must say the logic of "search but propagate original error on failure" is a good strategy, not a bad one. 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: Can I enable/disable a target?
>>> Lennart Poettering schrieb am 14.05.2019 um 10:55 in Nachricht <20190514085558.GD21579@gardel-login>: > On Di, 14.05.19 08:01, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) > wrote: > >> > systemd matches these UNIX semantics closely: we output error messages >> > exactly the same way as everything else on UNIX: a brief string >> > explaining what was attempted, followed by a colon, followed by a >> > space, followed by the system error string. >> > >> > I mean, sure we can always tweak error messages more, but we generally >> > start from how C and UNIX suggest these works, and then improve from >> > there. >> >> Thanks for the explanation. Actually I'm programming in C for about 30 years >> now. The point I had tried to address was: I think it doesn't make sense to > use >> the low-level error code (or message) in a high level routine. Just imagine >> some find(1) command would output "No such file or directory" when no file >> matched the search criteria given. IMHO ERRNO-related messages >> should be used > > I don't have to image that. It's exactly what find outputs: > > $ find /i/dont/exist > find: ‘/i/dont/exist’: No such file or directory I was talking about this: v04:~> find /var -name no-such-file 2>&1 | grep -v ': Permission denied' it outputs nothing if no file was found. And it's similar to systemd: It looks for a file in different places, but eventually did not find it. Also: In your example above the "No such file or directory" is specific to /i/dont/exist, while in systemd it's unspecific (which is confusing IMHO when no file name is associated dire4ctly with it). Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Can I enable/disable a target?
On Di, 14.05.19 08:01, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > systemd matches these UNIX semantics closely: we output error messages > > exactly the same way as everything else on UNIX: a brief string > > explaining what was attempted, followed by a colon, followed by a > > space, followed by the system error string. > > > > I mean, sure we can always tweak error messages more, but we generally > > start from how C and UNIX suggest these works, and then improve from > > there. > > Thanks for the explanation. Actually I'm programming in C for about 30 years > now. The point I had tried to address was: I think it doesn't make sense to > use > the low-level error code (or message) in a high level routine. Just imagine > some find(1) command would output "No such file or directory" when no file > matched the search criteria given. IMHO ERRNO-related messages > should be used I don't have to image that. It's exactly what find outputs: $ find /i/dont/exist find: ‘/i/dont/exist’: No such file or directory Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The first and the last things in systemd's lifecycle
On Di, 14.05.19 09:23, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > /var/run needs /var which is not guaranteed to be there when you need > > it which complicates things. > > Thanks, > > I'll start a new thread on this (I wanted to ask anyway): > AFAIK systemd does socket communication a lot, while old init was > happy with just a root filesystem. sysvinit communicated via a fifo in the file system. This isn't too different, except maybe it's one way and single-connection while sockets are duplex and can have parallel connections generally. > So I wonder how this Hen-Egg_Problem is solved: Systemd needs a > socket to operate, but to provide the infrastructure, systemd would > need the socket do do so. Or expressed in other words: How can > systemd create /run when it needs /run to operate? systemd mounts /run early on if its not mounted yet, becore creating any sockets in it. > The corresponding question would be for shutdown: How will systemd > unmount /run? OK, if ist a ramdisk, it's not really needed. It closes all sockets, then unmounts it. /run has to be a tmpfs, so yes, it's backed by pageable memory. > Another related question is that of shutdown in general: > > For startup the semantics of Before= and After= are clear, but isn't > it just reverted for shutdown? That is if "M" has "After=X" and > "Before=Y", does that imply that Y is stopped before M will be > stzopped, and M will be stopped before X is? Yes, the order between two ordered units is reversed if both are stopped. THat's how that is implemented. 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: Antw: Re: rdrand generated with march=winchip-c6 in systemd-241
On Di, 14.05.19 08:03, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >> > cpuid has *nothing* to do with /proc/cpuinfo > >> > > >> > https://en.wikipedia.org/wiki/CPUID > >> > The CPUID instruction (identified by a CPUID opcode) is a processor > >> > supplementary instruction > >> > >> Isn't it about to check a CPU's feature depending on the CPU model? > > > > Ulrich, please understand that __get_cpuid() (which the discussion > > here is about) is a gcc and llvm/clang feature weare are just making > > use of. It used by various Linux software, and apparently doesn't work > > entirely correctly on all CPUs in some corner case. The discussion is > > about fixing gcc accordingly, and making it work, so that systemd all > > all other software can work correctly. > > > > If you think that gcc/llvm are bad for "reimplementing /proc/cpuinfo" > > then please bring that up with those communities, but please stop > > these fruitless discussions here. > > The point I was trying to make was: "CPUID" and the model-specific registers > (thus the name) depend very much on the CPU being used. While the kernel makes > grat efforts to get things right, I wondered whether it's the best idea > whether > to repeat that effort in an application program. A compiler is hardly an "application program". There's also a bit of a chicken and egg problem: shared library linking support mechanisms for dynamically altering the function resolution slightly depending on the available CPU features, i.e. so that you get an SSE-enabled memcpy() if your CPU does SSE and a plain one otherwise. If you want to open /proc/cpuinfo you need to call libc's open() call and a number of other libc API calls. And hence you might end up calling into libc in order to call into libc in order to call into libc in order to libc and so on forever until your stack overruns. These problems are all neatly avoided by simply using __get_cpuid() provided by gcc so that you can just shortcut all this... Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inherit MAC address for bridge from physical device
Am Thu, 9 May 2019 11:49:24 +0200 schrieb Olaf Hering : > With systemd-networkd it is apparently required to specify the MAC in the > configuration. As a result, such configuration is per host and not generic > anymore. This is now https://github.com/systemd/systemd/issues/12558, so it does not get lost in the noise. Olaf pgpspYD4dz4BS.pgp Description: Digitale Signatur von OpenPGP ___ 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] The first and the last things in systemd's lifecycle
On Tue, May 14, 2019 at 10:24 AM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote: > >>> Andrei Borzenkov schrieb am 14.05.2019 um 08:40 > in > Nachricht > : > > 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. > > Thanks, > > I'll start a new thread on this (I wanted to ask anyway): > AFAIK systemd does socket communication a lot, while old init was happy > with just a root filesystem. > So I wonder how this Hen-Egg_Problem is solved: Systemd needs a socket to > operate, but to provide the infrastructure, systemd would need the socket > do do so. > Or expressed in other words: How can systemd create /run when it needs > /run to operate? > 1. systemd performs these actions during initialization, before switching to the main loop. 2. systemd can operate without any sockets; it connects to D-Bus for control once it becomes available, but it's not a runtime requirement. > The corresponding question would be for shutdown: How will systemd unmount > /run? OK, if ist a ramdisk, it's not really needed. > The 'systemd-shutdown' binary doesn't unmount /run or /, it keeps the former and remounts the latter read-only. (It can optionally pivot_root *to* /run, though, and unmount / using the "shutdown initramfs" feature.) > > Another related question is that of shutdown in general: > For startup the semantics of Before= and After= are clear, but isn't it > just reverted for shutdown? That is if "M" has "After=X" and "Before=Y", > does that imply that Y is stopped before M will be stzopped, and M will be > stopped before X is? > Yes, it is reversed on shutdown. > > From the experience how fast shutdown happens, I don't think it's like > that. > Usually killing processes is faster than loading them from disk. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Antw: Re: rdrand generated with march=winchip-c6 in systemd-241
> The point I was trying to make was: "CPUID" and the model-specific registers > (thus the name) depend very much on the CPU being used. While the kernel makes > grat efforts to get things right, I wondered whether it's the best idea > whether > to repeat that effort in an application program. Compiler intrinsics are supposed to provide correct results independent of the OS that they're running on. It's not unreasonable for code to expect them to behave correctly. In this case it seems that an assumption that gcc made that's true for most CPUs isn't true for a specific (20 years old) CPU - that's a bug in gcc, and it's reasonable to ask for it to be fixed. There's a separate question of whether depending on the kernel for this information rather than using the compiler was the best solution, but it's pretty justified for applications to presume that the compiler works the way that the compiler is documented as behaving. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] The first and the last things in systemd's lifecycle
>>> Andrei Borzenkov schrieb am 14.05.2019 um 08:40 in Nachricht : > 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. Thanks, I'll start a new thread on this (I wanted to ask anyway): AFAIK systemd does socket communication a lot, while old init was happy with just a root filesystem. So I wonder how this Hen-Egg_Problem is solved: Systemd needs a socket to operate, but to provide the infrastructure, systemd would need the socket do do so. Or expressed in other words: How can systemd create /run when it needs /run to operate? The corresponding question would be for shutdown: How will systemd unmount /run? OK, if ist a ramdisk, it's not really needed. Another related question is that of shutdown in general: For startup the semantics of Before= and After= are clear, but isn't it just reverted for shutdown? That is if "M" has "After=X" and "Before=Y", does that imply that Y is stopped before M will be stzopped, and M will be stopped before X is? From the experience how fast shutdown happens, I don't think it's like that. Regards, Ulrich ___ 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
[systemd-devel] Antw: Re: Antw: Re: Explain status "Loaded: not-found (Reason: No such file or directory)"
>>> Lennart Poettering schrieb am 13.05.2019 um 09:46 in Nachricht <20190513074653.GC9036@gardel-login>: > On Mo, 13.05.19 07:48, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) wrote: > >> >> I guess it's not a file named "Reason" that's missing. Despite of my >> >> recommendation to create helpful error messages, can you explain what it >> > means? >> >> Even after an strace I could not find out what is missing. >> >> >> > >> > It means that unit definition file (iotwatch.target) was not found in >> > any directory where systemd looks for it. >> >> The confusing part is that something that cannot be found is "active" for 18 >> minutes ;‑) > > If you start a unit, then remove its unit file it remains started but > the unit file cannot be found anymore. We try to make the best of it: > leave the service running as well as possible, but will tell you the > unit file is now absent. > > Of course, it's not a good idea to remove a unit file while a service > is still running, but we cannot really stop you from doing so, this > being UNIX and all... Yes, that was a corner-case. I had updated the package via RPM, and it tried to do it's best with a service: If running, it tried to restart it after upgrade. In this case the generator was broken and effectively the unit file wasn't updated but effectively removed... I didn't realize quickly what was going on. Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Antw: Re: Antw: Re: rdrand generated with march=winchip-c6 in systemd-241
>>> Lennart Poettering schrieb am 13.05.2019 um 09:45 in Nachricht <20190513074503.GB9036@gardel-login>: > On Mo, 13.05.19 09:18, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) wrote: > > Please guys, stop it. > >> > cpuid has *nothing* to do with /proc/cpuinfo >> > >> > https://en.wikipedia.org/wiki/CPUID >> > The CPUID instruction (identified by a CPUID opcode) is a processor >> > supplementary instruction >> >> Isn't it about to check a CPU's feature depending on the CPU model? > > Ulrich, please understand that __get_cpuid() (which the discussion > here is about) is a gcc and llvm/clang feature weare are just making > use of. It used by various Linux software, and apparently doesn't work > entirely correctly on all CPUs in some corner case. The discussion is > about fixing gcc accordingly, and making it work, so that systemd all > all other software can work correctly. > > If you think that gcc/llvm are bad for "reimplementing /proc/cpuinfo" > then please bring that up with those communities, but please stop > these fruitless discussions here. The point I was trying to make was: "CPUID" and the model-specific registers (thus the name) depend very much on the CPU being used. While the kernel makes grat efforts to get things right, I wondered whether it's the best idea whether to repeat that effort in an application program. Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Can I enable/disable a target?
>>> Lennart Poettering schrieb am 13.05.2019 um 09:35 in Nachricht <20190513073539.GA9036@gardel-login>: > On Mo, 13.05.19 08:25, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) wrote: > >> >> Whenever I try to enable or disable a target (that exists), I get >> >> "Failed to execute operation: No such file or directory". What file >> >> or directory, please? Or what is the command trying to say? >> > >> > Well, "systemctl enable" could not find the target unit file in the >> > directories it searches for them. Where did you place the unit file? >> >> Meanwhile I know: My generator was using bash, and for more reliability I >> dared to add "set ‑u". As it turned out my version of Bash has a bug that >> causes false reports of unset variables with arrays, so the generator failed >> (the thread of handling exit codes of generators). As a consequence of that, >> the unit file wasn't created any more (which I hadn't realized at that > time). >> >> But still combining the concepts "operation" and "No such file or directory" >> is odd: An operation is neither a file nor a directory. > > On unix, this is typically how errors are shown. It's built into basic > ANSI C and POSIX concepts if you so will, as "perror()" will output > error messages like this: a short app message string followed by a > colon and a space character, followed by the system error string. The > system error string is one of the "errno" strings listed on the > errno(3) man page, i.e "No such file or directory" is ENOENT. The app > error string usually says what was attempted when the system error was > seen. > > systemd matches these UNIX semantics closely: we output error messages > exactly the same way as everything else on UNIX: a brief string > explaining what was attempted, followed by a colon, followed by a > space, followed by the system error string. > > I mean, sure we can always tweak error messages more, but we generally > start from how C and UNIX suggest these works, and then improve from > there. Thanks for the explanation. Actually I'm programming in C for about 30 years now. The point I had tried to address was: I think it doesn't make sense to use the low-level error code (or message) in a high level routine. Just imagine some find(1) command would output "No such file or directory" when no file matched the search criteria given. IMHO ERRNO-related messages should be used in combination of the syscall or library routine returning that error only. In practice any error message trying to interpret the cause of an error can be quite wrong sometimes. (Recently I was dealing with a "parse error" that actually meant the input was truncated, because the programmer did not expect that the input would exceed 1kB...) > > I mean, we are used to being blamed for everything by everyone, but if > you want to criticise ANSI/POSIX "perror()" style error messages on > principle, then please direct this towards the ANSI C and POSIX > committees first. I guess you have three buckets there for criticism: "Justified" , "Unjustified", and "Don't known" Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
