[systemd-devel] Q: Reducing the output of systemctl status
Hi! First, is it a well-known bug that "--quitet" seems to be ignored for "systemctl status"? It's the only command where --quiet makes sense IMHO, but it seems to have no effect in v228. Also, considering this example output: --- ● iotwatch@LOC1.service - iotwatch I/O performance monitor instance "LOC1" Loaded: loaded (/run/systemd/generator.late/iotwatch@LOC1.service; bad; vendor preset: disabled) Active: active (running) since Wed 2019-05-15 08:33:14 CEST; 2min 17s ago Docs: man:iotwatch(1) man:iotwatch@.service(8) Process: 13962 ExecStartPost=/usr/bin/sleep 0.2 (code=exited, status=0/SUCCESS) Process: 13950 ExecStart=iotwatch-LOC1 -l /var/log/iotwatch/LOC1/iotwatch-LOC1.log -m N -p/var/run/iotwatch-LOC1/iotwatch-LOC1.pid -d1 -a0.02 -b512 -i4 -sE -t2.0 -TA=0.025:0.035,X=0.25:0.75 -OR -OS:T=F75,S:M=O52,N:3.29/40,Q:C=100,P:nagios.nagios=0664 /etc/passwd (code=exited, status=0/SUCCESS) Process: 13929 ExecStartPre=/bin/sh -c [ -d "/var/log/iotwatch/LOC1" -o 1 -eq 0 ] || mkdir "/var/log/iotwatch/LOC1" || exit 3 (code=exited, status=0/SUCCESS) Process: 13913 ExecStartPre=/bin/sh -c [ -h "/var/run/iotwatch-LOC1/iotwatch-LOC1" ] || ln -s "/usr/bin/iotwatch" "/var/run/iotwatch-LOC1/iotwatch-LOC1" || exit 3 (code=exited, status=0/SUCCESS) Process: 13903 ExecStartPre=/bin/sh -c [ -d "/var/run/iotwatch-LOC1" ] || mkdir "/var/run/iotwatch-LOC1" || exit 3 (code=exited, status=0/SUCCESS) Main PID: 13960 (iotwatch-LOC1) Tasks: 4 (limit: 512) CGroup: /system.slice/system-iotwatch.slice/iotwatch@LOC1.service └─13960 iotwatch-LOC1 -l /var/log/iotwatch/LOC1/iotwatch-LOC1.log ... May 15 08:33:14 rksapv04 systemd[1]: Starting iotwatch I/O performance moni. May 15 08:33:14 rksapv04 systemd[1]: Started iotwatch I/O performance monit...". --- I wonder if I could suppress the "lesser-important" output, like pre- and post start commands. (Actually I had to add a manual sleep as the PID file is created by the child process after the parent exited, and systemd complained the PIDFile is not present yet.) I just noticed: If you use a "argv[0] override" for your command, it's not just that the command is started with that name, it's also displayed as ExecStart here (not path shown). I used it to shorten error messages using argv[0]. So I'd like a status output that simply displays: Active: active (running) since Wed 2019-05-15 08:33:14 CEST; 2min 17s ago Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: "bad" status for genersated target; why?
>>> Andrei Borzenkov schrieb am 14.05.2019 um 20:21 in Nachricht : > 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. So there's nothing wrong with the unit? > >> # 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 I think "Generated iotwatch.target cannot have a state" would be a much improved error message then. So again there's nothing wrong with the unit file? > dameon-reload" removes and re-creates all generated units, so any > symlink to such unit outside of generated subdirectories potentially > becomes invalid. I think all the symlink stuff should be an implementation detail that shouldn't be part of the user interface; instead there should be some higher-level commands to maipulate these. > > Documentation could be better indeed. Finally: If a generated unit cannot be enabled or disabled, isn't the "vendor-preset: disabled" the wrong choice: I specified nothing, and the logic should be: If a generator created a unit it should be enabled; otherwise sich a unit shouldn't be enabled. I couldn't find the relevant manual page that discusses this topic... Regards, Ulrich > ___ > 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: 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