Re: [systemd-devel] libraries can not found since 252
On Thu, Nov 23, 2023 at 02:33:55PM +0800, d tbsky wrote: > Hi: >I saw systemd 252 release notes: > > Private shared libraries (libsystemd-shared-nnn.so, > libsystemd-core-nnn.so) are now installed into arch-specific > directories to allow multi-arch installs. > > I don't know if that is related, but in RHEL 9.2/9.3, "ldd" result like > below: > > > ldd /usr/lib64/systemd/libsystemd-core-252.so > linux-vdso.so.1 (0x7ffed6708000) > libsystemd-shared-252.so => not found > ... I don't think this is related. The "arch-specific directories" here means that e.g. /usr/lib64/systemd/ is used instead of /usr/lib/systemd/. Neither path is in the normal library search path. Those libraries are not found by ldd because they are not in the public library search path. The binaries that use those libraries use RPATH to add /usr/lib64/systemd/ to the library search path and thus find libsystemd-core-252.so and libsystemd-shared-255.so. $ ldd /usr/lib/systemd/systemd | rg libsystemd libsystemd-core-255.so => /usr/lib64/systemd/libsystemd-core-255.so (0x7fd54100) libsystemd-shared-255.so => /usr/lib64/systemd/libsystemd-shared-255.so (0x7fd540a0) > it seems other distributions(debian,suse) are in the same situation. > it will cause utilities like ReaR(relax and recover) failed to find > the libraries. I don't know the reason behind the design. should the > situation fixed by systemd, by os distribution, or the utility need to > handle that itself? I don't know what ReaR is, so I can't comment on that specifically. But in general, there is no "problem". Those libraries have an unstable ABI, so they are tucked away in a separate directory and are not intended to be found during a search. This seems to work just fine. Zbyszek
Re: [systemd-devel] Is systemd-cryptsetup binary internal?
On Mon, Sep 18, 2023 at 04:17:49PM +0200, Lennart Poettering wrote: > On Mo, 18.09.23 15:22, mpan (systemdml-bfok4...@mpan.pl) wrote: > > > Hello, > > > > I got redirected to here from #systemd on Libera. While responding to a > > query from another person (not on #systemd), I came across an ambiguity. Any > > answer I give, its validity would be uncertain. I wish to receive an > > authoritative clarification. > > > > There is systemd-cryptsetup binary in “/usr/lib/systemd/”. Its location > > suggests it’s internal to systemd and not intended for user invocation. > > However, it is also listed in manual as if it was something the user might > > be concerned with. The manual even has a specific, separate, explicit > > reference to systemd-cryptsetup page — though it’s shared with the > > corresponding service and the binary itself isn’t described. > > /usr/lib/systemd/ is indeed the place for internal binaries with > unstable interfaces. But it's also the place where we put binaries > that we don't typically expect users to call, because they are > generally called via some well define .service unit or so only. > > systemd-cryptsetup is one of the latter, we'd expect people to use > this via crypttab mostly. However, the interface is nonetheless > stable, it is a long-time part of systemd and so far we never broke > interface and I see no reason we ever would. In fact it might be a > candidate to move over to /usr/bin to make official, if there's > sufficient request for that. (such a request should be made via github > issue tracker) > > > Thanks in advance for indicating, if systemd-cryptsetup (the binary) is a > > tool users may rely on. > > Yes, absolutely. > > The only reason when we might break things for you is when we one day > move it from /usr/lib to /usr/bin, ;-) Actually, this wouldn't be a breaking change. If we were to move it, we'd most likely provide a compat symlink… > Hence: the call interface is certainly stable, the location in that > sense maybe not yet. Yeah. If there's interest, we could certainly move it to /usr/bin. Zbyszek
Re: [systemd-devel] Networkd's IPv6 Compliance Issues
On Wed, Jul 26, 2023 at 03:23:14AM +, Muggeridge, Matt wrote: > Hi, > > Recently, we ran a test suite to check networkd's conformance to IPv6 > Protocol (see https://www.ipv6ready.org/resources.html). I found a large > number of test failures (more than 80) and after examining a small number of > them, it became clear that networkd's implementation of IPv6 protocol does > not meet various RFC's MUST and SHOULD requirements. > > With so many IPv6 protocol compliance failures, it's not practical for me to > raise an issue for every failing case. Instead, I created a summary in > https://github.com/systemd/systemd/issues/28502. > > How would you like to handle these failing cases? > > Is there any more information you need from me? I think #28502 should be enough. If people have questions, they'll ask there. Zbyszek
[systemd-devel] deprecating Forward-Secure Sealing (FSS) in the journal
Hi, I'd like to start $subject. First, we'd just add an entry in NEWS and make the key generation code print a warning, but then in a release or few remove the code. See https://github.com/systemd/systemd/pull/28433/commits/1ecd1a994733d. If you're using FSS, please speak up. Zbyszek
Re: [systemd-devel] Root remaining read-only after boot, no obvious reason why
On Tue, May 16, 2023 at 05:26:00PM +, Dave Re wrote: > One step I haven't taken is turning on debug level logging in systemd - not > sure what to expect (or not expect) out of it, but I guess that's my next > step. I'd welcome any pointers to debugging resources, etc, but realize this > is an older version of systemd. https://freedesktop.org/wiki/Software/systemd/Debugging/ Zbyszek
Re: [systemd-devel] Root remaining read-only after boot, no obvious reason why
On Tue, May 16, 2023 at 02:37:58PM +, Dave Re wrote: > > Hi, Zbyszek, > > The kernel default is to mount root ro, so unless there's some configuration > to > mount or remount it rw, it'll stay ro. Generally this is configured in two > places 'rw' on the kernel command line and 'rw' in /etc/fstab. Do you have > one or both of those? > Yes. In this case, the kernel command line in grub contains the usual "ro" > option, but /etc/fstab has an entry for root with "defaults" as the sole > option. Default options are theoretically "rw, suid, dev, exec, auto, nouser, > and async". To verify, I placed that option list in /etc/fstab for root, and > saw the same behavior on reboot, so I eliminated the fstab entry as a > potential issue. Yes, systemd-remount-fs just calls 'mount -o remount /', and that remounts rw if 'ro' has not been specified. So the problem seems to be elsewhere. > Also related - the device is identified in fstab by UUID, not by label or > partition. I verified the UUID of the device still matches the UUID in fstab, > etc. This shouldn't matter. For the remount, we look for the file system by mountpoint. > If I change the kernel command line in grub to use "rw", root mounts rw as > expected. > If a remount is done, it'll be done by systemd-remount-fs.service. Do you > see it in the logs? > Ah, I misunderstood initrd-switch-root - thanks. On a system that > successfully boots with root mounted rw, I don't see anything about > systemd-remount-fs.service until it's shutdown, when the service is stopped, > but systemd was ratelimited by the kernel on that boot, so a startup message > may have been missed. But - I can see that systemd-remount-fs.service is > Active/exited (via systemctl status command). > > On the problem system, systemd-remount-fs.service is inactive/dead - and > shows the same status if I reboot with "rw" on the kernel command line (which > would be expected, given our symptoms, I think?). OK, so this is the problem. It seems that the service wasn't started at all. > On both systems, it's linked in /usr/lib/systemd/system/local-fs.target.wants > - so, should be run as part of getting to that target, if I understand > correctly? What should my next step be to determine why it's not being run? Yes. Hmm, so we stopped enabling systemd-remount-fs.service in this way back in 2018 (https://github.com/systemd/systemd/commit/9b69569d2c). At this point, that's ancient history for us ;) Zbyszek
Re: [systemd-devel] Root remaining read-only after boot, no obvious reason why
On Mon, May 15, 2023 at 10:21:27PM +, Dave Re wrote: > > Hi, all, > > Hoping to get some assistance root causing this issue. We have a set of > CentOS 7 based systems in AWS that we're using the leapp tool to migrate to > AlmaLinux 8.7. Following migration, the root filesystem is ending up being > mounted read-only, and I'm having a devil of a time figuring out why. There > are no helpful (to me) messages in dmesg, or on the console during boot. Root > on these machines is xfs - the filesystems appear to be intact, and running > "sudo mount -o rw,remount /" following boot succeeds straight away. The kernel default is to mount root ro, so unless there's some configuration to mount or remount it rw, it'll stay ro. Generally this is configured in two places 'rw' on the kernel command line and 'rw' in /etc/fstab. Do you have one or both of those? If a remount is done, it'll be done by systemd-remount-fs.service. Do you see it in the logs? Zbyszek
Re: [systemd-devel] Unsubscribing doesn't work.
On Mon, Mar 20, 2023 at 01:50:02PM -0400, Znoteer wrote: > Hi, > > I've tried twice sending an email to systemd-devel-request@l.f.o with > unsubscribe in the subject and then in the body. Thoese mails were both > rejected. > > I tried also subscribing via the maillist web site form. That also hasn't > unsubscribed me. > > Can someone please tell me the correct way to unsubscribe from this list? You need to unsubscribe through the web interface. Zbyszek
Re: [systemd-devel] systemd-timer way of queuing jobs like 'at' command does ?
On Thu, Dec 22, 2022 at 08:00:06PM +1100, Michael Chapman wrote: > On Thu, 22 Dec 2022, Andrei Borzenkov wrote: > > On Thu, Dec 22, 2022 at 11:17 AM Nicolas Pillot > > wrote: > > > > > > Hello > > > > > > I am wondering if i can dynamically plan jobs (once) using systemd timer. > > > What i mean by that is kind of replicating the usage of the 'at' command > > > > > > > systemd-run --on-calendar=tomorrow echo I am at replacement > > Curiously that gives me (on v250): > > $ systemd-run --on-calendar=tomorrow echo I am at replacement > Failed to parse calendar event specification: Invalid argument > > Known bug? `systemd-analyze timestamp tomorrow` can parse > it... > > This is still slightly different from "at" though, since the timer and > service are transient: they are lost if the system is rebooted. This is because it's a "calendar expression", not a "timestamp": 'systemd-analyze calendar tomorrow' fails. But I'm surprised by this, and the docs even even say that calendar expressions are a superset of the timestamp expressions. So it might be a bug. Feel free to file an issue. Zbyszek
Re: [systemd-devel] Fwd: make pystemd part of systemd repo.
[I misplaced the original mail, so I'm replying to a forward. Apologies if threading is broken.] > What do we propose to do? > - > > We want to bring pystemd[1] into the systemd organization, and merge > (functionality wise) with python-systemd[2], so that there is a single > Python library, supported by the systemd community, that interacts > with the systemd API. In short, you propose to subsume bring pystemd under the systemd org umbrella and to subsume python-systemd functionality into pystemd. I think this makes the most sense. > systemd has a Python library already under the organization: > python-systemd. This library does some interesting stuff with the > journal (my personal favorite is creating a Python logger that talks > directly with the journal, kudos to whoever did that!). Marti Raudsepp, 603876167a7ea78d0a71d70766f65979618ca423. > But in my honest opinion, this library is missing some core > functionality to interact with systemd: the service manager, > start/stop/interaction with Units, create ephemeral units, etc. At > Meta (the company formerly known as Facebook) we created a python > library that does that… among other things. The functionality in python-systemd is fairly cleanly split between the python frontent, and the the C backend which is a thin wrapper around libsystemd. When pystemd functions replace the backend, it should be possible to move the higher-level code without minimal changes. > with Unit(b'postfix.service') as unit: >if unit.Unit.ActiveState == b"active": >unit.Unit.Stop(b'replace') Not that it matters for this discussion, but what with all those b'' prefixes? systemd itself doesn't do non-unicode, so it should all be trivially translatable to and from str. > How do we propose to do this? > - > > Preliminary plan (of course we are open to any suggestions) look like this: > > 1. We move pystemd repo [1] into the systemd org, something like > https://github.com/systemd/pystemd > 2. People with commit access to this repo (Davide, Anita and me) would > remain having commit access to this repo, and whoever has access to > the python-systemd repo [2] would be added here. > 3. We merge all features of python-systemd (that are not in pystemd > yet) into pystemd, this will probably mean re-writing most of those > features. Development would be done by mostly me, with code review and > from hopefully as close to the original authors as possible… Basically > I don't want to be disrespectful of python-systemd. This sounds all good. > 4. If we want to keep the name python-systemd (and the import > namespace of systemd) we can rename the repo as python-systemd, if we > want to keep pystemd as the name of the package and the import > namespace, we can make python-systemd as “a link” to pystemd > 5. Whatever we decide on the last point, we cut the version 1.0.0 of > pystemd, or the next version of python-systemd. And we let the new era > of Python bindings start! I'd keep the names as they are. Renames create confusion, and I think everything will be easier if we keep the original names and keep things parallel-installable. Thank you for doing this. Zbyszek
Re: [systemd-devel] Configuring systemd to build systemd-tempfiles in Yocto
On Mon, May 23, 2022 at 01:24:44PM +, Dave Glenton wrote: > Sorry if this question is covered elsewhere, but a couple of days of googling > and experimentation has failed to find a solution and hopefully someone in > this list can give me some pointers. > > I am trying to configure an Open Embedded Yocto Linux build based round > systemd version 249.7, however the resulting image is missing a number of > binaries in the /usr/bin directory, specifically systemd-tmpfiles which is > present on my Ubuntu 20.04 build machine. > > I believe there should be parameters you can pass at build to configure what > is generated, but I am struggling to find any documentation as to what they > are and how you pass them to Meson / Ninja. There is a meson configuration option: -Dtmpfiles=true|false, with true being the default value. I can't say anything what Yocto is doing. But it sounds like a local configuration issue, the upstream default is to build most features. Zbyszek > > If I run systemd --version I get the following on Ubuntu > > systemd --version > systemd 245 (245.4-4ubuntu3.15) > +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP > +GCRYPT +GNUTLS > +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 > default-hierarchy=hybrid > > on this on Yocto > > systemd 249 (249.7+) > -PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK +SECCOMP -GCRYPT -GNUTLS > -OPENSSL +ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC +KMOD > -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -BZIP2 > -LZ4 -XZ -ZLIB +ZSTD +XKBCOMMON +UTMP +SYSVINIT > default-hierarchy=hybrid > > $ ls -la /usr/bin | grep systemd > 10-rwxr-xr-x 1 root root 14384 Mar 9 2018 psplash-systemd > 11-rwxr-xr-x 1 root root 18552 Mar 9 2018 systemd-cat > 12-rwxr-xr-x 1 root root 18656 Mar 9 2018 systemd-cgls > 13-rwxr-xr-x 1 root root 39048 Mar 9 2018 systemd-cgtop > 14-rwxr-xr-x 1 root root 26744 Mar 9 2018 systemd-delta > 15-rwxr-xr-x 1 root root 18552 Mar 9 2018 systemd-detect-virt > 16-rwxr-xr-x 1 root root 35112 Mar 9 2018 systemd-dissect > 17-rwxr-xr-x 1 root root 22640 Mar 9 2018 systemd-id128 > 18-rwxr-xr-x 1 root root 51544 Mar 9 2018 systemd-mount > 19-rwxr-xr-x 1 root root 18544 Mar 9 2018 systemd-path > 20lrwxrwxrwx 1 root root 10 Mar 9 2018 systemd-resolve -> > resolvectl > 21-rwxr-xr-x 1 root root 59712 Mar 9 2018 systemd-run > 22-rwxr-xr-x 1 root root 26752 Mar 9 2018 systemd-socket-activate > 23-rwxr-xr-x 1 root root 18560 Mar 9 2018 systemd-stdio-bridge > 24lrwxrwxrwx 1 root root 13 Mar 9 2018 systemd-umount -> > systemd-mount > > Regards > > Dave Glenton
Re: [systemd-devel] issues with systemd-cryptsetup@.service after in 251-rc3
On Fri, May 20, 2022 at 03:51:58PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, May 19, 2022 at 01:42:43PM +0200, Daan De Meyer wrote: > > > Am 19.05.22 um 05:32 schrieb Dusty Mabe: > > > > I'm requesting help to try to find a problematic commit between > > > > v251-rc2..v251-rc3. > > > > > > > > We have a test in Fedora CoreOS [1] that tests luks and this test > > > > started failing in our rawhide stream with the introduction of > > > > 251-rc3. Reverting back to 251-rc2 makes the failing test go away. I > > > > briefly looked at the commits from v251-rc2..v251-rc3 but nothing > > > > jumped out at me. > > > > > > > > Any commits in there that we think might be risky or ones we should > > > > look at closer? > > > > > > Please bisect. It’s the most efficient way, and you can do it yourself, > > > especially as you have a test to reproduce the issue. > > > > > > > Here's the original bug [2] I opened against Fedora CoreOS: > > > > > [1] > > > > https://github.com/coreos/fedora-coreos-config/tree/testing-devel/tests/kola/root-reprovision/luks > > > > [2] https://github.com/coreos/fedora-coreos-tracker/issues/1200 > > No idea. There were a few changes to udev and sd-device, and it's > possible that they caused some regression. But I don't see anything > obvious. https://koji.fedoraproject.org/koji/taskinfo?taskID=87360713 has a scratch builds with one patch reverted. Could you test if it fixes the issue? Zbyszek
Re: [systemd-devel] issues with systemd-cryptsetup@.service after in 251-rc3
On Thu, May 19, 2022 at 01:42:43PM +0200, Daan De Meyer wrote: > > Am 19.05.22 um 05:32 schrieb Dusty Mabe: > > > I'm requesting help to try to find a problematic commit between > > > v251-rc2..v251-rc3. > > > > > > We have a test in Fedora CoreOS [1] that tests luks and this test > > > started failing in our rawhide stream with the introduction of > > > 251-rc3. Reverting back to 251-rc2 makes the failing test go away. I > > > briefly looked at the commits from v251-rc2..v251-rc3 but nothing > > > jumped out at me. > > > > > > Any commits in there that we think might be risky or ones we should > > > look at closer? > > > > Please bisect. It’s the most efficient way, and you can do it yourself, > > especially as you have a test to reproduce the issue. > > > > > Here's the original bug [2] I opened against Fedora CoreOS: > > > [1] > > > https://github.com/coreos/fedora-coreos-config/tree/testing-devel/tests/kola/root-reprovision/luks > > > [2] https://github.com/coreos/fedora-coreos-tracker/issues/1200 No idea. There were a few changes to udev and sd-device, and it's possible that they caused some regression. But I don't see anything obvious. Zbyszek
Re: [systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
On Mon, May 09, 2022 at 03:57:21PM +0200, Lennart Poettering wrote: > On Mo, 09.05.22 11:23, Thomas Haller (thal...@redhat.com) wrote: > > > Hi everybody, > > > > this email is for discussing MACAddressPolicy=persistent in > > /data/src/systemd/network/99-default.link > > I think this would be better discussed on a new github issue, as > suggested here: I suggested systemd-devel for this… It's not a question of a bug, but instead whether the default MACAddressPolicy makes sense. So I think it's better to discuss this on the mailing list. FWIW, I still think it's a better _default_. The patch that finally introduced this was my patch [1], so I'm obviously biased… Some more considerations: 1. this allows bridge devices to be created without attached interfaces, and have a stable MAC address. 2. the idea that all interfaces are always available and always in the same order is something that isn't necessarilly true for modern systems where we want to react to hardware being detected dynamically. If we wait until late userspace to configure networking, then yeah, all devices will most likely have been detected by that time. But if we want to bring networking in the initrd, not all hardware must be detected by the time we start configuration. 3. one of the reasons to use bridge/bond and similar devices it that the agreggate device can function when some of the child devices die. By requiring the presence of one of the devices, we're partially defeating this. [1] https://github.com/systemd/systemd/commit/6d36464065 > 1) for bridge/bond interfaces, there is a special meaning of leaving > the MAC address unassigned. It causes kernel to automatically set the > MAC address when the first port gets attached. By setting a persistent > MAC address, that automatism is not longer possible. > > The MAC address can matter, for example, if you configure the DHCP > server to hand out IP addresses based on the MAC address (or based on > the client-id, which in turn might be based on the MAC address). If you > boot many machines (e.g. in data center or cloud), you might know the > MAC address of the machines, and thereby can also determine the > assigned IP addresses. With MACAddressPolicy=persistent the MAC address > is not predictable. This is true. But one can just as well argument that with MACAddressPolicy=persistent the address is even more predictable. If you know the machine-id and device name, you can calculate the address in advance, even before deciding if the device will e.g. have this or that card attached. I'm not sure if we expose this conveniently anywhere… Would it help if we document how to do this calculation with python one-liner or some helper? > 2) udev changing the MAC address causes races with naive scripts/tools. > For example: > > ip monitor link & > while : ; do > ip link del xxx > ip link add name xxx type dummy \ > && ip link set xxx addr aa:00:00:00:00:00 \ > && ip link show xxx | grep -q aa:00:00:00:00:00 \ > || break > done Again, this is a question of expecations. With MACAP=p, 'dummy' gets the same address every time, and maybe there's no reason to set it manually. It would be great if we could have 'ip link add' wait for udev to process the device. Maybe even by default? We also discussed adding a kernel command-line switch similar to net.ifnames= to allow this to be configured globally. Would that help? The cases where the old behaviour is relied on seems to be cases like the data center described above. But in that case you're creating local configuration anyway, so dropping in an override should be acceptable. Zbyszek > https://github.com/systemd/systemd/issues/3374#issuecomment-1031072530 > > or here: > > https://github.com/systemd/systemd/issues/3374#issuecomment-601240730
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 11:40:36AM -0400, Neal Gompa wrote: > On Wed, Apr 27, 2022 at 11:26 AM Dan Nicholson wrote: > > > > On Wed, Apr 27, 2022 at 9:10 AM Neal Gompa wrote: > > > > > > Note that it means Fedora CI, pull requests from contributors, and > > > releng auto-rebuilds will no longer work. Maintainers basically > > > sign-on to do all of those things manually and have to be responsive > > > for doing it. You will get FTBFS tickets every cycle because of it, > > > for example. > > > > Asking systemd folks to change their development process because of > > limitations in Fedora/Koji seems like a big ask, don't you think? > > Honestly, that never factors in for me, because then I'd never ask > anything of anyone. :) > > But no, it doesn't sound unreasonable to me, because I reasonably > expect the parts that make up the EFI boot manager code to be somewhat > separate from the rest of the codebase in the first place. It targets > a different build environment and has to be built differently from the > rest of systemd anyway. So to me, it's not a "big ask" as you put it. Once more (this has already been written *independently* by Lennart and me, but let's say it once again): THE USERSPACE AND EFI-SPACE PARTS SHARE CODE, the configuration system and the build system. So if we split them, we'd probably want to update them in tandem anyway, and it's just easier to do it, then to try to figure out if the sd-boot parts didn't change and we can skip the update. Since the signing is automatic once configured, I can't grok what savings people foresee by doing separate builds. > But I also strongly believe that it was a mistake to merge gummiboot > into the systemd source tree because it creates all kinds of problems > for distro maintenance, as I've already said earlier. It also > discourages making the sd-boot code tighter and simpler since your > primary focus is reuse across the tree rather than strictly separating > the functional domains. There are downsides, but there are also benefits: 1. code sharing (it's not a lot, but even some is better than nothing, and the amount is growing). 2. when implementing features that have a "producer side" and a "consumer side", e.g. as with the random-seed integration in the bootloader and pid1 and bootctl, it's *much* easier if all parts of the code can be implemented and viewed and tested together. Splitting things into separate projects adds overhead. This overhead is not too great, so it's always a question of balance, but so far the integration of sd-boot with systemds has generally made the the development of both sides easier. Also, with any boot menu stuff, we want to have functional equivalency for sd-boot and bootctl, and that also is much easier if it's just one repo, even if the implementations are separate. 3. one project is less work than two projects. Zbyszek
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 11:48:04AM -0400, Neal Gompa wrote: > On Wed, Apr 27, 2022 at 11:46 AM Luca Boccassi wrote: > > > > On Wed, 2022-04-27 at 11:26 -0400, Neal Gompa wrote: > > > On Wed, Apr 27, 2022 at 11:13 AM Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > > > > > On Wed, Apr 27, 2022 at 09:31:10AM -0400, Neal Gompa wrote: > > > > > On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering > > > > > > > Realistically, I think if we want to make movement on making > > > > > > > systemd-boot fully supported in Fedora, the systemd-boot boot > > > > > > > manager > > > > > > > code itself should be split out into its own repository with its > > > > > > > own > > > > > > > release cadence, while bootctl(1) and related infrastructure > > > > > > > remains > > > > > > > in the systemd source tree and evolves to be able to manage > > > > > > > arbitrary > > > > > > > BLS-conformant boot managers. > > > > > > > > > > > > Why though? I don't follow? as long as we provide you with a tarball > > > > > > you can build your stuff from it shouldn't really matter if there's > > > > > > more stuff in it you are not immediately interested in. > > > > > > > > > > > > I mean, if you like I could do a "cp systemd-251.tar.gz > > > > > > systemd-boot-251.tar.gz" for you if you want two tarballs instead of > > > > > > one, but I don't see the point? > > > > > > > > > > > > > > > > As I illustrated in another email[5], decoupling the lifecycle of the > > > > > EFI boot manager code from the rest of systemd would be ideal to not > > > > > make the constraints around building sd-boot with secure boot support > > > > > painful. > > > > > > > > > > [5]: > > > > > https://lists.freedesktop.org/archives/systemd-devel/2022-April/047801.html > > > > > > > > Apart from the constraint who can build official packages, is there > > > > anything else? If it's just that, that doesn't seem onerous. > > > > > > It also means Fedora CI, pull requests from contributors, and > > > releng auto-rebuilds will no longer work. Maintainers basically > > > sign-on to do all of those things manually and have to be responsive > > > for doing it. You will get FTBFS tickets every cycle because of it, > > > for example. > > > > > > Koji doesn't conceptually know the difference because there is no > > > namespacing for builders, only who is approved to build. > > > > > > (In contrast, in the Open Build Service like what Luca Boccassi was > > > talking about, packagers don't control the builds at all, so OBS only > > > has to trust itself to sign it, so everything works properly.) > > > > You could simply have a separate source RPM, no? That should be pretty > > simple, and limit the impact on team maintenance of the main source > > package? >From what I can see, it'd be strictly more work for the maintainers (*). I keep asking, but I'm not getting any answers! There's some supposed benefits, but apart from vague handwaving, I don't see anything. (*) Two packages two build instead of one. It's not a huge difference, but from experience, it's confusing to contributors and annoying for maintainers to remember to duplicate the work. > Yep. I was hoping we could have the upstream sources split too, but if > we can't, then that's definitely the preferred way to go. Again, [citation needed] for why this would be of benefit. Zbsyzek
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 11:26:14AM -0400, Neal Gompa wrote: > On Wed, Apr 27, 2022 at 11:13 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, Apr 27, 2022 at 09:31:10AM -0400, Neal Gompa wrote: > > > On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering > > > wrote: > > > It is not very friendly when you're in a failure scenario or have to > > > deal with boot stuff. > > > > Well, if you have a boot failure, then a text-based interface is better > > than a graphical one. I.e. while we might want to make it easier to discover > > disks and state from sd-boot, I doubt that adding support for icons and > > themes would be of any help in failure scenarios. > > > > > I know it more or less looks like Fedora's GRUB > > > is configured today, but Fedora is an outlier among Linux > > > distributions in that it doesn't theme GRUB or provide more > > > user-friendly boot configure out of the box. I don't like it and I'd > > > like to change this someday. > > > > E.g. the biggest development in how the boot looks in recent years > > in Fedora has been hiding on the boot menus and boot messages by > > default. I.e. the _design_ is that you start with the logo of the > > manufacturer which is seamlessly replaced by the gdm login screen. > > How the boot menu looks never factors into any of this. > > > > Hiding them by default doesn't mean making them scary and semi-useless > when you access them. Most people don't access UEFI menus very often, > if at all, and yet a huge amount of investment went into making that > UX better than it was in the past. Is it spectacular? No. Is it less > scary? Absolutely. > > Even with rEFInd, I'd probably want to do it that way because the > point of rEFInd is to make the emergency cases and multiboot cases > more approachable, not to present it all the time by default. > > > > Well, if you're installing and managing EFI binaries (as bootctl > > > does), you can design a scheme to allow bootctl to know what to do in > > > those circumstances. > > > > > > As a back of the napkin example, say you offer the user three EFI boot > > > manager options: rEFInd, sd-boot, or GRUB. The distribution may prefer > > > GRUB, sd-boot, or rEFInd, and define that as a config file for bootctl > > > to read. But if the user wants to override this choice, they could > > > pass --bootloader= to the install subcommand. That would write > > > out a config file in /etc/systemd/boot declaring which bootloader the > > > user chose as the "default" for future bootctl invocations and allow > > > the commands to work. > > > > --bootloader= sounds like something we can do. OTOH, I agree > > with what Lennart wrote elsewhere: we don't want to get into the > > business of fiddling with special files that'd be specific so some > > bootloader. > > > > Currently the update command only does the update if it find sd-boot. > > We could enhance it to update other installations (if it find matching > > files under /usr/lib somewhere. (I'd rather make it /usr/lib/boot/, > > but I think we can talk about directory names later.) > > > > That's more or less what I want. I don't really want bootctl being > *too* smart. Even for sd-boot, it doesn't do that much, and I'd rather > keep it that limited. If you need to do fancier bootloader specific > things, use the appropriate tools. > > > > The bootloaders themselves could be stored in > > > /usr/lib/systemd/boot/efi//, where is the bootloader name > > > passed to bootctl. It would then know to copy all the files from that > > > directory into the ESP. > > > > > > > > The second problem is because having sd-boot in the systemd source > > > > > tree means that in order for Fedora to sign the boot manager EFI > > > > > binaries, we have to lock down the systemd source package to the > > > > > secure boot Koji build channel. This is unequivocally unacceptable > > > > > from my point of view, as the restrictions around the secure boot > > > > > channel make it realistically impossible for community contribution > > > > > and maintenance of the package. > > > > > > > > I don't follow. Where's the problem using the same source package for > > > > two independently built RPM packages? > > > > > > > > If Fedora wants to build systemd userspace packages one way, and > > > > systemd-boot another way, that's entirely fine actually. they can just > >
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 09:31:10AM -0400, Neal Gompa wrote: > On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering > wrote: > It is not very friendly when you're in a failure scenario or have to > deal with boot stuff. Well, if you have a boot failure, then a text-based interface is better than a graphical one. I.e. while we might want to make it easier to discover disks and state from sd-boot, I doubt that adding support for icons and themes would be of any help in failure scenarios. > I know it more or less looks like Fedora's GRUB > is configured today, but Fedora is an outlier among Linux > distributions in that it doesn't theme GRUB or provide more > user-friendly boot configure out of the box. I don't like it and I'd > like to change this someday. E.g. the biggest development in how the boot looks in recent years in Fedora has been hiding on the boot menus and boot messages by default. I.e. the _design_ is that you start with the logo of the manufacturer which is seamlessly replaced by the gdm login screen. How the boot menu looks never factors into any of this. > Well, if you're installing and managing EFI binaries (as bootctl > does), you can design a scheme to allow bootctl to know what to do in > those circumstances. > > As a back of the napkin example, say you offer the user three EFI boot > manager options: rEFInd, sd-boot, or GRUB. The distribution may prefer > GRUB, sd-boot, or rEFInd, and define that as a config file for bootctl > to read. But if the user wants to override this choice, they could > pass --bootloader= to the install subcommand. That would write > out a config file in /etc/systemd/boot declaring which bootloader the > user chose as the "default" for future bootctl invocations and allow > the commands to work. --bootloader= sounds like something we can do. OTOH, I agree with what Lennart wrote elsewhere: we don't want to get into the business of fiddling with special files that'd be specific so some bootloader. Currently the update command only does the update if it find sd-boot. We could enhance it to update other installations (if it find matching files under /usr/lib somewhere. (I'd rather make it /usr/lib/boot/, but I think we can talk about directory names later.) > The bootloaders themselves could be stored in > /usr/lib/systemd/boot/efi//, where is the bootloader name > passed to bootctl. It would then know to copy all the files from that > directory into the ESP. > > > > The second problem is because having sd-boot in the systemd source > > > tree means that in order for Fedora to sign the boot manager EFI > > > binaries, we have to lock down the systemd source package to the > > > secure boot Koji build channel. This is unequivocally unacceptable > > > from my point of view, as the restrictions around the secure boot > > > channel make it realistically impossible for community contribution > > > and maintenance of the package. > > > > I don't follow. Where's the problem using the same source package for > > two independently built RPM packages? > > > > If Fedora wants to build systemd userspace packages one way, and > > systemd-boot another way, that's entirely fine actually. they can just > > do that… > > > > > Realistically, I think if we want to make movement on making > > > systemd-boot fully supported in Fedora, the systemd-boot boot manager > > > code itself should be split out into its own repository with its own > > > release cadence, while bootctl(1) and related infrastructure remains > > > in the systemd source tree and evolves to be able to manage arbitrary > > > BLS-conformant boot managers. > > > > Why though? I don't follow? as long as we provide you with a tarball > > you can build your stuff from it shouldn't really matter if there's > > more stuff in it you are not immediately interested in. > > > > I mean, if you like I could do a "cp systemd-251.tar.gz > > systemd-boot-251.tar.gz" for you if you want two tarballs instead of > > one, but I don't see the point? > > > > As I illustrated in another email[5], decoupling the lifecycle of the > EFI boot manager code from the rest of systemd would be ideal to not > make the constraints around building sd-boot with secure boot support > painful. > > [5]: > https://lists.freedesktop.org/archives/systemd-devel/2022-April/047801.html Apart from the constraint who can build official packages, is there anything else? If it's just that, that doesn't seem onerous. > > > This would also (hopefully) encourage other boot managers to support > > > the Bootloader Spec configuration model, making it succeed as a > > > semi-universal abstraction for boot manager configuration. > > > > I don't think grub developers really care about bootctl. They probably > > never heard of it I figure ;-). > > > > I am not sure what the reason of the general disinterest from their > > camp towards integration with userspace/systemd is. But I doubt that > > a missing reorganization our tarballs is what is stopping them... >
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 08:55:55AM -0400, Neal Gompa wrote:
> On Wed, Apr 27, 2022 at 6:47 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Tue, Apr 26, 2022 at 07:12:02PM -0400, Neal Gompa wrote:
> > > Hey all,
> >
> > Hi Neal,
> >
> > thank you for starting the discussion. I think it'd be good to figure
> > out what are the high-level options we have as a community…
> >
> > > Some of you might know about the recent discussion in Fedora about
> > > dropping BIOS support[1][2]. While the end result for now is that
> > > we're not dropping it[3], several side discussions involved enabling
> > > systemd-boot as an option in Fedora in the future.
> > >
> > > While I *personally* am not a huge fan of systemd-boot itself
> >
> > You mentioned that a few times, and we (at least Lennnart and I) have
> > asked for details. If there's something important missing from sd-boot,
> > we would like to know.
> >
>
> I think this is probably a distraction from this discussion, but sure
> I guess I can answer: I fundamentally dislike systemd-boot because I
> feel it's not a very user-friendly boot manager because of its
> absolutely spartan interface. I'm much more of a fan of rEFInd[1],
> which provides a feature-rich and user-friendly EFI boot manager[2].
Ah, icons and graphics ;) Yeah, we don't provide that, and I don't think
there are any plans to work on this. Instead of trying to make the menu
better, we can follow the example of windows: integrate the boot menu
directly in the graphical environment. We already have command-line access
to this: bootctl reboot-to-firmware, bootctl set-oneshot,
systemctl reboot --boot-loader-entry=. With a little bit of integration
users should be able to select the system / kernel to boot directly
from the reboot dialogue.
Rebooting from the DE has advantages: nice UI without much work, l10n,
accessibility, help, integration with normal auth mechanisms (e.g. polkit
auth for non-default boot entries or firmware setup), no need to
fiddle with pressing keys at the exactly right time.
> Essentially, the Koji build channel for secure boot is made up of three
> things:
[snip]
Thanks for the description. If the limitation that only RH folks can
build the official package is true, it'd be annoying, but not such a big
issue. In the recent times, I made the most builds, with Adam Williamson
and Yu Watanabe also doing an occasional build, i.e. all RH employees. It
is important that people can do pull requests for dist-git, but limiting the
offical builds to a few people wouldn't be a big issue. (Don't get me wrong:
I would prefer to keep the current state where a bunch of maintainer *and*
any proven packager or relengee can build systemd, but in practice it doesn't
happen much.)
> For sd-boot, it'd be making sure the package is "ExclusiveArch:
> %{efi}", then in %install, you'd do:
>
> pushd %{buildroot}%{_prefix}/lib/systemd/boot/efi
> %pesign -s -i systemd-boot%{efi_arch}.efi -o
> systemd-boot%{efi_arch}.efi.signed
> popd
https://src.fedoraproject.org/rpms/systemd/pull-request/77
does the deed. PTAL. (Though it just conditionalized the build on
%ifarch %efi, instead of limiting where the package is built. In mock
this produces an additional .signed thingy that 'bootctl update'
should pick up automatically.)
Zbyszek
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Tue, Apr 26, 2022 at 07:12:02PM -0400, Neal Gompa wrote: > Hey all, Hi Neal, thank you for starting the discussion. I think it'd be good to figure out what are the high-level options we have as a community… > Some of you might know about the recent discussion in Fedora about > dropping BIOS support[1][2]. While the end result for now is that > we're not dropping it[3], several side discussions involved enabling > systemd-boot as an option in Fedora in the future. > > While I *personally* am not a huge fan of systemd-boot itself You mentioned that a few times, and we (at least Lennnart and I) have asked for details. If there's something important missing from sd-boot, we would like to know. > I *am* a fan of a lot of the mechanisms around it, and I think it > would be valuable for us to adopt more of that in Fedora. To that > end, that means making it easier for people to fully adopt > systemd-boot on their systems in Fedora with minimal effort (ideally > just a kickstart or Anaconda flag if desired). Yeah. While I don't think we're ready to propose it as the default, we definitely would like it to be trivial to switch to it if somebody wants to. > From my point of view as someone working on several Fedora variants > and would like to provide more optionality around this, there are a > couple of issues: > > * bootctl(1) appears to be tightly coupled to sd-boot This is a misunderstanding of the our development goals of systemd (the project) and sd-boot. As far as possible, generic interfaces are used. Starting from the bottom: the boot loader specification is designed to be completely generic and independent of the boot loader and independent of the userspace tools used to configure the boot loader. Similarly, most bootctl commands are implemented using generic functionality (either EFI or any bootloader implementing the boot loader specification). And stuff like 'bootctl status' and 'systemd-analyze blame' use interfaces that are completely generic and any bootload can provide the appropriate information to the operating system (see https://systemd.io/BOOT_LOADER_INTERFACE/). So bootctl is NOT coupled to sd-boot, except for some specific parts explicitly documented to be about sd-boot, currently the install/update/uninstall verbs and random-seed support. > * sd-boot is part of the systemd source tree > > The first problem is mostly because I think bootctl(1) is a fantastic > interface to manage *any* Bootloader Spec[4] (BLS) conformant boot > manager, and I would love for that tool to be useful for doing so. > Being able to do things like install/upgrade/swap GRUB 2, > systemd-boot, or any other registered BLS-enabled boot manager would > make it tremendously useful and valuable as a "building block" tool. I > feel it would make sense to offer some kind of configuration to teach > bootctl(1) about these boot managers so that it can work for them, and > not just systemd-boot. bootctl could be taught to install other EFI stuff. It'd probably be a matter of specifying a different glob when looking for files to copy. I'm not sure if we want to get into the business of installing non-EFI stuff… What exactly do you have in mind? > The second problem is because having sd-boot in the systemd source > tree means that in order for Fedora to sign the boot manager EFI > binaries, we have to lock down the systemd source package to the > secure boot Koji build channel. This is unequivocally unacceptable > from my point of view, as the restrictions around the secure boot > channel make it realistically impossible for community contribution > and maintenance of the package. Do you have more information about "secure boot Koji build channel"? I was asking around, and I learnt that I need to read up on "pesign", but not much beyond that. What restrictions does it place on the build? > Realistically, I think if we want to make movement on making > systemd-boot fully supported in Fedora, the systemd-boot boot manager > code itself should be split out into its own repository with its own > release cadence, while bootctl(1) and related infrastructure remains > in the systemd source tree and evolves to be able to manage arbitrary > BLS-conformant boot managers. This is not so simple. systemd-boot shared source code with the bootctl and other parts of the tree (see src/fundamental/), and in general we want to move towards not having seperate implementations, but to share as much code as possible. Having this all in one tree makes things much easier. Splitting out to a separate repo would make development much harder and is somethign that we'd very much want to avoid. > This would also (hopefully) encourage other boot managers to support > the Bootloader Spec configuration model, making it succeed as a > semi-universal abstraction for boot manager configuration. We could > then teach our tooling in Fedora to interact with bootctl(1) to do > bootloader things, rather than having to create multiple tools and >
Re: [systemd-devel] all numeric usernames not allowed in systemd (version 245 onward)
On Thu, Apr 07, 2022 at 04:37:48PM +0530, Nikhil Kshirsagar wrote: > Is there any chance systemd could support a configuration option in the > future to get the earlier "all numeric" user logins to work? With an > understanding that it would be at the users own risk? No. > Are there any pam_systemd configuration options under consideration that > might help anyone looking for such functionality? Or is the only option > "not to upgrade" for someone interested in preserving their all numeric > usernames? Not upgrading is one option, renaming the users before or after the upgrade are the other options. Zbyszek
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 10:28:39AM +, Luca Boccassi wrote: > On Thu, 2022-03-24 at 09:38 +0100, Lennart Poettering wrote: > > On Mi, 23.03.22 11:28, Luca Boccassi (bl...@debian.org) wrote: > > > > > At least according to our documentation it wouldn't save us much > > > anyway, as the biggest leap is taking cgroupv2 for granted, which > > > requires 4.1, so it's included regardless. Unless there's something > > > undocumented that would make a big difference, in practical terms of > > > maintainability? > > > > Note that "cgroupv2 exists" and "cgroupv2 works well" are two distinct > > things. Initially too few controllers supported cgroupv2 for cgroupv2 > > to be actually useful. > > > > What I am trying to say is that it would actually help us a lot if > > we'd not just be able to take croupv2 for granted but to take a > > reasonably complete cgroupv2 for granted. > > Yes, that does sound like worth exploring - our README doesn't document > it though, do we have a list of required controllers and when they were > introduced? In the README: Linux kernel >= 4.2 for unified cgroup hierarchy support Linux kernel >= 4.10 for cgroup-bpf egress and ingress hooks Linux kernel >= 4.15 for cgroup-bpf device hook Linux kernel >= 4.17 for cgroup-bpf socket address hooks In this light, 4.19 is better than 4.4 or 4.9 ;) Zbyszek
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 08:08:31AM +0100, Greg KH wrote: > On Wed, Mar 23, 2022 at 10:11:36PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > > CIP 4.4 is supposed to be maintained until 2027, which is awfully > > long. The question is: is anyone putting new systemd on those > > systems? If no, then they're not relevant. > > Why not email them and ask? https://gitlab.com/cip-project/cip-core/cip-pkglist/-/issues/6 Zbyszek
Re: [systemd-devel] Antw: [EXT] Re: version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 08:21:37AM +0100, Ulrich Windl wrote: > I wonder: > > Why not providing some test suite instead: If the test suite succeeds, systemd > might work; if it doesn't, manual steps are needed. > My guess is that most people will quit trying once manual steps are needed. > In addition the configure procedure could include a "support window" (oldest > kernel supported, latest kernel supported). > And f the kernel is outside, print a warning at least that the configuration > is not supported. > Still I guess the kernel version is not the only dependency... We *are* providing a support window: the lower boundary is being discussed here, and the upper boundary is "open", always the latest kernel. Support for old kernels consists of various workarounds for missing syscalls or other functionality, and local copies of kernel headers. Instead of trying to write tests for this, we just add the workarounds and then try not to touch them until they are removed. (And this is similar for other dependencies. There's a list with versions in README.) Zbyszek
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 03:58:22PM +, Luca Boccassi wrote: > On Wed, 2022-03-23 at 12:38 +0100, Greg KH wrote: > > On Wed, Mar 23, 2022 at 11:28:29AM +, Luca Boccassi wrote: > > > On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > > On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote: > > > > > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek > > > > > wrote: > > > > > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > > > > > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew > > > > > > > Jędrzejewski-Szmek wrote: > > > > > > > > Hi all, > > > > > > > > > > > > > > > > we are considering dropping upstream support for kernel > > > > > > > > versions < 4.4. > > > > > > > > Would this be a problem for anyone? (*). > > > > > > > > > > > > > > Given that upstream (i.e. kernel.org) has dropped support for > > > > > > > kernel > > > > > > > 4.4, why not just move to not supporting kernels older than 4.9? > > > > > > > > > > > > It seems Civil Infrastructure Platform (a project under the Linux > > > > > > Foundation) still uses 4.4 [1]. > > > > > > > > > > Yes, but they are not going to be updating to a newer version of > > > > > systemd, right? > > > > > > > > > > And they are going to be "supporting" that for 20+ years. If they > > > > > want > > > > > to do something crazy like this, make them handle supporting code that > > > > > is older than 6+ years to start with. That's not the community's > > > > > issue, > > > > > that's the companies that demand such crazy requirement's issue. > > > > > > > > That's why I (we) asked the question on the list. If people are compling > > > > systemd on such old systems, or even older, we want to know about it. > > > > > > > > > > In the Debian world, Stretch which has EOL scheduled for June 2022 > > > > > > has 4.9, > > > > > > and after that Buster has 4.19. > > > > > > > > > > 4.9 is fine, and is supported by kernel.org until next year as seen > > > > > here: > > > > > https://kernel.org/category/releases.html > > > > > > > > > > I wrote "4.9" above, not "4.19" :) > > > > > > > > Yep. I'd vote for bumping to 4.9, unless some other voices pop up. > > > > > > > > Zbyszek > > > > > > Let's do 4.4 at most please - what's on kernel.org is not really that > > > important, as real usage is downstream from there anyway. > > > > And I will publically state that anyone still using 4.4.y today has an > > insecure and unsupported system. Please let's not encourage _ANYONE_ to > > do this. > > > > CIP is "special" in that they know what they are doing, and are using > > 4.4.y in a very limited set of use cases and configurations. And even > > they are going to have big problems keeping that kernel alive and > > secure. I would never expect anyone else to be able to do it, and I > > have doubts that they will either. > > > > So any "real usage" of 4.4 after today, should not matter. And if > > someone complains, send them to me please. > > > > thanks, > > > > greg k-h > > You can publically state that all day long, but you know perfectly well > that's not how the world works. In the grand scheme of things few > production scenarios build their kernel from kernel.org, most will be > getting it from a distro (best case) or a vendor (worst case), and they > couldn't care less about what kernel.org tells them to do, they use > what they get. I fully expect at some point to hear complaints from > some poor soul stuck on 3.x because of $crappy_arm_vendor with no way > to move on from there. > > Jumping forward from 3.13 to 4.4 as the baseline, allowing to take > cgroupsv2 for granted, seems like a good starting point to me. There's > very obvious and public evidence of that being used in the wild. We can > start to drop a bunch of backward-compat cruft, wait and see who > complains, and if nobody does we can re-evaluate again in a couple of > years. Yeah, but I don't think we want to go through this exercise again in a few months. If we jump, we might as well jump a bit further. CIP 4.4 is supposed to be maintained until 2027, which is awfully long. The question is: is anyone putting new systemd on those systems? If no, then they're not relevant. Or in other words: I'd prefer for such people to speak up for themselves, rather than us trying to figure out what somebody else *might* be planning to do. Zbyszek
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote: > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > Hi all, > > > > > > > > we are considering dropping upstream support for kernel versions < 4.4. > > > > Would this be a problem for anyone? (*). > > > > > > Given that upstream (i.e. kernel.org) has dropped support for kernel > > > 4.4, why not just move to not supporting kernels older than 4.9? > > > > It seems Civil Infrastructure Platform (a project under the Linux > > Foundation) still uses 4.4 [1]. > > Yes, but they are not going to be updating to a newer version of > systemd, right? > > And they are going to be "supporting" that for 20+ years. If they want > to do something crazy like this, make them handle supporting code that > is older than 6+ years to start with. That's not the community's issue, > that's the companies that demand such crazy requirement's issue. That's why I (we) asked the question on the list. If people are compling systemd on such old systems, or even older, we want to know about it. > > In the Debian world, Stretch which has EOL scheduled for June 2022 has 4.9, > > and after that Buster has 4.19. > > 4.9 is fine, and is supported by kernel.org until next year as seen > here: > https://kernel.org/category/releases.html > > I wrote "4.9" above, not "4.19" :) Yep. I'd vote for bumping to 4.9, unless some other voices pop up. Zbyszek
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > Hi all, > > > > we are considering dropping upstream support for kernel versions < 4.4. > > Would this be a problem for anyone? (*). > > Given that upstream (i.e. kernel.org) has dropped support for kernel > 4.4, why not just move to not supporting kernels older than 4.9? It seems Civil Infrastructure Platform (a project under the Linux Foundation) still uses 4.4 [1]. In the Debian world, Stretch which has EOL scheduled for June 2022 has 4.9, and after that Buster has 4.19. Of course we'd like to move to 4.19, but we don't want to disrupt distros that use older kernels. Is ≤4.19 really unused? [1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/start Zbyszek
[systemd-devel] version bump of minimal kernel version supported by systemd?
Hi all, we are considering dropping upstream support for kernel versions < 4.4. Would this be a problem for anyone? (*). Zbyszek (*) If you answer "yes", please substantiate why you are running new systemd with such old kernels.
Re: [systemd-devel] Antw: [EXT] [systemd‑devel] Why is using fstab the preferred approach according to systemd.mount man page?
On Mon, Jan 10, 2022 at 12:15:22PM +0100, Ulrich Windl wrote: > >>> "Manuel Wagesreither" schrieb am 10.01.2022 um 11:43 > >>> in > Nachricht <759bd805-ab37-4dc9-93cd-137668acf...@www.fastmail.com>: > > Hi all, > > > > currently, the systemd.mount man page [1] claims that "In general, > > configuring mount points through /etc/fstab is the preferred approach". Why > > is that? One would assume systemd proposing use of systemd.mount units over > > /etc/fstab. > > Because it's much easier to configure? Pretty much. There isn't any big benefit to using mount units (since the fstab syntax supports all the important use cases), and people are familiar with fstab. More tools support it too. Zbyszek
Re: [systemd-devel] Predictable Network Interface Name Bug?
As Lennart wrote, some of the changes since v245 are likely to fix your issue. I'd put my money on https://github.com/systemd/systemd/commit/2c8ec0095e i.e. systemd 247, but it's probably best to try systemd 249. Zbyszek
Re: [systemd-devel] Predictable Network Interface Name Bug?
On Thu, Dec 16, 2021 at 07:27:44AM -0500, Tim Safe wrote: > Thanks for the reply! Here's the output: > > $ udevadm test-builtin net_id /sys/class/net/ens8f0 > ID_NET_NAME_SLOT=ens8f0 > > $ udevadm test-builtin net_id /sys/class/net/ens8f1 > ID_NET_NAME_SLOT=ens8f1 > > $ udevadm test-builtin net_id /sys/class/net/eth2 > ID_NET_NAME_SLOT=ens8f0 > > $ udevadm test-builtin net_id /sys/class/net/eth3 > ID_NET_NAME_SLOT=ens8f1 Thanks. What does 'udevadm info /sys/class/net/*' say? Zbyszek
Re: [systemd-devel] Predictable Network Interface Name Bug?
On Wed, Dec 15, 2021 at 09:37:41PM -0500, Tim Safe wrote:
> Hello-
>
> I have an Ubuntu Server 20.04 (systemd 245 (245.4-4ubuntu3.13)) box that I
> recently installed a Intel quad-port Gigabit ethernet adapter (E1G44ETBLK).
>
> It appears that the predictable interface naming is only renaming the first
> two interfaces (ens8f0, ens8f1) and the second two fail to be renamed
> (eth2, eth3).
>
> From the logs, I see the following messages:
>
> systemd-udevd[456]: eth2: Failed to rename network interface 5 from 'eth2'
> to 'ens8f0': File exists
> systemd-udevd[456]: eth2: Failed to process device, ignoring: File exists
> systemd-udevd[459]: ethtool: autonegotiation is unset or enabled, the speed
> and duplex are not writable.
> systemd-udevd[459]: eth3: Failed to rename network interface 6 from 'eth3'
> to 'ens8f1': File exists
> systemd-udevd[459]: eth3: Failed to process device, ignoring: File exists
>
> Taking a closer look at the PCI bus, I see:
>
> 05:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network
> Connection (rev 01)
> 05:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network
> Connection (rev 01)
> 06:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network
> Connection (rev 01)
> 06:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network
> Connection (rev 01)
>
> It looks like the adapter has two instances ending in '0' and two instances
> ending in '1'; they differ by the higher number ('05' vs '06') in the lspci
> output.
>
> Is this a bug? I'd expect to see the 3rd and 4th interfaces to be named
> ens8f2, ens8f3.
Can you provide the output from 'udevadm test-builtin net_id
/sys/class/net/'
for each of the four interfaces?
Zbyszek
Re: [systemd-devel] Preferred library for hash functions
On Sun, Aug 08, 2021 at 03:17:40PM -0500, Daniel Parks wrote: > I'd like to add a feature to systemd-cryptsetup that requires computing > a sha256 hash. Currently, systemd links to several different crypto > libraries, and I'm a bit confused what the preferred implementation > would be. > > Currently I'm thinking about adding a dependency on libopenssl to > systemd-cryptsetup and falling back to khash if openssl is not > available at compile time, similar to the design in > src/libsystemd/sd-id128/sd-id128.c#L285. > > I do think it's slightly concerning that I would be adding another > shared library dependency to systemd-cryptsetup, but given that it > already indirectly depends on libopenssl through libsystemd-shared, I > think it should be fine. > > What do other people think about this idea? We plan to switch everything to openssl (now that openssl 3 is coming out) and require it a hard dependency for libsystemd-shared. So please just use openssl. Zbyszek
Re: [systemd-devel] Antw: [EXT] Re: minimum space needed for reload/reexec
On Wed, Jun 30, 2021 at 02:14:36PM +0200, Ulrich Windl wrote: > >>> "CHEN, Jack" schrieb am 30.06.2021 um 13:39 in > Nachricht > > > > Hi, > > > > I happen to see to a fix in system, which adds a space checking before > > reload/reexec. > > From the code: > > Require 16MiB free in /run/systemd for reloading/reexecing. After all we > > need to serialize our state there, and if > > * we can't we'll fail badly > > #define RELOAD_DISK_SPACE_MIN (UINT64_C(16) * UINT64_C(1024) * > > UINT64_C(1024)) > > And I got further explanation from poettering: > > it's a "safety buffer", see commit msg of the fix. It's set to 16M because > > it has to be set to something, and it sounded like a reasonably value, and > so > > far we got no feedback to the contrary > > > > However, just for “serialize our state there”, literally, there is no need > > for such a big space (16M). > > There is no problem for PC. But for embedded devices, 16M is quite > prodigal. > > And in my test, even 1M free space would allow reloading/reexecing to work > > normally. > > > > Shall we remove this restriction? (Removing I mean we just check if there is > > > free space or not) Or at least lower the threshold. > > It is not good to forbid reloading/reexecing when there is enough free > > space, just because it is smaller than the threshold (16M)。 > > The obvious solution seems to be: > 1) Monitor the actual memory usage across different platforms > 2) Add 25% to set the final value > Or if really paranoid: use four times the maximum measured value ;-) Four times the measured value seems reasonable. Or maybe derive some measure that applies to an "average unit" and multiply it by the number of loaded units times four. I guess adding a log message what the size of the serialized buffer is as part of reload would be a very good first step. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd]: sd-sync lead to kernel panic
On Wed, Jun 30, 2021 at 02:54:24PM +0800, www wrote: > Dear all, > > > systemd version: v234 > kernel version: 5.1.5 > > > My embedded system uses systemd. Occasionally kernel panic appears in this > system. It is found that it is related to sd-sync in systemd. How to analyze > this and why? > What causes this problem? Or can you see that sd-sync has a problem > processing that file or service? > If you have any ideas or opinions, or need any specific information, please > let me know. sd-sync is just systemd calling sync(2) in a thread. So it's just your kernel crashing. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Entry-level bugs/features
On Tue, Jun 22, 2021 at 08:15:53PM -0400, Albert Brox wrote: > Hi folks, > > I'm an experienced developer though have never worked on a large C > project before. > Can anyone point me at a relatively approachable bug or feature > request that I can sink my teeth into? > Trying to gain some familiarity with the world of systems programming. Hi Albert, we don't have such a list handy. You could try https://github.com/systemd/systemd/issues?q=is%3Aopen+is%3Aissue+label%3Aneeds-better-log-message or https://github.com/systemd/systemd/issues?q=is%3Aopen+is%3Aissue+label%3Adocumentation Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] minimum required meson version bump?
Hi, we're considering bumping the meson version from the current 0.46 to something more recent (0.52 or 0.53…). Ubuntu Biionic 18.04 has 0.45, so it is below the cutoff point already. Focal 20.04 has 0.53.2. Would this be a problem for anyone? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Trying to collaborate.
On Fri, May 07, 2021 at 02:07:32PM +0200, Manuel Hernández Méndez wrote: > Hello everyone, > > I am a software developer willing to collaborate in the systemd project. I > have taken a loook of the issue list in your GitHub repository, but it is a > bit difficult for me to found an "entry level" issue or task I could start > doing or fixing. > I have cloned the repository and I have spent some days wathcing the code. > I have also compiled and used the mkosi environment following your hacking > guide. > I would appreciate a lot some starting point to introduce in your project. > I am open to collaborate with anyone who needs some help also, I have some > knowledge about c, gdb debugging and linux environment. Hi Manuel, you might want to start with simpler issues. https://github.com/systemd/systemd/issues?q=is%3Aopen+is%3Aissue+label%3Aneeds-better-log-message and https://github.com/systemd/systemd/issues?q=is%3Aopen+is%3Aissue+label%3Adocumentation might be two good starting points. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Storing package metadata in ELF objects
[I'm forwarding the mail from Luca who is not subscribed to fedora-devel] On Sat, Apr 10, 2021 at 01:38:31PM +0100, Luca Boccassi wrote: Hello, Cross-posting to the mailing lists of a few relevant projects. After an initial discussion [0], recently we have been working on a new specification [0] to encode rich package-level metadata inside ELF objects, so that it can be included automatically in generated coredump files. The prototype to parse this in systemd-coredump and store the information in systemd-journal is ready for testing and merged upstream. We are now seeking further comments/opinions/suggestions, as we have a few months before the next release and thus there's plenty of time to make incompatible changes to the format and implementation, if required. A proposal to use this by default for all packages built in Fedora 35 has been submitted [1]. The Fedora Wiki and the systemd.io document have more details, but to make a long story short, a new .notes.package section with a JSON payload will be included in ELF objects, encoding various package- build-time information like distro name, package name, etc. To summarize from the discussion, the main reasons why we believe this is useful are as following: 1) minimal containers: the rpm database is not installed in the containers. The information about build-ids needs to be stored externally, so package name information is not available immediately, but only after offline processing. The new note doesn't depend on the rpm db in any way. 2) handling of a core from a container, where the container and host have different distros 3) self-built and external packages: unless a lot of care is taken to keep access to the debuginfo packages, this information may be lost. The new note is available even if the repository metadata gets lost. Users can easily provide equivalent information in a format that makes sense in their own environment. It should work even when rpms and debs and other formats are mixed, e.g. during container image creation. Other than in Fedora, we are already making the required code changes at Microsoft to use the same format for internally-built binaries, and for tools that parse core files and logs. Tools for RPM and DEB (debhelper) integration are also available [3]. > -- > Kind regards, > Luca Boccassi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How should Wayland compositors handle logind restarts?
On Mon, Feb 08, 2021 at 11:43:35AM +0200, Vlad Zahorodnii wrote: > Hi, > My question is - should Wayland compositors handle logind restarts > in any way? > > At the moment, many Wayland compositors don't take any precautions > against the case where logind is restarted. They assume that the DRM > file descriptors will remain valid and the session will be restored > auto-magically. Yes, that is what they should be doing. > Currently, a lot of Wayland compositors can't recover from logind > restarts. For example, that's the case with weston, sway, kwin, and > perhaps other compositors. > > The culprit seems to be that atomic commits fail with the > "Permission denied" error. That's because of a bug in logind. I started working on a fix last year [1], but doing this properly requires restructuring how the code handles cleanup. It's on the TODO list. [1] https://github.com/systemd/systemd/pull/17558 Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is LTO worth it?
On Mon, Jan 11, 2021 at 06:05:26PM +0100, Michael Biebl wrote: > Am Mo., 11. Jan. 2021 um 16:39 Uhr schrieb Lennart Poettering > : > > https://fedoraproject.org/wiki/LTOByDefault > > Interestingly, that wiki page says, that LTO should produce smaller > binaries, which clearly isn't the case here. I think LTO should be understood as "work in progress". Making it the default in Fedora surfaced a few different issues in the compiler, and some packages needed to temporarily opt out. Compiler maintainers worked on those, and I think they have been all or almost all resolved. But since they were working on just making the thing work, they most likely didn't have too much time to work on improvements. The initial reports spoke about a few percent savings on average, with significantly larger savings for some packages, esp. C++ programs. Hopefully, we will see bigger savings in the future. > I wonder whether the wiki is incorrect or whether this is a toolchain > issue or if this is specific to systemd > Or maybe this is Debian specific. Would be interested to see numbers > from other distros. This is a rebuild of systemd package with standard settings (lto, -O2) and without lto (-O2): $ ls -l *rpm no-lto/*rpm 9932144 Jan 13 13:03 systemd-247.2-2.fc34.src.rpm (with lto) 9932165 Jan 13 13:28 systemd-247.2-2.fc34.src.rpm (the second number is always without lto) 4411100 Jan 13 13:07 systemd-247.2-2.fc34.x86_64.rpm 4412181 Jan 13 13:31 systemd-247.2-2.fc34.x86_64.rpm 512945 Jan 13 13:07 systemd-container-247.2-2.fc34.x86_64.rpm <-- 548286 Jan 13 13:31 systemd-container-247.2-2.fc34.x86_64.rpm <-- 1105667 Jan 13 13:07 systemd-container-debuginfo-247.2-2.fc34.x86_64.rpm 1584398 Jan 13 13:31 systemd-container-debuginfo-247.2-2.fc34.x86_64.rpm 9608297 Jan 13 13:08 systemd-debuginfo-247.2-2.fc34.x86_64.rpm 9779602 Jan 13 13:31 systemd-debuginfo-247.2-2.fc34.x86_64.rpm 3012544 Jan 13 13:08 systemd-debugsource-247.2-2.fc34.x86_64.rpm 3010956 Jan 13 13:31 systemd-debugsource-247.2-2.fc34.x86_64.rpm 441654 Jan 13 13:07 systemd-devel-247.2-2.fc34.x86_64.rpm 441622 Jan 13 13:31 systemd-devel-247.2-2.fc34.x86_64.rpm 104294 Jan 13 13:07 systemd-journal-remote-247.2-2.fc34.x86_64.rpm 105182 Jan 13 13:31 systemd-journal-remote-247.2-2.fc34.x86_64.rpm 157884 Jan 13 13:07 systemd-journal-remote-debuginfo-247.2-2.fc34.x86_64.rpm 157852 Jan 13 13:31 systemd-journal-remote-debuginfo-247.2-2.fc34.x86_64.rpm 558758 Jan 13 13:07 systemd-libs-247.2-2.fc34.x86_64.rpm <-- 610528 Jan 13 13:31 systemd-libs-247.2-2.fc34.x86_64.rpm <-- 1572056 Jan 13 13:07 systemd-libs-debuginfo-247.2-2.fc34.x86_64.rpm <-- 2939352 Jan 13 13:31 systemd-libs-debuginfo-247.2-2.fc34.x86_64.rpm <-- 486239 Jan 13 13:07 systemd-networkd-247.2-2.fc34.x86_64.rpm 501935 Jan 13 13:31 systemd-networkd-247.2-2.fc34.x86_64.rpm 1144027 Jan 13 13:07 systemd-networkd-debuginfo-247.2-2.fc34.x86_64.rpm 1263367 Jan 13 13:31 systemd-networkd-debuginfo-247.2-2.fc34.x86_64.rpm 319473 Jan 13 13:07 systemd-pam-247.2-2.fc34.x86_64.rpm 362518 Jan 13 13:31 systemd-pam-247.2-2.fc34.x86_64.rpm 979482 Jan 13 13:07 systemd-pam-debuginfo-247.2-2.fc34.x86_64.rpm 1726838 Jan 13 13:31 systemd-pam-debuginfo-247.2-2.fc34.x86_64.rpm 26582 Jan 13 13:07 systemd-rpm-macros-247.2-2.fc34.noarch.rpm 26553 Jan 13 13:31 systemd-rpm-macros-247.2-2.fc34.noarch.rpm 110101 Jan 13 13:07 systemd-standalone-sysusers-247.2-2.fc34.x86_64.rpm <-- 139709 Jan 13 13:31 systemd-standalone-sysusers-247.2-2.fc34.x86_64.rpm <-- 284825 Jan 13 13:07 systemd-standalone-sysusers-debuginfo-247.2-2.fc34.x86_64.rpm <-- 759506 Jan 13 13:31 systemd-standalone-sysusers-debuginfo-247.2-2.fc34.x86_64.rpm <-- 153608 Jan 13 13:07 systemd-standalone-tmpfiles-247.2-2.fc34.x86_64.rpm <-- 184424 Jan 13 13:31 systemd-standalone-tmpfiles-247.2-2.fc34.x86_64.rpm <-- 389470 Jan 13 13:07 systemd-standalone-tmpfiles-debuginfo-247.2-2.fc34.x86_64.rpm 727117 Jan 13 13:31 systemd-standalone-tmpfiles-debuginfo-247.2-2.fc34.x86_64.rpm 4601160 Jan 13 13:08 systemd-tests-247.2-2.fc34.x86_64.rpm 4635619 Jan 13 13:31 systemd-tests-247.2-2.fc34.x86_64.rpm 15261886 Jan 13 13:08 systemd-tests-debuginfo-247.2-2.fc34.x86_64.rpm <-- 21949592 Jan 13 13:32 systemd-tests-debuginfo-247.2-2.fc34.x86_64.rpm <-- 1568229 Jan 13 13:07 systemd-udev-247.2-2.fc34.x86_64.rpm 1571073 Jan 13 13:31 systemd-udev-247.2-2.fc34.x86_64.rpm 934456 Jan 13 13:07 systemd-udev-debuginfo-247.2-2.fc34.x86_64.rpm 986681 Jan 13 13:31 systemd-udev-debuginfo-247.2-2.fc34.x86_64.rpm So we get some small savings in package size, with huge savings in -debuginfo packages. > Concerning the build speed: I wonder whether at least disabling LTO on > our CI would make sense. We don't really care for fast/small > executables there. We could disable it on some CIs. I agree that disabling it everywhere would be detrimental. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
Re: [systemd-devel] Creating executable device nodes in /dev?
On Wed, Dec 09, 2020 at 10:58:59PM +0100, Ben Hutchings wrote: > I'm convinced. I've committed a change to initramfs-tools that removes > the noexec mount option again. Systemd counterpart: https://github.com/systemd/systemd/pull/17940. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Creating executable device nodes in /dev?
On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote: > Hi udev people- > > The upcoming Linux SGX driver has a device node /dev/sgx. User code > opens it, does various setup things, mmaps it, and needs to be able to > create PROT_EXEC mappings. This gets quite awkward if /dev is mounted > noexec. > > Can udev arrange to make a device node executable on distros that make > /dev noexec? This could be done by bind-mounting from an exec tmpfs. > Alternatively, the kernel could probably learn to ignore noexec on > /dev/sgx, but that seems a little bit evil. I'd be inclined to simply drop noexec from /dev by default. We don't do noexec on either /tmp or /dev/shm (because that causes immediate problems with stuff like Java and cffi). And if you have those two at your disposal anyway, having noexec on /dev doesn't seem important. Afaik, the kernel would refuse execve() on a character or block device anyway. Thus noexec on /dev matters only for actual binaries copied to /dev, which requires root privileges in the first place. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd prerelease 247-rc2
On Thu, Nov 12, 2020 at 04:36:01PM +0100, Michael Biebl wrote: > Hi there > > Am Do., 12. Nov. 2020 um 11:58 Uhr schrieb systemd tag bot > : > > > > A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the > > tarball here: > > > > https://github.com/systemd/systemd/archive/v247-rc2.tar.gz > > Congrats to the new release! > > > Changes since the previous release: > > > > * KERNEL API INCOMPATIBILITY: Linux 4.12 introduced two new uevents > > "bind" and "unbind" to the Linux device model. When this kernel > > change was made, systemd-udevd was only minimally updated to > > handle > > and propagate these new event types. The introduction of these new > > uevents (which are typically generated for USB devices and devices > > needing a firmware upload before being functional) resulted in a > > number of issues which we so far didn't address. We hoped the > > kernel > > maintainers would themselves address these issues in some form, > > but > > that did not happen. To handle them properly, many (if not most) > > udev > > rules files shipped in various packages need updating, and so do > > many > > programs that monitor or enumerate devices with libudev or > > sd-device, > > or otherwise process uevents. Please note that this > > incompatibility > > is not fault of systemd or udev, but caused by an incompatible > > kernel > > change that happened back in Linux 4.12, but is becoming more and > > more visible as the new uevents are generated by more kernel > > drivers. > > > > To minimize issues resulting from this kernel change (but not > > avoid > > them entirely) starting with systemd-udevd 247 the udev "tags" > > concept (which is a concept for marking and filtering devices > > during > > enumeration and monitoring) has been reworked: udev tags are now > > "sticky", meaning that once a tag is assigned to a device it will > > not > > be removed from the device again until the device itself is > > removed > > (i.e. unplugged). This makes sure that any application monitoring > > devices that match a specific tag is guaranteed to both see > > uevents > > where the device starts being relevant, and those where it stops > > being relevant (the latter now regularly happening due to the new > > "unbind" uevent type). The udev tags concept is hence now a > > concept > > tied to a *device* instead of a device *event* — unlike for > > example > > udev properties whose lifecycle (as before) is generally tied to a > > device event, meaning that the previously determined properties > > are > > forgotten whenever a new uevent is processed. > > > > With the newly redefined udev tags concept, sometimes it's > > necessary > > to determine which tags are the ones applied by the most recent > > uevent/database update, in order to discern them from those > > originating from earlier uevents/database updates of the same > > device. To accommodate for this a new automatic property > > CURRENT_TAGS > > has been added that works similar to the existing TAGS property > > but > > only lists tags set by the most recent uevent/database > > update. Similarly, the libudev/sd-device API has been updated with > > new functions to enumerate these 'current' tags, in addition to > > the > > existing APIs that now enumerate the 'sticky' ones. > > > > To properly handle "bind"/"unbind" on Linux 4.12 and newer it is > > essential that all udev rules files and applications are updated > > to > > handle the new events. Specifically: > > > > • All rule files that currently use a header guard similar to > > ACTION!="add|change",GOTO="xyz_end" should be updated to use > > ACTION=="remove",GOTO="xyz_end" instead, so that the > > properties/tags they add are also applied whenever "bind" (or > > "unbind") is seen. (This is most important for all physical > > device > > types — those for which "bind" and "unbind" are currently > > generated, for all other device types this change is still > > recommended but not as important — but certainly prepares for > > future kernel uevent type additions). > > > > • Similarly, all code monitoring devices that contains an 'if' > > branch > > discerning the "add" + "change" uevent actions from all other > > uevents actions (i.e. considering devices only relevant after > > "add" > > or "change", and irrelevant on all other events) should be > > reworked > > to instead negatively check
Re: [systemd-devel] Sponsoring systemd
On Thu, Oct 15, 2020 at 10:57:18AM +0200, Jan Keller wrote: > Hey systemd project, > > I am trying to get in touch with someone regarding a potential sponsorship > (details at > https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html). > Who is best to talk to? In the past financial stuff was handled by by Lennart and me. You can just reply to this email (maybe with the mailing list removed). Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Sat, Jun 27, 2020 at 11:42:00AM +0100, Mark Rogers wrote: > On Sat, 27 Jun 2020 at 11:06, Zbigniew Jędrzejewski-Szmek > wrote: > > You should use Before=network-pre.target, Wants=network-pre.target. > > Thanks, tried that but still not working: > > $ journalctl -b | grep -Ei '(db2config|dhcpcd)' > Feb 14 10:12:03 localhost systemd[1]: Starting dhcpcd on all interfaces... > Feb 14 10:12:03 localhost dhcpcd[341]: read_config: fopen > `/etc/dhcpcd.conf': No such file or directory > [...] > Jun 27 10:19:39 localhost dhcpcd[341]: wlan0: /etc/wpa_supplicant.conf > does not exist > [...] > Jun 27 10:19:39 localhost dhcpcd[341]: read_config: fopen > `/etc/dhcpcd.conf': No such file or directory > [...] > Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting an IPv6 router > Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting a DHCP lease > Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config > Creating /tmp/sys//etc/dhcpcd.conf > Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config > Creating /tmp/sys//etc/wpa_supplicant/wpa_supplicant.conf > > (Comments about that extract: the jump from Feb to Jun I assume is the > clock getting updated from RTC, it's all from the same boot obviously; > also note my db2config script doesn't run until after hostname is set > which I would assume is set by the network startup?) > > Unit file is currently: > > [Unit] > Description=Config generation from DB > Before=network-pre.target > Wants=network-pre.target > > [Service] > Type=oneshot > ExecStart=/home/mark/bin/db2config.py > > [Install] > RequiredBy=network.target And how does the unit that is running dhcpcd look like? Zbyszek > After any changes I'm using > $ sudo systemctl daemon-reload > $ sudo systemctl reenable db2config.service > > ... although that's another area I'm not entirely clear about what > exactly is required after a unit file change. > > PS: Is list etiquette around here to CC on reply? Some love it, some > hate it, others don't care... reply-all is fine. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Sat, Jun 27, 2020 at 09:34:00AM +0100, Mark Rogers wrote: > I have tried multiple approaches so far but by current service file > looks like this: > > [Unit] > Description=Config generation from DB > Before=networking.service You should use Before=network-pre.target, Wants=network-pre.target. > [Service] > Type=oneshot > ExecStart=/home/mark/bin/db2config.py > > [Install] > RequiredBy=network.target > > [1] > https://stackoverflow.com/questions/62574482/ensuring-that-a-systemd-unit-starts-before-any-networking > - no responses there to date, feel free to respond there for > reputation or else I'll update it when I solve it. Yes, please update so. Also feel free to submit a PR for our man pages if you find the time. netowrk-pre.target is briefly explained in systemd.special(7), but maybe the network target deserve a separate section in bootup(7)? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-level]: how to config and enable systemd help to create coredump file when the process crashes ？
On Wed, May 20, 2020 at 04:22:35PM +0800, www wrote: > Dear all, > > > how to config and enable systemd help to create coredump file when the > process crashes ？ See http://www.freedesktop.org/software/systemd/man/coredumpctl.html. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-hostnamed/hostnamectl and transient hostname change
On Mon, Apr 27, 2020 at 12:00:36PM +0200, Thomas HUMMEL wrote: > On 4/27/20 11:51 AM, Mantas Mikulėnas wrote: > > Hello, thanks for your answer. > > >On Mon, Apr 20, 2020 at 6:17 PM Thomas HUMMEL > >mailto:thomas.hum...@pasteur.fr>> > >wrote: > > > >1. why does the transient hostname change while I stated --static only > >while running hostnamectl ? > > > >2. why does the change take some time to appear on dbus ? > > > > > > >Hostnamed does not implement receiving hostname change > >notifications from the kernel, so it always reports you the same > >hostname that it has seen on startup. > > That was my understanding as well. Lennart opened a PR to remove the caching: https://github.com/systemd/systemd/pull/15624. > >You're only seeing changes because hostnamed /exits when idle/ -- > >the next time you're actually talking to a brand new instance of > >hostnamed, which has seen the new hostname. > > But this does not explain why the transient hostname is changed as I > only changed the static one, does it ? Unless this new instance sets > it from the static one when it starts ? I mean something has to call > sethostname(2) to set the transient to the new static one, right ? The documentation is wrong. The code in hostnamed sets the kernel hostname when setting the static one. This was changed in https://github.com/systemd/systemd/commit/c779a44222: commit c779a44222161155c039a7fd2fd304c006590ac7 Author: Stef Walter Date: Wed Feb 12 09:46:31 2014 +0100 hostnamed: Fix the way that static and transient host names interact It is almost always incorrect to allow DHCP or other sources of transient host names to override an explicitly configured static host name. This commit changes things so that if a static host name is set, this will override the transient host name (eg: provided via DHCP). Transient host names can still be used to provide host names for machines that have not been explicitly configured with a static host name. The exception to this rule is if the static host name is set to "localhost". In those cases we act as if no static host name has been explicitly set. We need to reconcile the code and the docs. I'd go for updating the docs to match the code, because this is a long-standing behaviour and people haven't been complaining about it. (I'm assuming you're not unhappy, just confused by the unexpected results...). Opinions? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd vulnerability detection
On Wed, Apr 29, 2020 at 08:53:23AM +0530, Amish wrote: > > On 29/04/20 1:00 am, Lennart Poettering wrote: > >Please see: > > > >https://systemd.io/SECURITY/ > > > >... > > > >Lennart > > On a side note, phrasing on the site needs to be changed. https://github.com/systemd/systemd/pull/15632 ? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user service conflict and confusion
On Fri, Apr 10, 2020 at 10:53:36AM -0500, Matt Zagrabelny wrote: > Greetings, > > I am hitting a confusing scenario with my system. I am running 245.4-2 > (Debian). > > I have a user service, mpd, which is failing to start. It is enabled: > > $ systemctl --user is-enabled mpd > enabled > > And now that I look for the enabled unit within the filesystem, I don't see > it. > > I'm expecting to see something in ~/.config/systemd, but that directory > doesn't exist. > > $ stat ~/.config/systemd > stat: cannot stat '/home/z/.config/systemd': No such file or directory > > I have other systems with user services and ~/.config/systemd is where all > the details are. > > First question, where should I be looking (in the filesystem) for user > enabled services? Try 'systemctl --user cat mpd'. > After that I look to see why the user service isn't starting: > > $ systemctl --user status mpd > [...] > Apr 10 10:00:29 zipper mpd[16231]: exception: Failed to bind to ' > 192.168.0.254:6600' > Apr 10 10:00:29 zipper mpd[16231]: exception: nested: Failed to bind > socket: Address already in use > Apr 10 10:00:29 zipper systemd[1982]: mpd.service: Main process exited, > code=exited, status=1/FAILURE > > Okay. Something is using that port. > > $ sudo fuser 6600/tcp > 6600/tcp: 1795 > > $ ps -f -q 1795 > UID PIDPPID C STIME TTY TIME CMD > root1795 1 0 08:24 ?00:00:00 /lib/systemd/systemd > --user > > Is that "systemd --user" command running for the root user? or is that the > system level systemd? > > My system level mpd.* units are disabled and inactive: > > # systemctl is-active mpd.service > inactive > > # systemctl is-active mpd.socket > inactive Maybe it's running under user@0.service, i.e. the root's user manager? You can drill down from 'systemctl status 1795'. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] pstore: options to enable kernel writing into the pstore
On Thu, Mar 26, 2020 at 01:05:22PM -0500, Eric DeVolder wrote:
> >Below is a proposal for adding a couple of settings to the systemd pstore
> >service so that it can enable the kernel parameters that allow the
> >kernel to write into the pstore.
Hi,
please submit this as PR.
> > From 837d716c6e7ed02518a399356df95bf7c47e1772 Mon Sep 17 00:00:00 2001
> >From: Eric DeVolder
> >Date: Wed, 11 Mar 2020 14:11:03 -0500
> >Subject: [RFC] pstore: options to enable kernel writing into the pstore
> >
> >The systemd pstore service archives the contents of /sys/fs/pstore
> >upon boot so that there is room for a subsequent dump. The pstore is
> >usually backed by flash memory typically in the vicinity of 64KB. The
> >pstore can contain post-mortem debug information even if kdump fails
> >or is not enabld.
> >
> >The issue is that while the service is present, the kernel still needs
> >to be configured to write data into the pstore. It has two parameters,
> >crash_kexec_post_notifiers and printk.always_kmsg_dump, that control
> >writes into pstore.
> >
> >The crash_kexec_post_notifiers parameter enables the kernel to write
> >dmesg (including stack trace) into pstore upon a panic, and
> >printk.always_kmsg_dump parameter enables the kernel to write dmesg upon
> >a shutdown (shutdown, reboot, halt).
> >
> >As it stands today, these parameters are not managed/manipulated by the
> >systemd pstore service, and are solely reliant upon the user [to have
> >the foresight] to set them on the kernel command line at boot, or post
> >boot via sysfs. Furthermore, the user would need to set these parameters
> >in a persistent fashion so that that they are enabled on subsequent
> >reboots.
> >
> >This patch allows the user to set these parameters via the systemd
> >pstore service, and forget about it. This patch introduces two new
> >settings in the pstore.conf, 'kmsg' and 'crash'. If either of these
> >is set to true, then the corresponding parameter is enabled in the
> >kernel. If the setting is false, then the parameter is not touched,
> >thus preserving whatever behavior the user may have previously
> >chosen.
> >---
> > src/pstore/pstore.c | 36 +++-
> > 1 file changed, 35 insertions(+), 1 deletion(-)
> >
> >diff --git a/src/pstore/pstore.c b/src/pstore/pstore.c
> >index 5c812b5d5b..02bd94751f 100644
> >--- a/src/pstore/pstore.c
> >+++ b/src/pstore/pstore.c
> >@@ -68,6 +68,10 @@ static
> >DEFINE_CONFIG_PARSE_ENUM(config_parse_pstore_storage, pstore_storage, PSt
> > static PStoreStorage arg_storage = PSTORE_STORAGE_EXTERNAL;
> >
> > static bool arg_unlink = true;
> >+static bool arg_kmsg = false;
> >+static bool arg_crash = false;
> >+static const char *arg_kmsg_path =
> >"/sys/module/printk/parameters/always_kmsg_dump";
> >+static const char *arg_crash_path =
> >"/sys/module/kernel/parameters/crash_kexec_post_notifiers";
> > static const char *arg_sourcedir = "/sys/fs/pstore";
> > static const char *arg_archivedir = "/var/lib/systemd/pstore";
> >
> >@@ -75,6 +79,8 @@ static int parse_config(void) {
> > static const ConfigTableItem items[] = {
> > { "PStore", "Unlink", config_parse_bool, 0,
> > _unlink },
> > { "PStore", "Storage", config_parse_pstore_storage, 0,
> > _storage },
> >+ { "PStore", "kmsg", config_parse_bool, 0,
> >_kmsg },
> >+ { "PStore", "crash", config_parse_bool, 0,
> >_crash },
This also needs a man page update.
Config keys are generally capitalized. But they should be named in a
way that indicates what they're actually configuring.
> > {}
> > };
> >
> >@@ -363,7 +369,7 @@ static int list_files(PStoreList *list, const char
> >*sourcepath) {
> >
> > static int run(int argc, char *argv[]) {
> > _cleanup_(pstore_entries_reset) PStoreList list = {};
> >- int r;
> >+ int fd, r;
> >
> > log_setup_service();
> >
> >@@ -380,6 +386,34 @@ static int run(int argc, char *argv[]) {
> > log_debug("Selected storage: %s.",
> > pstore_storage_to_string(arg_storage));
> > log_debug("Selected unlink: %s.", yes_no(arg_unlink));
> >
> >+ if (arg_kmsg) {
> >+ /* Only enable if requested; otherwise do not touch the
> >parameter */
> >+ /* NOTE: These errors are not fatal */
> >+ fd = open(arg_kmsg_path, O_WRONLY|O_CLOEXEC);
> >+ if (fd < 0)
> >+ log_error_errno(r, "Failed to open %s: %m",
> >arg_kmsg_path);
> >+ r = write(fd, "Y", 1);
> >+ if (r != 1)
> >+ log_error_errno(r, "Failed to write: %m");
> >+ else
> >+ log_debug("Set printk.always_kmsg_dump.");
> >+ close(fd);
> >+ }
> >+
> >+ if (arg_crash) {
> >+ /* Only enable if requested; otherwise do not touch the
>
Re: [systemd-devel] systemd prerelease 245-rc2
On Tue, Mar 03, 2020 at 07:43:22AM +, systemd tag bot wrote: > A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the > tarball here: > > https://github.com/systemd/systemd/archive/v245-rc2.tar.gz It's mostly bufixes, but still 146 commits since -rc1. The plan is too release the final version at the end of the week. Regressions and bugs are still being reported, so expect more patches to go in. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-daemon documentation clarification
On Mon, Mar 02, 2020 at 01:38:54PM +0100, Łukasz Niemier wrote: > > AFAIK both stdout and stderr even get attached to the same journal pipe by > > default, so they should also be interpreted in the same way. > > > > The description of SyslogLevelPrefix= in systemd.exec(5) also says: "This > > only applies to log messages written to stdout or stderr.” > > THX, I must have missed that. This mean that the `sd-daemon` documentation > page should be updated to contain that information as well. Please file a PR! Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Minimize systemd for kdump's initramfs
On Tue, Feb 25, 2020 at 01:12:08PM +0800, Kairui Song wrote: > On Fri, Jan 3, 2020 at 3:23 PM Zbigniew Jędrzejewski-Szmek > wrote: > > On Fri, Jan 03, 2020 at 11:48:53AM +0800, Dave Young wrote: > > > On 01/03/20 at 11:45am, Dave Young wrote: > > > > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote: > > > > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote: > > > > > > Some component, like Systemd, have grown by a lot, here is a list of > > > > > > the size of part of binaries along with the binaries they required > > > > > > in > > > > > > F31: > > > > > > /root/image/bin/systemctl > > > > > > 20M . > > > > > > /root/image/usr/bin/systemctl > > > > > > 20M . > > > > > > /root/image/usr/bin/systemd-cgls > > > > > > 20M . > > > > > > /root/image/usr/bin/systemd-escape > > > > > > 20M . > > > > > > /root/image/usr/bin/systemd-run > > > > > > 20M . > > > > > > ... > > > > > > > > > > > > There are overlays between the libraries they used so when installed > > > > > > into the initramfs, the total size didn't go too big yet. But we can > > > > > > see the size of systemd binary and libraries it used is much bigger > > > > > > than others. > > > > > > > > > > All systemd binaries will mostly link to the same libraries (because > > > > > they link to a private shared library, which links to various other > > > > > shared libraries). So this "20M" will be repeated over and over, but > > > > > it's the same dependencies. > > > > > > > > > > While we'd all prefer for this to be smaller, 20M should is actually > > > > > not that much... > > > > > > > > > > > And as a compare, from version 219 to 243, systemd's library > > > > > > dependency increased a lot: > > > > > > (v219 is 5M in total, v243 is 20M in total) > > > > > > > > > > This is slightly misleading. Code was moved from individual binaries > > > > > to libsystemd-shared-nnn.so, so if you look at the deps of just a > > > > > single > > > > > binary, you'll see many more deps (because libsystemd-shared-nnn.so > > > > > has > > > > > more deps). But the total number of deps when summed over all binaries > > > > > grew much less. A more useful measure would be the size with deps > > > > > summed > > > > > over all systemd binaries that are installed into your image in v219 > > > > > and > > > > > v243. > > > > > > > > > > > > > I vaguely remember the size increased before due to linking with libidn2 > > > > previously, so those libraries contribute a lot. > > > > > > > > Does every systemd binary depend on all libraries? Or each of the > > > > systemd binary only depends on those libs when really needed? > > > > > > For example if I do not need journalctl, then I can drop journalctl and > > > those libraries specific for journalctl? > > > > It's using standard shared object linking, so yeah, for anything which > > libsystemd-shared-nnn.so links to, "every systemd binary depend[s] on > > all libraries", in the sense that the runtime linker will fail to start > > the executable if any of the libraries are missing. > > > > Hi, it has been a while since last discuss update, but a second > thought about the libsystemd-shared-nnn.so problem: > > Now each systemd executable depends on libsystemd-shared-nnn.so, which > then depend on a lot of things. In older version (eg. version 219), > each individual systemd executable have it's own dependency, that make > thing much cleaner for special usages like kdump. > > I'm not sure what is the purpose of this change, could there be any > work be done to minimize the lib dependency of each systemd binary? libsystemd-shared-nnn.so holds code used in multiple executables. This means that if the full suite is installed, shared code is present in just one copy, and the total footprint of the installation is minimized (disk, loading time, rss). OTOH, the footprint of installing just a single executable is unfortunately increased. Our thinking was that installing many executables is much more common (pretty even a minimal system with systemd has at least ~30 systemd binaries), so it makes sense to prioritize that. See https://github.com/systemd/systemd/pull/3516 for the discussion of the space savings back when this was originally done. Now we have many more binaries (and even more shared code since integration of various components is increasing...), so I expect the savings to be even bigger. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] lunch before devconf
Update: The location is now known: Purkyňova 99. We're crowdsourcing some topics to discuss so we're not bored ;) Please add to the list: https://docs.google.com/document/d/1y4NU60q0oCHGAo3qi0NkK5KVLdQRY-ZLSUroqrUT-XE/edit?usp=sharing Zbyszek On Thu, Jan 09, 2020 at 04:06:27PM +, Zbigniew Jędrzejewski-Szmek wrote: > Dear all, > > we'll be having an open meeting in Brno on Thursday, Jan 23rd, 2020, > before the DevConf.cz conference. Everyone interested in systemd > development is invited. The plan is to meet for lunch around 1 PM, and > then go the Red Hat office afterwards for discussion and planning. > We should be at the office from 2PM and it is of course also possible > to go directly there. > > When: 23.1.2020, Thursday, 13:00 – 16:00. > Location: Red Hat offices in Brno, > Purkyňova 99 or 111 depending on availability (14:00–16:00) > and somewhere close for lunch (13:00—14:00). > > If you wish to join, please let me know (off-list), so I can keep tabs. > Once we know the exact location, I'll reply to this email with additional > details. > > Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] lunch before devconf
Dear all, we'll be having an open meeting in Brno on Thursday, Jan 23rd, 2020, before the DevConf.cz conference. Everyone interested in systemd development is invited. The plan is to meet for lunch around 1 PM, and then go the Red Hat office afterwards for discussion and planning. We should be at the office from 2PM and it is of course also possible to go directly there. When: 23.1.2020, Thursday, 13:00 – 16:00. Location: Red Hat offices in Brno, Purkyňova 99 or 111 depending on availability (14:00–16:00) and somewhere close for lunch (13:00—14:00). If you wish to join, please let me know (off-list), so I can keep tabs. Once we know the exact location, I'll reply to this email with additional details. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Minimize systemd for kdump's initramfs
On Fri, Jan 03, 2020 at 11:48:53AM +0800, Dave Young wrote: > On 01/03/20 at 11:45am, Dave Young wrote: > > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote: > > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote: > > > > Some component, like Systemd, have grown by a lot, here is a list of > > > > the size of part of binaries along with the binaries they required in > > > > F31: > > > > /root/image/bin/systemctl > > > > 20M . > > > > /root/image/usr/bin/systemctl > > > > 20M . > > > > /root/image/usr/bin/systemd-cgls > > > > 20M . > > > > /root/image/usr/bin/systemd-escape > > > > 20M . > > > > /root/image/usr/bin/systemd-run > > > > 20M . > > > > ... > > > > > > > > There are overlays between the libraries they used so when installed > > > > into the initramfs, the total size didn't go too big yet. But we can > > > > see the size of systemd binary and libraries it used is much bigger > > > > than others. > > > > > > All systemd binaries will mostly link to the same libraries (because > > > they link to a private shared library, which links to various other > > > shared libraries). So this "20M" will be repeated over and over, but > > > it's the same dependencies. > > > > > > While we'd all prefer for this to be smaller, 20M should is actually > > > not that much... > > > > > > > And as a compare, from version 219 to 243, systemd's library > > > > dependency increased a lot: > > > > (v219 is 5M in total, v243 is 20M in total) > > > > > > This is slightly misleading. Code was moved from individual binaries > > > to libsystemd-shared-nnn.so, so if you look at the deps of just a single > > > binary, you'll see many more deps (because libsystemd-shared-nnn.so has > > > more deps). But the total number of deps when summed over all binaries > > > grew much less. A more useful measure would be the size with deps summed > > > over all systemd binaries that are installed into your image in v219 and > > > v243. > > > > > > > I vaguely remember the size increased before due to linking with libidn2 > > previously, so those libraries contribute a lot. > > > > Does every systemd binary depend on all libraries? Or each of the > > systemd binary only depends on those libs when really needed? > > For example if I do not need journalctl, then I can drop journalctl and > those libraries specific for journalctl? It's using standard shared object linking, so yeah, for anything which libsystemd-shared-nnn.so links to, "every systemd binary depend[s] on all libraries", in the sense that the runtime linker will fail to start the executable if any of the libraries are missing. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Minimize systemd for kdump's initramfs
On Thu, Jan 02, 2020 at 03:29:26PM -0500, Robbie Harwood wrote: > Kairui Song writes: > > > What I'm trying to do is reduce the initramfs size used for kdump. > > Kdump loads a crash kernel and kdump initramfs image in a prereseved > > memory region, which get booted when current kernel crashed and > > perform crash dump. The prereserved memory is limited, so initramfs > > shouldn't go too big. > > > > Kdump in Fedora use Dracut to create bootable initramfs, just hook the > > final step to do kdump things instead of switch root. And to reduce > > the size only the binaries and drivers required to boot and perform > > kdump on current machine is installed. So long it have been working > > very well. > > > > But problem is Dracut works by reusing binaries and libraries from the > > currently running system, and many userspace binaries and libraries is > > keep growing and using more space. So the initramfs is also growing. > > > > /root/image/bin/bash > > 4.8M. > > /root/image/bin/sh > > 4.8M. > > So it's not a direct comparison, but: > > $ du -sh /bin/bash /bin/dash > 1.2M /bin/bash > 132K /bin/dash > > This suggests to me that 1-3 MB could be reduced by using dash as the > shell. (dash's library dependencies are also smaller since it drops > requirements on libtinfo (200K) and libdl (36K); whether this matters I > don't know.) dash doesn't support various bash extensions and syntaxes. The problem is that many scripts which use #!/bin/sh really require #!/bin/bash. So after switching to dash as the provider of /bin/sh various scripts would suddenly behave differently, and those bugs would only be detected at runtime. Debian went through a long process of switching to dash as the default init shell and fixing various scripts to remove bashisms so things would run on dash (or any other /bin/sh). This was way more work than anyone excepted and took a long time. IMO the gain of 1 MB that we would get is not nearly enough to offset the work required and the destabilization. (In Debian the motivation was speed, rather than installation footprint. So that work was mostly wasted because of the switch from sysvinit to systemd and ensuing avoidance of shell during boot. Instead of trying to switch shells, we should instead try to avoid shell in boot as much as possible.) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Minimize systemd for kdump's initramfs
On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote: > Some component, like Systemd, have grown by a lot, here is a list of > the size of part of binaries along with the binaries they required in > F31: > /root/image/bin/systemctl > 20M . > /root/image/usr/bin/systemctl > 20M . > /root/image/usr/bin/systemd-cgls > 20M . > /root/image/usr/bin/systemd-escape > 20M . > /root/image/usr/bin/systemd-run > 20M . > ... > > There are overlays between the libraries they used so when installed > into the initramfs, the total size didn't go too big yet. But we can > see the size of systemd binary and libraries it used is much bigger > than others. All systemd binaries will mostly link to the same libraries (because they link to a private shared library, which links to various other shared libraries). So this "20M" will be repeated over and over, but it's the same dependencies. While we'd all prefer for this to be smaller, 20M should is actually not that much... > And as a compare, from version 219 to 243, systemd's library > dependency increased a lot: > (v219 is 5M in total, v243 is 20M in total) This is slightly misleading. Code was moved from individual binaries to libsystemd-shared-nnn.so, so if you look at the deps of just a single binary, you'll see many more deps (because libsystemd-shared-nnn.so has more deps). But the total number of deps when summed over all binaries grew much less. A more useful measure would be the size with deps summed over all systemd binaries that are installed into your image in v219 and v243. I don't have a link at hand, but there's work being done to use openssl for all crypto, which would reduce the dependency list nicely. > Is there any way to have a smaller systemd binary that is just enough > to boot the initramfs into the stage before switch-root? We don't have anything like this now, sorry! Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Why does initrd-parse-etc.service re-start initrd-fs.target?
On Sat, Dec 14, 2019 at 11:58:37AM +0300, Andrei Borzenkov wrote: > 09.12.2019 10:06, Ulrich Windl пишет: > >> > >> After real root is mounted daemon-reload re-runs fstab generator which > >> parses real root /etc/fstab and may pull mount points from it. > > > > I wonder: Are there realistic cases when the fstab in initrd is newer than > > the > > fstab in the root file system? > > It has nothing to do with being "newer". It allows managing initrd > filesystems in one place and avoids need to re-create initrd every time > you need additional filesystem. I'd go even further: initramfses should not need to be rebuilt all the time. I.e. they should be what dracut calls hostonly=no. Having to propagate configuration files from the host to the initramfs is very costly. So yeah, in general I think we need to think about mechanisms which pull all possible information from the host. This is never going to be as simple as encoding all configuration statically in the initramfs, but that's the price we have to pay for usability. Zbyszek > > That would be the case where detecting a "new" > > fstab would fail. I didn't dig into the generators, but an alternative > > method > > to detect a file change would be to compare the size as well (as cheap as > > stat()), or to compare some checksum (requires some more extra code). I feel > > the generators should fix the issue, not the user (i.e. restart). > > > >> Restarting initrd-fs.target will propagate start request to its (newly > >> created) dependent mount units. Otherwise there is no obvious way to > >> start them (without explicitly starting each). > > > > I never liked the idea of generators and /etc/fstab. > > > > It fits perfectly into systemd design goal - start services *on boot* > once. Most problems with systemd stem from attempt to use it as "dynamic > service manager" which it is not. This discussion is example of it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No error even a Required= service does not exist
On Mon, Nov 25, 2019 at 06:13:17PM +0200, Uoti Urpala wrote: > On Mon, 2019-11-25 at 15:19 +0200, Mantas Mikulėnas wrote: > > > Requires=xyz.service > > > > > > produces no complaint and starts the service even if there is no > > > xyz.service > > > Is this the normal behavior or can I configure systemd to throw an error > > > in this case? > > > > The docs say you can get this behavior if you also have After=xyz.service. > > (Not entirely sure why.) > > No when there IS NOT an "After=xyz.service". > > Without "After=", there is no ordering dependency - it just tells that > anything starting this unit will effectively order the start of the > other as well. Without ordering, this unit can be the one to start > first. If the other one fails to actually start later, that doesn't > make systemd go back to stop this one (note that this is consistent > with ordering dependencies - if a depended-on service fails later > during runtime, that does not automatically force a stop of already > running depending services). I guess this logic extends to failures of > the "does not exist at all" type where there was never a chance of > successfully starting the unit. Sounds like a bug. I'd expect the transaction to fail if the Required unit cannot be found. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Please reopen issue #12506
On Mon, Nov 18, 2019 at 11:41:20AM +, Marcos Mello wrote: > Although util-linux's fstab.d work has stalled, there is still systemd code > that needs porting to libmount. See Karel's last comment: > > https://github.com/systemd/systemd/issues/12506 Reopened. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dead link in the documentation of the Journal File Format on freedesktop.org
On Thu, Nov 07, 2019 at 02:12:55PM +, kein name wrote: > Hi, > > I'd like to report a dead link in the documentation of the Journal File > Format on freedesktop.org[1]. > The link[2] goes to gmane.org which is dead, it should probably use your own > mailing list archive[3]. Thanks, updated. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is the watchdog useful?
On Thu, Oct 31, 2019 at 06:30:33PM +0100, Lennart Poettering wrote: > On Mo, 21.10.19 17:50, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > In principle, the watchdog for services is nice. But in practice it seems > > be bring only grief. The Fedora bugtracker is full of automated reports of > > ABRTs, > > and of those that were fired by the watchdog, pretty much 100% are bogus, in > > the sense that the machine was resource starved and the watchdog fired. > > > > There a few downsides to the watchdog killing the service: > > 1. if it is something like logind, it is possible that it will cause > > user-visible > > failure of other services > > 2. restarting of the service causes additional load on the machine > > 3. coredump handling causes additional load on the machine, quite > > significant > > 4. those failures are reported in bugtrackers and waste everyone's time. > > > > I had the following ideas: > > 1. disable coredumps for watchdog abrts: systemd could set some flag > > on the unit or otherwise notify systemd-coredump about this, and it could > > just > > log the occurence but not dump the core file. > > 2. generally disable watchdogs and make them opt in. We have > > 'systemd-analyze service-watchdogs', > > and we could make the default configurable to "yes|no". > > > > What do you think? > > Isn't this more a reason to substantially increase the watchdog > interval by default? i.e. 30min if needed? Yep, there was a proposal like that. I want to make it 1h in Fedora. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] getting ready for v244
Hi everyone, I think it's time to get ready for a v244-prerelease. Currently, 8 issues are open on https://github.com/systemd/systemd/milestones/v244 without a PR. I'll be working on the remaining issues and hope to release an -rc1 late this week or early next. If there is stuff I should review or look into with higher priority, let me know.. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is the watchdog useful?
On Thu, Oct 24, 2019 at 02:56:55PM -0700, Vito Caputo wrote: > On Thu, Oct 24, 2019 at 10:45:32AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Oct 22, 2019 at 04:35:13AM -0700, Vito Caputo wrote: > > > On Tue, Oct 22, 2019 at 10:51:49AM +, Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > On Tue, Oct 22, 2019 at 12:34:45PM +0200, Umut Tezduyar Lindskog wrote: > > > > > I am curious Zbigniew of how you find out if the coredump was on a > > > > > starved > > > > > process? > > > > > > > > A very common case is systemd-journald which gets SIGABRT when in a > > > > read() or write() or similar syscall. Another case is when > > > > systemd-udevd workers get ABRT when doing open() on a device. > > > > > > > > > > In the case of journald, is it really in read()/write() syscalls you're > > > seeing the SIGABRTs? > > > > I was sloppy here — it's not read/write, but various other syscalls. > > In particular clone(), which makes sense, because it involves memory > > allocation. > > > > That's interesting, it's not like journald calls clone() a lot. Hm, maybe it was udevd that was calling clone(), not journald. All the reports are available here: https://bugzilla.redhat.com/show_bug.cgi?id=1300212 I opened a pull request to make the watchdog setting configurable for our own internal services: https://github.com/systemd/systemd/pull/13843. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is the watchdog useful?
On Tue, Oct 22, 2019 at 04:35:13AM -0700, Vito Caputo wrote: > On Tue, Oct 22, 2019 at 10:51:49AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Oct 22, 2019 at 12:34:45PM +0200, Umut Tezduyar Lindskog wrote: > > > I am curious Zbigniew of how you find out if the coredump was on a starved > > > process? > > > > A very common case is systemd-journald which gets SIGABRT when in a > > read() or write() or similar syscall. Another case is when > > systemd-udevd workers get ABRT when doing open() on a device. > > > > In the case of journald, is it really in read()/write() syscalls you're > seeing the SIGABRTs? I was sloppy here — it's not read/write, but various other syscalls. In particular clone(), which makes sense, because it involves memory allocation. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is the watchdog useful?
On Tue, Oct 22, 2019 at 12:34:45PM +0200, Umut Tezduyar Lindskog wrote: > I am curious Zbigniew of how you find out if the coredump was on a starved > process? A very common case is systemd-journald which gets SIGABRT when in a read() or write() or similar syscall. Another case is when systemd-udevd workers get ABRT when doing open() on a device. > This is common for our embedded devices. I didn't think it is common for > desktop too. > It is really useful for getting coredumps on deadlocked applications. For > that reason I don't think it is good to remove this functionality > completely. Yes, I never suggested removing it completely. I'm just saying that for the type of systems that Fedora targets, I don't recall any actual deadlock. For more specialized systems, where the workload is more predictable, it makes sense to have the watchdog. There might be cases where the kernel is dead-locked internally, and e.g. open() or modprobe() never returns. For those cases it might be useful to get the backtrace, but actually killing the process and/or storing the coredump is useful. Zbyszek > > Umut > > On Mon, Oct 21, 2019 at 7:51 PM Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > > > In principle, the watchdog for services is nice. But in practice it seems > > be bring only grief. The Fedora bugtracker is full of automated reports of > > ABRTs, > > and of those that were fired by the watchdog, pretty much 100% are bogus, > > in > > the sense that the machine was resource starved and the watchdog fired. > > > > There a few downsides to the watchdog killing the service: > > 1. if it is something like logind, it is possible that it will cause > > user-visible > > failure of other services > > 2. restarting of the service causes additional load on the machine > > 3. coredump handling causes additional load on the machine, quite > > significant > > 4. those failures are reported in bugtrackers and waste everyone's time. > > > > I had the following ideas: > > 1. disable coredumps for watchdog abrts: systemd could set some flag > > on the unit or otherwise notify systemd-coredump about this, and it could > > just > > log the occurence but not dump the core file. > > 2. generally disable watchdogs and make them opt in. We have > > 'systemd-analyze service-watchdogs', > > and we could make the default configurable to "yes|no". > > > > What do you think? > > Zbyszek > > ___ > > 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
Re: [systemd-devel] is the watchdog useful?
On Mon, Oct 21, 2019 at 02:32:08PM -0700, Vito Caputo wrote: > On Mon, Oct 21, 2019 at 05:50:44PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > In principle, the watchdog for services is nice. But in practice it seems > > be bring only grief. The Fedora bugtracker is full of automated reports of > > ABRTs, > > and of those that were fired by the watchdog, pretty much 100% are bogus, > > in > > the sense that the machine was resource starved and the watchdog fired. > > > > There a few downsides to the watchdog killing the service: > > 1. if it is something like logind, it is possible that it will cause > > user-visible > > failure of other services > > 2. restarting of the service causes additional load on the machine > > 3. coredump handling causes additional load on the machine, quite > > significant > > 4. those failures are reported in bugtrackers and waste everyone's time. > > > > I had the following ideas: > > 1. disable coredumps for watchdog abrts: systemd could set some flag > > on the unit or otherwise notify systemd-coredump about this, and it could > > just > > log the occurence but not dump the core file. > > 2. generally disable watchdogs and make them opt in. We have > > 'systemd-analyze service-watchdogs', > > and we could make the default configurable to "yes|no". > > > > What do you think? > > Zbyszek > > > I think the main issue is the watchdog timeout hasn't been tuned > appropriately for the environment it's being applied. > > It's as if the timeouts are somewhere near the hard real-time > expectations end of the spectrum, while being applied to > non-deterministically delayed and scheduled normal priority userspace > processes. It's a sort of impedance mismatch. > > I /think/ the purpose of the watchdog is to detect when processes are > permanently wedged, capture their state for debugging, and forcefully > unwedge them. > > That seems perfectly reasonable, but the timeout heuristic being used, > given our non-deterministic scheduling, should be incredibly long by > default. It's not the kind of thing you want false positives on, folks > can always shrink the timeout if they find it's desirable. It is now 3 minutes in all systemd units. Dunno, maybe we should make that 30 minutes. Zbyszek > Without having spent much time thinking about this, I'd lean towards > retaining the watchdogs but making their default timeouts so long a > program would have to be wedged for an hour+ before it triggered. > > At least that way we preserve the passive information gathering of > serious bugs which might otherwise go unnoticed with background/idle > services, improving debugging substantially, but eliminate the problems > you describe resulting from false positives. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is the watchdog useful?
On Tue, Oct 22, 2019 at 09:54:31AM +0300, Pekka Paalanen wrote: > On Mon, 21 Oct 2019 17:50:44 + > Zbigniew Jędrzejewski-Szmek wrote: > > > In principle, the watchdog for services is nice. But in practice it seems > > be bring only grief. The Fedora bugtracker is full of automated reports of > > ABRTs, > > and of those that were fired by the watchdog, pretty much 100% are bogus, > > in > > the sense that the machine was resource starved and the watchdog fired. > > Hi, > > just curious, is that resource starvation caused by something big, e.g. > a browser, using too much memory which leads to the kernel reclaiming > also pages of program text sections because they can be reloaded from > disk at any time, however those pages are needed again immediately > after when some CPU core switches process context, leading to something > that looks like a hard freeze to a user, while the kernel is furiously > loading pages from disk just to drop them again, and can take from > minutes to hours before any progress is visible? I don't really know. Unfortunately, abrt in Fedora does not collect log messages. In the old syslog days, a snippet of /var/log/messages for the last 20 minutes or something like that before a crash would be copied into the bug report, and this would include kernel messages about disk errors, or kernel stalls, or other interesting hints. Unfortunately nowadays, because of privacy concerns (?) and an effort to make things more efficient (?), just some heavily-filtered journalctl output is attached. In practice, usually this is at most a few lines and completely useless. In particular, it does not give any hints to the overall state of the system. I have spoken to abrt maintainers about this, but it seems that this problem is specific to systemd, and for most other applications it is OK to get a backtrace without any system-wide context. So I don't see this changing any time soon ;( Sometimes I ask people for logs, and sometimes I get them, and in those cases it seems that both hardware issues (e.g. a failing disk), or memory exhaustion are often involved. In some cases there is no clear reason. And since in the great majority we don't have any logs, it is hard to say anything. > It has happened to me on Fedora in the past. I could probably dig up > discussions about the problem in general if you want, they explain it > better than I ever could. > > Does Fedora prevent that situation by tuning some kernel knobs nowadays > for desktops? I don't think so. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] is the watchdog useful?
In principle, the watchdog for services is nice. But in practice it seems be bring only grief. The Fedora bugtracker is full of automated reports of ABRTs, and of those that were fired by the watchdog, pretty much 100% are bogus, in the sense that the machine was resource starved and the watchdog fired. There a few downsides to the watchdog killing the service: 1. if it is something like logind, it is possible that it will cause user-visible failure of other services 2. restarting of the service causes additional load on the machine 3. coredump handling causes additional load on the machine, quite significant 4. those failures are reported in bugtrackers and waste everyone's time. I had the following ideas: 1. disable coredumps for watchdog abrts: systemd could set some flag on the unit or otherwise notify systemd-coredump about this, and it could just log the occurence but not dump the core file. 2. generally disable watchdogs and make them opt in. We have 'systemd-analyze service-watchdogs', and we could make the default configurable to "yes|no". What do you think? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cannot unsubscribe from this list
On Tue, Oct 15, 2019 at 04:08:24PM -0400, Brian Reichert wrote: > I initiated an unsubscribe from this web page: > > https://lists.freedesktop.org/mailman/options/systemd-devel > > That created a confirmation email, that I replied to. Yeah, that doesn't work. Use the web interface: > https://lists.freedesktop.org/mailman/listinfo/systemd-devel Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Replacement for JoinControllers
On Sat, Oct 05, 2019 at 09:34:09AM +0200, azu...@pobox.sk wrote: > Hi guys. > > recently, we upgraded one of our servers from Debian Stretch > (systemd version 232-25+deb9u12) to Debian Buster (systemd version > 241-7~deb10u1). Soon after, we found out that setting > 'JoinControllers' is not longer available. Is there any replacement > or workaround? Our software is depended on that setting. The replacement is to use cgroups v2, where all controllers are always joined, so this setting is not useful. JoinContollers= was removed in 143fadf369a18449464956206226761e49be1928 because of a) cgroupsv2, b) it was broken, c) it appears almost nobody was using it (which is also confirmed by the fact that nobody reported that it doesn't work as documented...). Sorry if that's disappointing, but you'll need to switch and/or adjust. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unload disabled units
On Sun, Sep 15, 2019 at 03:12:22AM +, Daniel Duong wrote: > Hi, > > I have a 2 template units: 1 for a service and 1 for a socket. Each > instance is a version of my web application. > > After a successful deploy, I stop and disable the old version and I > enable the new one: > systemctl start belleshop@0.2.socket > # Test that everything is fine > systemctl enable belleshop@0.2.socket > systemctl stop belleshop@0.1.socket > systemctl stop belleshop@0.1.service > systemctl disable belleshop@0.1.socket > > I've done that for a few versions now, and it seemed to work OK. There > is a little problem though. The old versions are still loaded: > > $ systemctl --no-legend --all list-units belleshop@* > belleshop@0.110.service loaded active running Belleshop server > belleshop@0.34.service loaded inactive deadBelleshop server > belleshop@0.36.service loaded inactive deadBelleshop server > belleshop@0.37.service loaded inactive deadBelleshop server > [...] > belleshop@0.110.socket loaded active running Belleshop socket > belleshop@0.34.socket loaded inactive deadBelleshop socket > belleshop@0.36.socket loaded inactive deadBelleshop socket > belleshop@0.37.socket loaded inactive deadBelleshop socket > [...] > > Is there any way I can unload these old versions? Normally units should be unloaded immediately if they are stopped and didn't fail. What systemd version are you using? (One possibility to consider is that the glob matches *files*, and you are simply loading the units at the time the systemctl query is made. Use 'belleshop@*' instead.) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd243rc2, sysd-coredump is not triggered on segfaults
On Mon, Sep 02, 2019 at 07:55:20PM -0600, Chris Murphy wrote: > Maybe it's something unique to gnome-shell segfaults, that's the only > thing I have crashing right now. But I've got a pretty good reproducer > to get it to crash and I never have any listings with coredumpctl. > > process segfaults but systemd-coredump does not capture it > https://bugzilla.redhat.com/show_bug.cgi?id=1748145 Thanks for the report. I looks to be a bug/feature in gnome-shell. I replied in the bug. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] When will my timer next run?
On Fri, Aug 30, 2019 at 06:04:22PM -0700, Kenneth Porter wrote: > I've created my service timer with the following: > > [Timer] > # wait a bit after boot to let our victim catch up with its work > OnBoot=13m This needs to be OnBootSec=13m. (systemd-analyze verify is your friend in cases like this.) > # let the victim get some work done between backups > # we use inactive to prevent back-to-back backups if they run long > OnUnitInactiveSec=1h > > I then run list-timers but all the time columns for my service are > n/a. I want my backup to run with an hour between backups, and with > a pause after boot to let all the machines come up and finish > overdue work from any long power outage. I started the timer unit > and then see this: > > # systemctl list-timers > NEXT LEFT LAST PASSED > UNIT ACTIVATES > n/a n/a n/a > n/a rsync-Saruman.timer rsync-Saruman.service So... your timer has (after the invalid "OnBoot=" is ignored), only OnUnitInactiveSec=1h. After this timer unit is started, it is never scheduled. I would expect it to be scheduled 1h after the unit was started. So this seems to be bug to me. If you agree, please open an issue on https://github.com/systemd/systemd/issues/ so we can track this. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: 242~rc2 break VT/tty switching on Fedora 31
On Fri, Aug 30, 2019 at 04:08:39PM +0200, Hans de Goede wrote: > Hi All, > > I already filed a github issue for $subject: > https://github.com/systemd/systemd/issues/13437 > > But I'm not sure how close github issues are watched hence this email. It > would be nice if we can get this fixed for F31 beta, or if some more time is > needed, at least get this regression fixed for F31 gold. Yes, they are watched. No need to post to the mailing list about bugs. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-boot on Fedora 30?
On Fri, Aug 23, 2019 at 11:43:43AM -0700, Filipe Brandenburger wrote: > Hi, > > I've been trying to get sd-boot to work on Fedora 30, made some progress > but not fully there yet... > > First I found my partition GPT type in /boot was incorrect and bootctl was > trying to use /boot/efi instead. Ok, that fixed, now I get a list of > kernels. What fstype is /boot? If it's ext4, then it will not be read by sd-boot. > But whenever I boot, I only get the "Reboot Into Firmware Interface" menu > entry and nothing else... > > I imagine this might be related to the Grub entries: > > $ sudo bootctl list > /boot/loader/entries/4d3fcddc096748c4a398037699515189-5.2.8-200.fc30.x86_64.conf:7: > Unknown line "id", ignoring. > /boot/loader/entries/4d3fcddc096748c4a398037699515189-5.2.8-200.fc30.x86_64.conf:8: > Unknown line "grub_users", ignoring. > /boot/loader/entries/4d3fcddc096748c4a398037699515189-5.2.8-200.fc30.x86_64.conf:9: > Unknown line "grub_arg", ignoring. > /boot/loader/entries/4d3fcddc096748c4a398037699515189-5.2.8-200.fc30.x86_64.conf:10: > Unknown line "grub_class", ignoring. > title: Fedora (5.2.8-200.fc30.x86_64) 30 (Workstation Edition) > (default) >id: 4d3fcddc096748c4a398037699515189-5.2.8-200.fc30.x86_64 >source: > /boot/loader/entries/4d3fcddc096748c4a398037699515189-5.2.8-200.fc30.x86_64.conf > version: 5.2.8-200.fc30.x86_64 > linux: /vmlinuz-5.2.8-200.fc30.x86_64 >initrd: /initramfs-5.2.8-200.fc30.x86_64.img > options: $kernelopts > > I tried to at least fix the $kernelopts one, with grubby --args="..." > adding a dummy argument just to deduplicate it from the grubenv contents, > but still couldn't boot from there... > > Even if I fix that, looks like new kernels installed would trigger > /usr/lib/kernel/install.d/20-grub.install and probably mess up that setup > (do I have to mask or remove it completely?) > > Fedora's BLS document unfortunately doesn't mention sd-boot at all :-( > https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault > > Anyways, if anyone has hints of what I could try next, I'd be quite > interested to know. (Perhaps adding some docs to Fedora wiki would be > pretty helpful too!) I thought I'd ask here first... If I don't hear back, > I might try to ask on Fedora lists instead. Unfortunately what the grub people call BLS is not the real thing. For reasons I still don't quite understand, they decided to make their file format incompatible. (That they chose different file paths, that is understandable, because they wanted to use /boot and retain compatibility with old installations. But this is not what causes incompatibilities with sd-boot. It's the gratuitous syntax changes in entry files.) To get sd-boot working on Fedora, the easiest option is to get rid of boot loader entries in /boot, and make sure kernels are installed to /boot/efi. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nspawn blocks sync_file_range on arm
On Sun, Aug 18, 2019 at 05:02:35PM +0100, Steve Dodd wrote:
> ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2.
> The former is apparently not used, and glibc calls the latter whenever a
> userspace program calls sync_file_range. I'm guessing systemd-nspawn
> doesn't know this, because the follow code consistently fails in an nspawn
> container on ARM:
>
> #define _GNU_SOURCE
> #include
> #include
> #include
> #include
>
> void main()
> {
> int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
> int r=sync_file_range(f, 0, 0, 0);
> if (r)
> perror("sync_file_range");
> close(f);
> }
>
> This seems to be causing problems specifically for borg(backup) and
> postgres:
> https://github.com/borgbackup/borg/issues/4710
> https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93
>
> I will test the obvious fix when I can, unless someone beats me to it :)
Please test https://github.com/systemd/systemd/pull/13352.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] lto issues
On Tue, Aug 06, 2019 at 09:34:36AM +0200, Michael Biebl wrote:
> Am Di., 6. Aug. 2019 um 09:26 Uhr schrieb Zbigniew Jędrzejewski-Szmek
> :
> >
> > On Sat, Aug 03, 2019 at 07:03:47PM +0200, Michael Biebl wrote:
> > > Hi,
> > >
> > > today I tried compiling systemd v242 (on Debian sid) once using lto
> > > (-Db_lto=true) and once without lto (-Db_lto=false).
> > >
> > > The lto build took approximately twice as long on my laptop (using
> > > dpkg-buildpackage, which introduces a bit of overhead):
> > >
> > > lto:
> > > real 11m22,605s
> > > user 37m9,675s
> > > sys 2m51,041s
> > >
> > > nolto:
> > > real 6m35,615s
> > > user 18m51,782s
> > > sys 2m12,934s
> > >
> > > That's kinda expected. What suprised me though is that using lto
> > > produced larger binaries:
> >
> > I built systemd in F31 (-Doptimization=2 -Db_lto=true/false, and I saw
> > a big increase in binary sizes *before stripping*. After stripping,
> > binaries with lto=true are smaller:
> >
> > $ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
> > 7116384 Aug 6 09:08 build-rawhide/systemd*
> > 11951256 Aug 6 09:07 build-rawhide/src/shared/libsystemd-shared-243.so*
> > 1594912 Aug 6 09:12 build-rawhide-lto/systemd*
> > 3167096 Aug 6 09:11
> > build-rawhide-lto/src/shared/libsystemd-shared-243.so*
> > $ strip build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
> > $ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
> > 1439640 Aug 6 09:19 build-rawhide/systemd*
> > 2806456 Aug 6 09:19 build-rawhide/src/shared/libsystemd-shared-243.so*
> > 1370008 Aug 6 09:19 build-rawhide-lto/systemd*
> > 2806288 Aug 6 09:19
> > build-rawhide-lto/src/shared/libsystemd-shared-243.so*
>
>
> The sizes I posted i.e. the debdiff is after stripping.
>
> gcc --version
> gcc (Debian 8.3.0-19) 8.3.0
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> ld --version
> GNU ld (GNU Binutils for Debian) 2.32.51.20190727
> Copyright (C) 2019 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
>
> So with the toolchain I have, mostly has downsides. The only benefit
> it seems to have is that it optimizes unnecessary library dependencies
> away (see how the udev subpackage does not depend on libcap2 (>=
> 1:2.10), libidn2-0 (>= 0.6)
In Fedora, lto seems to have good returns. The final package size was
~10% smaller. We disabled it for a while because there were linking
failures, but I think it's all resolved now.
I forgot to mention. In my test:
gcc-9.1.1-2.fc31.1.x86_64
binutils-2.32-19.fc31.x86_64
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] lto issues
On Sat, Aug 03, 2019 at 07:03:47PM +0200, Michael Biebl wrote:
> Hi,
>
> today I tried compiling systemd v242 (on Debian sid) once using lto
> (-Db_lto=true) and once without lto (-Db_lto=false).
>
> The lto build took approximately twice as long on my laptop (using
> dpkg-buildpackage, which introduces a bit of overhead):
>
> lto:
> real 11m22,605s
> user 37m9,675s
> sys 2m51,041s
>
> nolto:
> real 6m35,615s
> user 18m51,782s
> sys 2m12,934s
>
> That's kinda expected. What suprised me though is that using lto
> produced larger binaries:
I built systemd in F31 (-Doptimization=2 -Db_lto=true/false, and I saw
a big increase in binary sizes *before stripping*. After stripping,
binaries with lto=true are smaller:
$ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
7116384 Aug 6 09:08 build-rawhide/systemd*
11951256 Aug 6 09:07 build-rawhide/src/shared/libsystemd-shared-243.so*
1594912 Aug 6 09:12 build-rawhide-lto/systemd*
3167096 Aug 6 09:11 build-rawhide-lto/src/shared/libsystemd-shared-243.so*
$ strip build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
$ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
1439640 Aug 6 09:19 build-rawhide/systemd*
2806456 Aug 6 09:19 build-rawhide/src/shared/libsystemd-shared-243.so*
1370008 Aug 6 09:19 build-rawhide-lto/systemd*
2806288 Aug 6 09:19 build-rawhide-lto/src/shared/libsystemd-shared-243.so*
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd's connections to /run/systemd/private ?
On Thu, Aug 01, 2019 at 08:46:58AM -0400, Brian Reichert wrote: > On Thu, Aug 01, 2019 at 08:17:01AM +, Zbigniew J??drzejewski-Szmek wrote: > > The kernel will use the lower-numbered available fd, so there's lot of > > "reuse" of the same numbers happening. This strace means that between > > each of those close()s here, some other function call returned fd 19. > > Until we know what those calls are, we cannot say why fd19 remains > > open. (In fact, the only thing we can say for sure, is that the > > accept4() call shown above is not relevant.) > > So, what I propose at this step: > > - Restart my strace, this time using '-e trace=desc' (Trace all > file descriptor related system calls.) > > - Choose to focus on a single descriptor; when I passively notice > that '19' has been reused a couple of time, stop the trace. Well, no. If you notice that '19' has STOPPED being reused, then stop the trace. If it is being reused, then it's it's not "leaked". Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Backup the current boot logs in raw format
On Thu, Aug 01, 2019 at 10:52:07AM +0200, Francis Moreau wrote: > On Thu, Aug 1, 2019 at 10:36 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Thu, Aug 01, 2019 at 10:26:50AM +0200, Francis Moreau wrote: > > > On Thu, Aug 1, 2019 at 9:45 AM Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > > > > > On Thu, Aug 01, 2019 at 09:11:19AM +0200, Francis Moreau wrote: > > > > > On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek > > > > > wrote: > > > > > > you can export and write to a journal file with: > > > > > > journalctl -o export ... | > > > > > > /usr/lib/systemd/systemd-journal-remote -o /tmp/foo.journal - > > > > > > This has the advantage that you can apply any journalctl filter > > > > > > where > > > > > > the dots are, e.g. '-b'. > > > > > > > > > > This doesn't look to work correctly: > > > > > > > > > > $ journalctl -b | head > > > > > -- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01 > > > > > 08:51:39 CEST. -- > > > > > Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to > > > > > revision 0x25, date = 2018-04-02 > > > > > > > > > > $ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o > > > > > /tmp/foo.journal - > > > > > $ journalctl -b --file=/tmp/foo.journal | head > > > > > -- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01 > > > > > 08:45:45 CEST. -- > > > > > Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication > > > > > Agent for unix-process:7300:772806437 (system bus name :1.4562, object > > > > > path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale > > > > > en_US.UTF-8) (disconnected from bus) > > > > > > > > > > As you can see, the start is not the same. > > > > > > > > > > Also are foo.journal data compressed ? > > > > > > > > What does "ls /tmp/foo*" say? > > > > > > > > > > /tmp/foo@4e9f5da4aaac4433bc8744fe49e25b5a-0001-000584e4cc1ef61f.journal > > > /tmp/foo.journal > > > > systemd-journal-remote will "rotate" files when they grow above certain > > size. > > (The same as systemd-journald). 'journalctl --file=/tmp/foo*.journal' should > > do the trick. > > Indeed that did the trick, thanks ! > > It's a bit counterintuitive because I asked the journal to be saved in > /tmp/foo.journal only. Can this "rotation" be disabled somehow ? Unfortunately not. That's because of the heritage of those programs which were written in mind with continuous reception of logs in mind, and "conversions" like the one above were just a fortunate side-effect. I guess it'd be nice to make it possible to disable rotation. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Backup the current boot logs in raw format
On Thu, Aug 01, 2019 at 10:26:50AM +0200, Francis Moreau wrote: > On Thu, Aug 1, 2019 at 9:45 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Thu, Aug 01, 2019 at 09:11:19AM +0200, Francis Moreau wrote: > > > On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > you can export and write to a journal file with: > > > > journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote -o > > > > /tmp/foo.journal - > > > > This has the advantage that you can apply any journalctl filter where > > > > the dots are, e.g. '-b'. > > > > > > This doesn't look to work correctly: > > > > > > $ journalctl -b | head > > > -- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01 > > > 08:51:39 CEST. -- > > > Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to > > > revision 0x25, date = 2018-04-02 > > > > > > $ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o > > > /tmp/foo.journal - > > > $ journalctl -b --file=/tmp/foo.journal | head > > > -- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01 > > > 08:45:45 CEST. -- > > > Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication > > > Agent for unix-process:7300:772806437 (system bus name :1.4562, object > > > path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale > > > en_US.UTF-8) (disconnected from bus) > > > > > > As you can see, the start is not the same. > > > > > > Also are foo.journal data compressed ? > > > > What does "ls /tmp/foo*" say? > > > > /tmp/foo@4e9f5da4aaac4433bc8744fe49e25b5a-0001-000584e4cc1ef61f.journal > /tmp/foo.journal systemd-journal-remote will "rotate" files when they grow above certain size. (The same as systemd-journald). 'journalctl --file=/tmp/foo*.journal' should do the trick. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd's connections to /run/systemd/private ?
On Wed, Jul 31, 2019 at 11:37:31AM -0400, Brian Reichert wrote:
> On Wed, Jul 31, 2019 at 12:36:41AM +0300, Uoti Urpala wrote:
> > On Tue, 2019-07-30 at 14:56 -0400, Brian Reichert wrote:
> > > I see, between 13:49:30 and 13:50:01, I see 25 'successful' calls
> > > for close(), e.g.:
> > >
> > > 13:50:01 close(19) = 0
> > >
> > > Followed by getsockopt(), and a received message on the supposedly-closed
> > > file descriptor:
> > >
> > > 13:50:01 getsockopt(19, SOL_SOCKET, SO_PEERCRED, {pid=3323, uid=0,
> > > gid=0}, [12]) = 0
> >
> > Are you sure it's the same file descriptor? You don't explicitly say
> > anything about there not being any relevant lines between those. Does
> > systemd really just call getsockopt() on fd 19 after closing it, with
> > nothing to trigger that? Obvious candidates to check in the strace
> > would be an accept call returning a new fd 19, or epoll indicating
> > activity on the fd (though I'd expect systemd to remove the fd from the
> > epoll set after closing it).
>
> My analysis is naive.
>
> There was an earlier suggestion to use strace, limiting it to a
> limited number of system calls.
>
> I then used a simple RE to look for the string '(19', to see calls where
> '19' was used as an initial argument to system calls. That's way too
> simplistic.
>
> To address some of your questions/points.
>
> - No, I don't know if it's the same file descriptor. I could not
> start strace early enough to catch the creation of several dozen
> file descriptors.
This shouldn't really matter. We care about descriptors which are
created while the process is running, so it is not a problem if we
"miss" some that are created early.
> 13:50:01 accept4(13, 0, NULL, SOCK_CLOEXEC|SOCK_NONBLOCK) = 19
> 13:50:01 getsockopt(19, SOL_SOCKET, SO_PEERCRED, {pid=3323, uid=0, gid=0},
> [12]) = 0
> 13:50:01 getsockopt(19, SOL_SOCKET, SO_RCVBUF, [4194304], [4]) = 0
> 13:50:01 getsockopt(19, SOL_SOCKET, SO_SNDBUF, [262144], [4]) = 0
> 13:50:01 getsockopt(19, SOL_SOCKET, SO_PEERCRED, {pid=3323, uid=0, gid=0},
> [12]) = 0
> 13:50:01 getsockopt(19, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0 13:50:01
> getsockname(19, {sa_family=AF_LOCAL, sun_path="/run/systemd/private"}, [23])
> = 0 13:50:01 recvmsg(19, {msg_name(0)=NULL, msg_iov(1)=[{"\0AUTH EXTERNAL
> 30\r\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", 256}], msg_controllen=0,
> msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 45
> 13:50:01 sendmsg(19, {msg_name(0)=NULL, msg_iov(3)=[{"OK
> 9fcf621ece0a4fe897586e28058cd2fb\r\nAGREE_UNIX_FD\r\n", 52}, {NULL, 0},
> {NULL, 0}], msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 52
> 13:50:01 sendmsg(19, {msg_name(0)=NULL,
> msg_iov(2)=[{"l\4\1\1P\0\0\0\1\0\0\0p\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\2\1s\0
>
> \0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\3\1s\0\7\0\0\0UnitNew\0\10\1g\0\2so\0",
> 128},
> {"\20\0\0\0session-11.scope\0\0\0\0003\0\0\0/org/freedesktop/systemd1/unit/session_2d11_2escope\0",
> 80}], msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = -1 EPIPE
> (Broken pipe)
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
> 13:50:01 close(19) = 0
The kernel will use the lower-numbered available fd, so there's lot of
"reuse" of the same numbers happening. This strace means that between
each of those close()s here, some other function call returned fd 19.
Until we know what those calls are, we cannot say why fd19 remains
open. (In fact, the only thing we can say for sure, is that the
accept4() call shown above is not relevant.)
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Backup the current boot logs in raw format
On Thu, Aug 01, 2019 at 09:11:19AM +0200, Francis Moreau wrote: > On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek > wrote: > > you can export and write to a journal file with: > > journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote -o > > /tmp/foo.journal - > > This has the advantage that you can apply any journalctl filter where > > the dots are, e.g. '-b'. > > This doesn't look to work correctly: > > $ journalctl -b | head > -- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01 > 08:51:39 CEST. -- > Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to > revision 0x25, date = 2018-04-02 > > $ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o > /tmp/foo.journal - > $ journalctl -b --file=/tmp/foo.journal | head > -- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01 > 08:45:45 CEST. -- > Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication > Agent for unix-process:7300:772806437 (system bus name :1.4562, object > path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale > en_US.UTF-8) (disconnected from bus) > > As you can see, the start is not the same. > > Also are foo.journal data compressed ? What does "ls /tmp/foo*" say? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KExecWatchdogSec NEWS entry needs work
On Tue, Jul 30, 2019 at 08:32:44AM +1000, Clinton Roy wrote: > Particularly the following sentence: > > This option defaults to off, since it depends on drivers and > software setup whether the watchdog is correctly reset again after > the kexec completed, and thus for the general case not clear if safe > (since it might cause unwanted watchdog reboots after the kexec > completed otherwise). > > I can't quite work out what intent is, otherwise I'd take a stab myself. https://github.com/systemd/systemd/pull/13227 Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Backup the current boot logs in raw format
On Wed, Jul 24, 2019 at 03:48:40PM +0200, Francis Moreau wrote: > Hi, > > I would like to backup the journal logs for the current boot in a > "raw" format so I can reuse it later with "journalctl > --file=my-backup". > > But looking at the different values for "-o" option I can't find the answer. > > Could anybody give me some clues ? One option is to simply copy some of the files in /var/log/journal to a different location. You can then read them with 'journalctl -D'. If you want to be more granular and only select specific log entries, you can export and write to a journal file with: journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote -o /tmp/foo.journal - This has the advantage that you can apply any journalctl filter where the dots are, e.g. '-b'. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Unknown lvalue '' in section 'Service'"
On Thu, Jul 18, 2019 at 11:46:59AM +0300, Mantas Mikulėnas wrote: > On Thu, Jul 18, 2019 at 11:34 AM Ulrich Windl < > ulrich.wi...@rz.uni-regensburg.de> wrote: > > > Hi! > > > > I noticed that a line of "===" in "[Service]" cases the message " > > Unknown lvalue '' in section 'Service'". > > (systemd 228) > > > > Shouldn't that be "Parse error at '===' in section 'Service'"? > > > > Arguably it isn't a parse error – the keyfile parser successfully > recognizes the line as assigning the value "==" to the key "". It's > only later when the parsed results are interpreted that each key is matched > to an internal handler. > > The error message *could* be clearer if all such errors had a common "Parse > error:" prefix, I guess. (And what's the point of calling it an 'lvalue' > anyway?...) https://github.com/systemd/systemd/pull/13107 Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd's connections to /run/systemd/private ?
On Thu, Jul 11, 2019 at 10:08:43AM -0400, Brian Reichert wrote: > On Wed, Jul 10, 2019 at 10:44:14PM +, Zbigniew J??drzejewski-Szmek wrote: > > That's ancient... 228 was released almost four years ago. > > That's the joy of using a commercial Linux distribution; they tend > to be conservative about updates. SLES may very well have backported > fixes to the packaged version they maintain. > > They may also have a newer version of a systemd RPM for us to take. > > I'm looking for an efficient way to repro the symptoms, as to confirm > whether a newer RPM solves this for us. > > > > > > When we first spin up a new SLES12 host with our custom services, > > > > > the number of connections to /run/systemd/private numbers in the > > > > > mere hundreds. > > > > > > > That sounds wrong already. Please figure out what those connections > > > > are. I'm afraid that you might have to do some debugging on your > > > > own, since this issue doesn't seem easily reproducible. > > Above, I cite a desire for reproducing the symptoms. If you're > confident that a newly-spun-up idle host should not hover at hundreds > of connections, then hypothetically I could update the vendor-provided > systemd RPM (if there is one), reboot, and see if the connection > count is reduced. > > > strace -p1 -e recvmsg,close,accept4,getsockname,getsockopt,sendmsg -s999 > > > > yields the relevant info. In particular, the pid, uid, and guid of the > > remote is shown. My approach would be to log this to some file, and > > then see which fds remain, and then look up this fd in the log. > > The recvmsg calls contain the serialized dbus calls, a bit messy but > > understandable. E.g. 'systemctl show systemd-udevd' gives something > > like this: > > Thanks for such succinct feedback; I'll see what I can get from this. > > In my prior email, I showed how some of the connections were > hours/days old, even with no connecting peer. > > Does that sound like expected behavior? No, this shouldn't happen. What I was trying to say, is that if you have the strace log, you can figure out what created the stale connection and what the dbus call was, and from all that info it should be fairly simply to figure out what the calling command was. Once you have that, it'll be much easier to reproduce the issue in controlled setting and look for the fix. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd's connections to /run/systemd/private ?
On Wed, Jul 10, 2019 at 09:51:36AM -0400, Brian Reichert wrote:
> On Wed, Jul 10, 2019 at 07:37:19AM +, Zbigniew J??drzejewski-Szmek wrote:
>
> > It's a bug report as any other. Writing a meaningful reply takes time
> > and effort. Lack of time is a much better explanation than ressentiments.
>
> I wasn't expressing resentment; I apologize if it came off that way.
>
> > Please always specify the systemd version in use. We're not all SLES
> > users, and even if we were, I assume that there might be different
> > package versions over time.
>
> Quite reasonable:
>
> localhost:/var/tmp # cat /etc/os-release
> NAME="SLES"
> VERSION="12-SP3"
> VERSION_ID="12.3"
> PRETTY_NAME="SUSE Linux Enterprise Server 12 SP3"
> ID="sles"
> ANSI_COLOR="0;32"
> CPE_NAME="cpe:/o:suse:sles:12:sp3"
>
> localhost:/var/tmp # rpm -q systemd
> systemd-228-142.1.x86_64
That's ancient... 228 was released almost four years ago.
> > > When we first spin up a new SLES12 host with our custom services,
> > > the number of connections to /run/systemd/private numbers in the
> > > mere hundreds.
>
> > That sounds wrong already. Please figure out what those connections
> > are. I'm afraid that you might have to do some debugging on your
> > own, since this issue doesn't seem easily reproducible.
>
> What tactics should I employ? All of those file handles to
> /run/systemd/private are owned by PID 1, and 'ss' implies there are
> no peers.
>
> 'strace' in pid shows messages are flowing, but that doesn't reveal
> the logic about how the connections get created or culled, nor who
> initiated them.
strace -p1 -e recvmsg,close,accept4,getsockname,getsockopt,sendmsg -s999
yields the relevant info. In particular, the pid, uid, and guid of the
remote is shown. My approach would be to log this to some file, and
then see which fds remain, and then look up this fd in the log.
The recvmsg calls contain the serialized dbus calls, a bit messy but
understandable. E.g. 'systemctl show systemd-udevd' gives something
like this:
recvmsg(20, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="l\1\4\1\5\0\0\0\1\0\0\0\257\0\0\0\1\1o\08\0\0\0",
iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
recvmsg(20, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="/org/freedesktop/systemd1/unit/systemd_2dudevd_2eservice\0\0\0\0\0\0\0\0\3\1s\0\6\0\0\0GetAll\0\0\2\1s\0\37\0\0\0org.freedesktop.DBus.Properties\0\6\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\10\1g\0\1s\0\0\0\0\0\0\0",
...
HTH,
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] OFFLIST Re: systemd's connections to /run/systemd/private ?
On Tue, Jul 09, 2019 at 11:05:50PM +0300, Mantas Mikulėnas wrote: > On Tue, Jul 9, 2019 at 4:28 PM Brian Reichert wrote: > > > On Tue, Jul 09, 2019 at 11:21:13AM +0100, > > systemd-devel@lists.freedesktop.org wrote: > > > Hi Brian > > > > > > I feel embarrassed at having recommended you to join the systemd-devel > > > list :( I don't understand why nobody is responding to you, and I'm not > > > qualified to help! > > > > I appreciate the private feedback. I recognize this is an all-volunteer > > ecosystem, but I'm not used to radio silence. :/ > > > > > There is a bit of anti-SUSE feeling for some reason > > > that I don't really understand, but Lennart in particular normally > > > seems to be very helpful, as does Zbigniew. > > > > It seems that Lennart tends to process his mailing-list inbox only every > couple of weeks. He's a bit more active on GitHub however. > > The rest of us are probably either waiting for a dev to make a comment, > and/or wondering why such massive numbers of `systemctl` are being run on > your system in the first place. > > > > I'm new to this list, so haven't seen any anti-SLES sentiments as > > of yet. But, based on the original symptoms I reported, this occurs > > on many distributions. It's a bug report as any other. Writing a meaningful reply takes time and effort. Lack of time is a much better explanation than ressentiments. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd's connections to /run/systemd/private ?
On Tue, Jul 02, 2019 at 09:57:44AM -0400, Brian Reichert wrote:
> At $JOB, on some of our SLES12 boxes, our logs are getting swamped
> with messages saying:
>
> "Too many concurrent connections, refusing"
Please always specify the systemd version in use. We're not all SLES
users, and even if we were, I assume that there might be different
package versions over time.
> # ss -x | grep /run/systemd/private | wc -l
> 4015
/run/systemd/private is used by systemctl and other systemd utilities
when running as root. Those connections are expected to be short-lived.
Generally, on a normal machine "ss -x | grep /run/systemd/private | wc -l"
is expected to yield 0 or a very low number transiently.
> But, despite the almost 4k connections, 'ss' shows that there are
> no connected peers:
>
> # ss -x | grep /run/systemd/private | grep -v -e '* 0' | wc -l
> 0
Interesting. ss output is not documented at all from what I can see,
but indeed '* 0' seems to indicate that. It is possible that systemd
has a leak and is not closing the private bus connections properly.
> When we first spin up a new SLES12 host with our custom services,
> the number of connections to /run/systemd/private numbers in the
> mere hundreds.
That sounds wrong already. Please figure out what those connections
are. I'm afraid that you might have to do some debugging on your
own, since this issue doesn't seem easily reproducible.
(I installed systemd with CONNECTIONS_MAX set to 10, and I can easily
saturate the number of available connections with
for i in {1..11}; do systemctl status '*' & sleep 0.5; kill -STOP $!;done
As soon as I allow the processes to continue or kill them, the connection
count goes down. They never show up with '* 0'.)
> Is my guess about CONNECTIONS_MAX's relationship to /run/systemd/private
> correct?
Yes. The number is hardcoded because it's expected to be "large
enough". The connection count shouldn't be more than "a few" or maybe
a dozen at any time.
> I have a hypothesis that this may be some resource leak in systemd,
> but I've not found a way to test that.
Once you figure out what is creating the connection, it would be useful
to attach strace to pid 1 and see what is happening there.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Is "systemctl status --state=failed" expected to fail silently?
On Tue, Jul 09, 2019 at 10:23:47AM +0200, Ulrich Windl wrote: > >>> Zbigniew Jedrzejewski-Szmek schrieb am 09.07.2019 um > 10:05 > in Nachricht <20190709080527.gk17...@in.waw.pl>: > > On Tue, Jul 09, 2019 at 08:49:32AM +0200, Ulrich Windl wrote: > >> Hi! > >> > >> It seems "‑‑state=failed" is being ignored silently for "systemctl status" > (in > > version 228). Is this by design? > > > > Nope. In 242‑1092+ it seems to work fine. > > In v228 is is effective for "list-units", but not for "status"... Oh, right. I checked "list-units", but not "status". "systemctl status 'systemd*' --state=running" and "systemctl status 'systemd*' --state=failed" both seem to do the right thing here. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is "systemctl status --state=failed" expected to fail silently?
On Tue, Jul 09, 2019 at 08:49:32AM +0200, Ulrich Windl wrote: > Hi! > > It seems "--state=failed" is being ignored silently for "systemctl status" > (in version 228). Is this by design? Nope. In 242-1092+ it seems to work fine. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] connection failure
On Tue, Jul 02, 2019 at 03:39:04PM +0200, ABDUL MAJITH wrote: > Hi all, > > I am trying to use the Docker in GNS3, when I try to launch it show the > error as follows, > > -- The start-up result is done. > Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Start request > repeated too quickly. > Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Failed with > result 'exit-code'. > Jul 02 15:21:55 reccon.irisa.fr systemd[1]: Failed to start Docker > Application Container Engine. > -- Subject: Unit docker.service has failed > -- Defined-By: systemd > -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit docker.service has failed. > -- > -- The result is failed. > Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.socket: Failed with > result 'service-start-limit-hit'. > Jul 02 15:24:06 reccon.irisa.fr systemd[1]: Starting dnf makecache... > -- Subject: Unit dnf-makecache.service has begun start-up > -- Defined-By: systemd > -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit dnf-makecache.service has begun starting up. > Jul 02 15:24:07 reccon.irisa.fr dnf[18029]: Metadata timer caching disabled. > Jul 02 15:24:07 reccon.irisa.fr systemd[1]: Started dnf makecache. > -- Subject: Unit dnf-makecache.service has finished start-up > -- Defined-By: systemd > -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit dnf-makecache.service has finished starting up. > -- > -- The start-up result is done. > ...skipping... > -- > -- The start-up result is done. > Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Start request > repeated too quickly. > Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Failed with > result 'exit-code'. > Jul 02 15:21:55 reccon.irisa.fr systemd[1]: Failed to start Docker > Application Container Engine. > -- Subject: Unit docker.service has failed > -- Defined-By: systemd > -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit docker.service has failed. > -- > -- The result is failed. > Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.socket: Failed with > result 'service-start-limit-hit'. > Jul 02 15:24:06 reccon.irisa.fr systemd[1]: Starting dnf makecache... > -- Subject: Unit dnf-makecache.service has begun start-up > -- Defined-By: systemd > -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit dnf-makecache.service has begun starting up. > Jul 02 15:24:07 reccon.irisa.fr dnf[18029]: Metadata timer caching disabled. > Jul 02 15:24:07 reccon.irisa.fr systemd[1]: Started dnf makecache. > -- Subject: Unit dnf-makecache.service has finished start-up > -- Defined-By: systemd > -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit dnf-makecache.service has finished starting up. > -- > -- The start-up result is done. > > How to rectify this failure to start the docker application This is a problem with docker. Nothing to do with the systemd-devel list. Please ask in a forum appropriate for docker issues. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Tue, Jun 25, 2019 at 10:55:27AM +0200, Lennart Poettering wrote: > On Mo, 24.06.19 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > > So for tmpfs mounts that don't turn off DefaultDependencies= we > > > implicit add in an After=swap.target ordering dep. The thinking was > > > that there's no point in swapping in all data of a tmpfs because we > > > want to detach the swap device when we are going to flush it all out > > > right after anyway. This made quite a difference to some folks. > > > > But we add Conflicts=umount.target, Before=umount.target, so we do > > swapoff on all swap devices, which means that swap in the data after all. > > Maybe that's an error, and we should remove this, at least for > > normal swap partitions (not files)? > > We never know what kind of weird storage swap might be on, I'd > probably leave that in, as it's really hard to figure out correctly > when leaving swap on would be safe and when not. > > Or to say this differently: if people want to micro-optimize that, > they by all means should, but in that case they should probably drop > in their manually crafted .swap unit with DefaultDependencies=no and > all the ordering in place they need, and nothing else. i.e. I believe > this kind of optimization is nothing we need to cater for in the > generic case when swap is configured with /etc/fstab or through GPT > enumeration. Not swapping off would make a nice optimization. Maybe we should invert this, and "drive" this from the other side: if we get a stop job for the storage device, then do the swapoff. Then if there are devices which don't need to stop, we wouldn't swapoff. This would cover the common case of swap on partition. I haven't really thought about the details, but in principle this should already work, if all the dependencies are declared correctly. > zswap is different: we know exactly that the swap data is located in > RAM, not on complex storage, hence it's entirely safe to not > disassemble it at all, iiuc. Agreed. It seems that any Conflicts= (including the one I proposed) are unnecessary/harmful. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Mon, Jun 24, 2019 at 02:11:03PM +0200, Lennart Poettering wrote: > On Sa, 22.06.19 10:42, Chris Murphy (li...@colorremedies.com) wrote: > > > Hi, > > > > I've got a commit to add 'Conflicts=umount.target' to this zram > > service based on a bug comment I cited in the comment. But I'm not > > certain I understand if it's a good idea or necessary. > > > > https://src.fedoraproject.org/fork/chrismurphy/rpms/zram/c/63900c455e8a53827aed697b9f602709b7897eb2?branch=devel > > > > I figure it's plausible at shutdown time that something is swapped > > out, and a umount before swapoff could hang (briefly or indefinitely I > > don't know), and therefore it's probably better to cause swapoff to > > happen before umount. > > So for tmpfs mounts that don't turn off DefaultDependencies= we > implicit add in an After=swap.target ordering dep. The thinking was > that there's no point in swapping in all data of a tmpfs because we > want to detach the swap device when we are going to flush it all out > right after anyway. This made quite a difference to some folks. But we add Conflicts=umount.target, Before=umount.target, so we do swapoff on all swap devices, which means that swap in the data after all. Maybe that's an error, and we should remove this, at least for normal swap partitions (not files)? > That said, I don't really grok zram, and not sure why there's any need > to detach it at all. I mean, if at shutdown we lose compressed RAM > or lose uncompressed RAM shouldn't really matter. Hence from my > perspective there's no need for Conflicts= at all, but maybe I am > missing something? > > Zbigniew, any particular reason why you added the Conflicts= line? It's been a while since I wrote that comment... Most likely I did it because that's the default combination that we use for units, and I didn't think that something different should be used for a swap service. Don't read too much into it. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Building systemd
On Sun, Jun 09, 2019 at 05:58:16PM -0300, Leonardo Akel Daher wrote: > Hi, > > I am trying to make a Pull Request for systemd, but I am struggling running > the tests locally (before making any code changes). I get the error of the > attached image when running "ninja -C build/ test". Hi, please don't attach error logs as messages. Just copy & paste the error text into your mail. You are hitting a bug in meson. Since you installed meson using pip, you have a very new meson, which you are using with a rather old python. It's likely that this combination is not tested very well. But it *should* work. Maybe you can get more help from Ubuntu users. > I then decided to try using mkosi to create an image, but then I get this > other error (attached on this other image). I currently use Ubuntu, so > should I change the file mkosi.default so it includes Ubuntu's file instead > of Fedora's? You are using an old mkosi version that doesn't know about newer Fedora. Either update, or switch to Ubuntu images as you say. > Another problem I faced, but have already fixed was while installing Meson. > In Ubuntu's package manager, the latest Meson version is < 0.46, so when > running "meson build", it renders an error stating that my Meson version > should be >= 0.46. I fixed this by installing Meson through Python's > package manager, pip. But, I think this would be a problem when trying to > build the Ubuntu image with mkosi. How would I install the pip's version of > Meson instead of Ubuntu package manager's? You can run arbitrary scripts during image creation, so in principle you could do 'pip install' then. But it quickly becomes very messy and complicated. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
