Re: [systemd-devel] mkosi config to build minimal Ubuntu 22.04 VM image?
Hi Paul, Ubuntu 22.04 is too old to run mkosi on. Your best bet is to use the tools tree functionality. By adding ToolsTree=default and ToolsTreeDistribution=debian, mkosi will build a debian image and use that image to do the final build. That will help you get around the lack of bootctl on Ubuntu Jammy. Do note that mkosi is a fast moving project and you might be better off running a distribution such as Fedora or Arch Linux which will generally have more up to date tooling than the latest Ubuntu LTS release. Cheers, Daan On Wed, 3 Apr 2024 at 14:48, Paul Menzel wrote: > > Dear Daan, > > > Thank you very much for your reply. > > > Am 04.03.24 um 15:52 schrieb Daan De Meyer: > > > Please see the config included in the mkosi repository itself: > > https://github.com/systemd/mkosi/blob/main/mkosi.conf and > > https://github.com/systemd/mkosi/tree/main/mkosi.conf.d. This should > > help you get started. https://mkosi.systemd.io/bootable.html shows how > > to build a minimal bootable image for different distributions. mkosi > > doesn't concern itself with which packages are installed in the image. > > Please refer to your distribution of choice for that. > > Thank you for the pointers. I started to try it again, but Ubuntu 22.04 > (Jammy Jellyfish) does not have `bootctl`, that means *systemd-boot* is > not in the official package archive [1]. > > > Kind regards, > > Paul > > > [1]: https://packages.ubuntu.com/search?keywords=systemd-boot
Re: [systemd-devel] repart: How to use CopyBocks= with usr-verity?
Hi Nils, Pretty sure nobody ever tried this. The root hash might be changing because we format the verity hash partition with different parameters than it was originally formatted with in your case. I assume the roothash will only stay the same if the verity format arguments are exactly the same. We'd probably accept PRs to allow configuring more verity arguments to support this use case. Cheers, Daan On Fri, 29 Mar 2024 at 19:55, Nils Kattenbeck wrote: > > Hello everyone, > > I am having trouble with getting CopyBlocks= to work with a verify enabled > usr partition. The documentations says that it should automatically work > automatically but it does not describe which properties have to be set for > which partition, i.e. repart.d file. > So far I have tried several variations of Verity=/VerityMatchKey=, settings > it only on one partition, both etc., setting CopyBlocks= on only usr or usr > and usr-verity. Setting CopyBlocks= on both does not work and systemd-repart > fails with the message that it was unable to find the correct partition for > usr-verity. The other approach was setting CopyBlocks= only on the usr > partition but regardless of what I try with Verity= the root hash changes > (and thus also the partition UUIDs). Or more specifically the usr partition > retains the correct/original PARTUUID whereas the PARTUUID of the usr-verity > partition changes. > > Maybe someone has an idea what might cause this or better yet already has a > similar working solution which they could share. > > Kind regards, > Nils >
Re: [systemd-devel] enable systemd-resolved in early boot (dracut)
Hi Aleksandar, > I want to enable systemd-resolved in early boot so that `clevis` can > resolve `tang` address by mdns. This will simplify local network > configuration by not relying on static IP addresses. > But it seems that is not enabled by default. > Is there a way to tell dracut to also include and start > `systemd-resolved` as part of early boot network start? This is something to ask on the dracut mailing list or whatever their equivalent is. Cheers, Daan On Tue, 19 Mar 2024 at 11:44, Aleksandar Kostadinov wrote: > > Hello, > > I want to enable systemd-resolved in early boot so that `clevis` can > resolve `tang` address by mdns. This will simplify local network > configuration by not relying on static IP addresses. > > But it seems that is not enabled by default. > > Is there a way to tell dracut to also include and start > `systemd-resolved` as part of early boot network start? > > Thank you. >
Re: [systemd-devel] mkosi config to build minimal Ubuntu 22.04 VM image?
Hi Paul, Please see the config included in the mkosi repository itself: https://github.com/systemd/mkosi/blob/main/mkosi.conf and https://github.com/systemd/mkosi/tree/main/mkosi.conf.d. This should help you get started. https://mkosi.systemd.io/bootable.html shows how to build a minimal bootable image for different distributions. mkosi doesn't concern itself with which packages are installed in the image. Please refer to your distribution of choice for that. Cheers, Daan On Thu, 29 Feb 2024 at 23:36, Paul Menzel wrote: > > Dear systemd and mkosi folks, > > > I would like to create a minimal Ubuntu 22.04 (Jammy) virtual machine > image for QEMU/KVM with VirtIO. Inside the VM only systemd, sshd, a > shell and curl or Wget should be installed. (From this base, one goal is > then to install BigBlueButton for example.) I found one blog post from > 2020 [1], but mkosi changed a lot since then. > > > Thank you in advance and kind regards, > > Paul > > > [1]: https://krystof.litomisky.com/2020/09/08/mkosi-for-ubuntu/
Re: [RFC] initoverlayfs - a scalable initial filesystem
> We have been working on a new initial filesystem called initoverlayfs. > It is a new filesystem that provides a more scalable approach to > initial filesystems as opposed to just using initrds. We are writing > this RFC to the systemd and dracut mailing lists (feel free to forward > to UAPI group also) because although this solution works without > changing the code in these projects, it operates in the same area as > systemd, udev, dracut, etc. and uses these tools. I like the concept of using erofs instead of a compressed cpio and we have been discussing doing something similar within systemd. I very much dislike the implementation though. I believe this should be implemented natively within the Linux kernel instead of hacking around the missing kernel support in userspace. If the kernel would add support for supplying an erofs initramfs instead of a cpio initramfs, put a writable tmpfs on top of it and would unpack any extra cpios provided by the bootloader on top of the tmpfs, then there wouldn't be any need for initoverlayfs. Before adopting anything like this I believe there should be a serious effort to get this implemented within Linux itself. Only if that turns out to be impossible should we fall back to exploring userspace only solutions. Cheers, Daan On Sat, 9 Dec 2023 at 16:08, Eric Curtin wrote: > > On Sat, 9 Dec 2023 at 14:56, Andrei Borzenkov wrote: > > > > On 09.12.2023 17:42, Eric Curtin wrote: > > > On Sat, 9 Dec 2023 at 12:46, Luca Boccassi wrote: > > >> > > >> On Fri, 8 Dec 2023 at 19:00, Eric Curtin wrote: > > >>> > > >>> We have been working on a new initial filesystem called initoverlayfs. > > >>> It is a new filesystem that provides a more scalable approach to > > >>> initial filesystems as opposed to just using initrds. We are writing > > >>> this RFC to the systemd and dracut mailing lists (feel free to forward > > >>> to UAPI group also) because although this solution works without > > >>> changing the code in these projects, it operates in the same area as > > >>> systemd, udev, dracut, etc. and uses these tools. > > >> > > >> It seems to me everything you described already exists? If you want to > > >> avoid having an initrd -> rootfs transition, you can already do that - > > > > > > You need a initrd -> rootfs transition for generic linux operating > > > systems right? > > > > No, you do not. Nothing stops you from running off initramfs (today you > > do not really have init*RAM Disk* - the content of initrd is unpacked > > into initramfs. > > Apologies if I am misinterpreting this response, I use terms initrd > and initramfs > interchangeably (not technically correct, but it's common to do this). The > point is to avoid unpacking as much as possible, because in many initrds > the majority of the software need not be unpacked, but is designed to work > with throwaway initial filesystems. > > > > > > Or else you start building all sorts of things directly > > > into the kernel which isn't really scalable. > > > > > > > See above. > > >
Re: [systemd-devel] How to debug systemd-pcrphase-initrd.service failure
Note that we also have `InitrdPackages=` in the latest mkosi release which allows you to add extra packages to the default initrd without having to build one separately. Cheers, Daan On Wed, 6 Dec 2023 at 14:26, Renjaya Raga Zenta wrote: > > Yes, I think now I understand that mkosi will build default initrd image > without tpm2-tss libraries. Perhaps because the package names are different > for each distro. > > I need to build the initrd image separately at first, then use it to build OS > image with --initrd flag. > > Thanks. > > On Wed, Dec 6, 2023 at 8:02 PM Lennart Poettering > wrote: >> >> On Mi, 06.12.23 18:28, Renjaya Raga Zenta (ragaze...@gmail.com) wrote: >> >> > Hi, >> > >> > I am exploring OS image building with mkosi. It works great until I add TPM >> > 2.0 in qemu. >> > >> > I found that the systemd-pcrphase-initrd.service failed. There are 3 >> > pcrphase service: >> > >> > 1. systemd-pcrphase-initrd.service (failed) >> > 2. systemd-pcrphase.service (ok) >> > 3. systemd-pcrphase-sysinit.service (ok) >> >> So the latter two run from the host fs, the first one from the initrd fs. >> >> > Related journal log: >> > systemd[1]: Failed to start systemd-pcrphase-initrd.service - TPM2 PCR >> > Barrier (initrd). >> > ... >> > systemd-pcrphase[130]: Failed to load TPM2 libraries: Operation not >> > supported >> > ... >> >> It appears you are lacking the tpm2-tss libraries in your initrd image. >> >> Lennart >> >> -- >> Lennart Poettering, Berlin > > > > -- > Renjaya Raga Zenta > Mobile: > +62 811 572 4400
Re: [systemd-devel] USB installer for mkosi
Unfortunately there's no ready made answer yet here. We're busy designing and implementing a solution for these problems. https://github.com/systemd/systemd/pull/27792 has more details. Cheers, Daan On Fri, 18 Aug 2023, 19:44 Nils Kattenbeck, wrote: > Hi, > > currently I am building a minimalistic Linux image using mkosi which > should be installed on bare-metal hardware. > For the installation I am trying to create a USB-stick installer which > simply installs the resulting image on the hardware. > > First and foremost: > Does someone maybe know of an existing tool which generates such a USB > installer? > For now I have found the installer script[1] from Yocto, and FAI > (Fully automatic installation)[2]. > I would like to avoid using Yocto and the script seems to also perform > partitioning etc. which I do not need as mkosi already generates a > ready-to-use raw disk image with partitions set up. > FAI on the other hand seems to focus on network installs and prefers > to build its own images instead of using an arbitrary .raw/ISOs. > > So I fear that I will have to write my own installer... > I do not require fancy GUI shenanigans; a simple CLI application > prompting for the destination disk should suffice. > > Based on my understanding the primary steps are `cp /dev/usb-stick > /dev/target-disk` (or dd for the old fashioned), followed by a `parted > --script --fix /dev/target-disk print` to resolve GPT warnings due to > the header not being at the end when the disk is larger than the USB > stick. > Is it possible to replace the second step with `systemd-parted`. > Especially given that mkosi v15 now uses it for itself, this would > likely be a lot cleaner than invoking parted. > > The major problem I am facing with that approach is how do I know > whether I am booting from a USB stick or already from the final disk > drive. > One technique which comes to mind would be to create two images, one > of which will be placed into the mkosi.extra/ directory of the other. > This way I could have one auto-start the install script whereas the > other image would be completely free of that logic. > Am I missing a more obvious way to perform this? > > Any help would be greatly appreciated! > Kind regard, Nils > > [1] > https://github.com/yoctoproject/poky/blob/13734bb520732882a95da7ee6efe1e5b98568acc/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb > [2] https://fai-project.org/ >
Re: [systemd-devel] systemd enables custom service units on firstboot
Disabling manually will still get overridden by preset on first boot.
Debian does not ship 99-disable.preset because deb-systemd-helper relies on
systemctl preset to enable services on install. Shipping that file would
break backwards compat because no services would be enabled anymore.
If I were you I would ship 99-disable.preset and add 85-mydevice.preset
enabling only the services you want to be enabled.
Cheers,
Daan
On Sat, 29 Apr 2023, 17:47 Martin Petzold, wrote:
> Dear Daan,
> Am 29.04.23 um 17:43 schrieb Daan De Meyer:
>
> Systemd does a preset on first boot when there's no machine ID yet. If no
> preset from a preset file applies, the default is to enable it. Since
> debian does not ship a 99-disable.preset with disable * in it, all services
> are enabled on firstboot on Debian.
>
> What would you then suggest:
>
> a. Disable every single service unit after copy to the /lib/systemd/system
> location manually?
> b. Add a 99-disable.preset file with 'disable *'? (I wonder why Debian
> does not have it and if it then may brake something)
>
> Thanks,
>
> Martin
>
>
> On Sat, 29 Apr 2023, 17:27 Martin Petzold,
> wrote:
>
>> Dear Paul,
>>
>> Am 29.04.23 um 17:13 schrieb Paul Menzel:
>> > Dear Martin,
>> >
>> >
>> > Am 29.04.23 um 16:12 schrieb Martin Petzold:
>> >
>> >> we are building our OS with debootstrap (Debian bullseye). Our image
>> >> shall be flashed on embedded devices. In order to get a unique
>> >> machine-id we removed '/etc/machine-id' as instructed in [1] and also
>> >> removed '/var/lib/dbus/machine-id' as instructed in [2]) from the
>> >> golden image.
>> >>
>> >> After we flash the image and boot it, new machine-ids are created and
>> >> identical.
>> >>
>> >> However, now we realized that some of our systemd service units added
>> >> to '/lib/systemd/system' are enabled and starting on boot. We did not
>> >> enable them, we just copied them to that location at the end of our
>> >> rootfs build. They are just there to be used in some special test
>> cases.
>> >>
>> >> We already checked '/lib/systemd/system-preset/*'. But there is only
>> >> a single file '90-systemd.preset' and there is no rule which matches
>> >> our service units.
>> >>
>> >> 1. Why are our service units placed in '/lib/systemd/system' enabled?
>> > Sorry, you provide not enough information.
>> >
>> > Please provide an example `systemctl status X` and `systemctl cat X`
>> > for service X, that is started but does not. Does that happen with all
>> > services you add?
>> =
>>
>> tavla@tavla:~$ sudo systemctl status tavla-test
>>
>> × tavla-test.service - TAVLA Platform OS Tester Service
>> Loaded: loaded (/lib/systemd/system/tavla-test.service; enabled;
>> preset: enabled)
>> Active: failed (Result: signal) since Sat 2023-04-29 15:52:12
>> CEST; 17min ago
>> Process: 388 ExecStart=/opt/tavla/bin/test (code=killed, signal=HUP)
>> Main PID: 388 (code=killed, signal=HUP)
>> CPU: 118ms
>>
>> Apr 29 15:52:12 tavla systemd[1]: Starting tavla-test.service - TAVLA
>> Platform OS Tester Service...
>> Apr 29 15:52:12 tavla systemd[1]: tavla-test.service: Main process
>> exited, code=killed, status=1/HUP
>> Apr 29 15:52:12 tavla systemd[1]: tavla-test.service: Failed with result
>> 'signal'.
>> Apr 29 15:52:12 tavla systemd[1]: Failed to start tavla-test.service -
>> TAVLA Platform OS Tester Service.
>>
>> =
>>
>> tavla-test.service is 'enabled' (and started), but I never enabled it.
>> It was enabled after I removed machine-id and did a reboot. Before that,
>> it was disabled. The service unit
>> ('/lib/systemd/system/tavla-test.service') was copied to this location
>> during image build after debootstrap and apt installation of systemd.
>>
>> Here is the only preset ('90-systemd.preset'):
>>
>> =
>>
>> enable remote-fs.target
>> enable remote-cryptsetup.target
>> enable machines.target
>>
>> enable getty@.service
>> enable systemd-timesyncd.service
>> enable systemd-networkd.service
>> enable systemd-network-generator.service
>> enable systemd-resolved.service
>> enable systemd-homed.service
>> enable systemd-userdbd.socket
>> enable systemd-pstore.service
>> enable systemd-boot-update.ser
Re: [systemd-devel] systemd enables custom service units on firstboot
Systemd does a preset on first boot when there's no machine ID yet. If no
preset from a preset file applies, the default is to enable it. Since
debian does not ship a 99-disable.preset with disable * in it, all services
are enabled on firstboot on Debian.
Cheers,
Daan
On Sat, 29 Apr 2023, 17:27 Martin Petzold, wrote:
> Dear Paul,
>
> Am 29.04.23 um 17:13 schrieb Paul Menzel:
> > Dear Martin,
> >
> >
> > Am 29.04.23 um 16:12 schrieb Martin Petzold:
> >
> >> we are building our OS with debootstrap (Debian bullseye). Our image
> >> shall be flashed on embedded devices. In order to get a unique
> >> machine-id we removed '/etc/machine-id' as instructed in [1] and also
> >> removed '/var/lib/dbus/machine-id' as instructed in [2]) from the
> >> golden image.
> >>
> >> After we flash the image and boot it, new machine-ids are created and
> >> identical.
> >>
> >> However, now we realized that some of our systemd service units added
> >> to '/lib/systemd/system' are enabled and starting on boot. We did not
> >> enable them, we just copied them to that location at the end of our
> >> rootfs build. They are just there to be used in some special test cases.
> >>
> >> We already checked '/lib/systemd/system-preset/*'. But there is only
> >> a single file '90-systemd.preset' and there is no rule which matches
> >> our service units.
> >>
> >> 1. Why are our service units placed in '/lib/systemd/system' enabled?
> > Sorry, you provide not enough information.
> >
> > Please provide an example `systemctl status X` and `systemctl cat X`
> > for service X, that is started but does not. Does that happen with all
> > services you add?
> =
>
> tavla@tavla:~$ sudo systemctl status tavla-test
>
> × tavla-test.service - TAVLA Platform OS Tester Service
> Loaded: loaded (/lib/systemd/system/tavla-test.service; enabled;
> preset: enabled)
> Active: failed (Result: signal) since Sat 2023-04-29 15:52:12
> CEST; 17min ago
> Process: 388 ExecStart=/opt/tavla/bin/test (code=killed, signal=HUP)
> Main PID: 388 (code=killed, signal=HUP)
> CPU: 118ms
>
> Apr 29 15:52:12 tavla systemd[1]: Starting tavla-test.service - TAVLA
> Platform OS Tester Service...
> Apr 29 15:52:12 tavla systemd[1]: tavla-test.service: Main process
> exited, code=killed, status=1/HUP
> Apr 29 15:52:12 tavla systemd[1]: tavla-test.service: Failed with result
> 'signal'.
> Apr 29 15:52:12 tavla systemd[1]: Failed to start tavla-test.service -
> TAVLA Platform OS Tester Service.
>
> =
>
> tavla-test.service is 'enabled' (and started), but I never enabled it.
> It was enabled after I removed machine-id and did a reboot. Before that,
> it was disabled. The service unit
> ('/lib/systemd/system/tavla-test.service') was copied to this location
> during image build after debootstrap and apt installation of systemd.
>
> Here is the only preset ('90-systemd.preset'):
>
> =
>
> enable remote-fs.target
> enable remote-cryptsetup.target
> enable machines.target
>
> enable getty@.service
> enable systemd-timesyncd.service
> enable systemd-networkd.service
> enable systemd-network-generator.service
> enable systemd-resolved.service
> enable systemd-homed.service
> enable systemd-userdbd.socket
> enable systemd-pstore.service
> enable systemd-boot-update.service
>
> disable console-getty.service
> disable debug-shell.service
>
> disable halt.target
> disable kexec.target
> disable poweroff.target
> enable reboot.target
> disable rescue.target
> disable exit.target
>
> disable systemd-networkd-wait-online.service
> disable systemd-time-wait-sync.service
> disable systemd-boot-check-no-failures.service
> disable proc-sys-fs-binfmt_misc.mount
>
> disable syslog.socket
>
> disable systemd-journal-gatewayd.*
> disable systemd-journal-remote.*
> disable systemd-journal-upload.*
>
> =
>
> >
> >> Platform:
> >>
> >> systemd 252.5-2~bpo11+1 (from bullseye-backports)
> >> systemd-resolved and systemd-networkd with iwd (all from
> >> bullseye-backports)
> >> Custom Debian bullseye (with some packages from bullseye-backports)
> >> Custom Kernel 5.10
> >> U-Boot
> >>
> >> [1] https://systemd.io/BUILDING_IMAGES/
> >> [2] https://wiki.debian.org/MachineId
>
> Best regards,
>
> Martin
>
>
Re: [systemd-devel] mkosi dnf install packages failed
See the hacking guide, we depend on very latest mkosi from git. On Fri, 17 Mar 2023, 22:55 William Roberts, wrote: > I am on Fedora 37, I did a dnf up and rebooted to make sure that's not > the issue. > > With the mkosi from the pkg manager, I am getting: > mkosi > mkosi: error: unrecognized arguments: > --kernel-command-line-extra=systemd.crash_shell > systemd.log_level=debug > udev.log_level=info > systemd.journald.forward_to_console > systemd.journald.max_level_console=warning > systemd.mask=auditd > > Which reports as mkosi version 14 > mkosi --version > mkosi 14 > > I grabbed the current main and installed it > python3 -m pip install --user git+https://github.com/systemd/mkosi.git > > And when I run the mkosi command, I ensure its picking up the right one: > sudo -E $(which mkosi) > > And it seems to be building along, but then it gets to a point where > the packages are > being verified with dnf (see below). I am not really sure how to proceed. > > Thanks for any help. > Bill > > > xfsprogs-6.1.0-1.fc37.x86_64 > xkeyboard-config-2.36-3.fc37.noarch > xxhash-libs-0.8.1-3.fc37.x86_64 > xz-5.4.1-1.fc37.x86_64 > xz-libs-5.4.1-1.fc37.x86_64 > zchunk-libs-1.3.0-1.fc37.x86_64 > zlib-1.2.12-5.fc37.x86_64 > zsh-5.9-2.fc37.x86_64 > Failed: > NetworkManager-1:1.40.10-1.fc37.x86_64 > ca-certificates-2023.2.60-1.0.fc37.noarch dbus-broker-33-1.fc37.x86_64 > dhcp-server-12:4.4.3-4.P1.fc37.x86_64 dnsmasq-2.89-1.fc37.x86_64 > gdb-13.1-1.fc37.x86_64 groff-base-1.22.4-10.fc37.x86_64 > kexec-tools-2.0.25-1.fc37.x86_64 > libutempter-1.2.1-7.fc37.x86_64 polkit-121-4.fc37.x86_64 > rpm-4.18.0-1.fc37.x86_64 tpm2-tss-3.2.2-1.fc37.x86_64 > > Error: Transaction failed > ‣ Error: "dnf -y > --config=/home/test/systemd2/.mkosi.tmp5lla7668/dnf.conf --best > --allowerasing --releasever=37 > --installroot=/home/test/systemd2/.mkosi.tmp5lla7668/root > --setopt=keepcache=1 --setopt=install_weak_deps=0 > '--setopt=cachedir=/home/test/systemd2/mkosi.cache/fedora~37' > --setopt=reposdir= > --setopt=varsdir=/home/test/systemd2/.mkosi.tmp5lla7668/vars > --noplugins --nodocs install acl alsa-lib bash-completion btrfs-progs > compsize coreutils cryptsetup dhcp-server diffutils dnf dnsmasq > dosfstools dracut dracut-config-generic e2fsprogs f2fs-tools findutils > fuse gcc gdb glib2 glibc-minimal-langpack gnutls grep iproute > iproute-tc kbd kernel-core kernel-modules kexec-tools kmod less > libasan libbpf libcap-ng libcap-ng-utils libfido2 libgcrypt > libmicrohttpd libmnl libubsan libxcrypt libxkbcommon mtools nano > netcat nftables numactl-libs openssl pam passwd polkit popt procps-ng > python3 'python3dist(pefile)' qrencode quota rpm sed strace systemd > tpm2-tss tree util-linux util-linux valgrind vim-common > wireguard-tools xfsprogs zsh '(systemd-networkd if systemd)' > '(systemd-udev if systemd)'" returned non-zero exit code 1. >
Re: [systemd-devel] issues with systemd-cryptsetup@.service after in 251-rc3
I'd also recommend opening an issue on the upstream issue tracker (https://github.com/systemd/systemd/issues). It'd be great if you could include a full journal (just zip up /var/log/journal) and the contents of systemd-cryptsetup@myluksdev.service if possible to help with debugging. Cheers, Daan On Thu, 19 May 2022 at 08:05, Paul Menzel wrote: > > Dear Dusty, > > > 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: > > > Kind regards, > > Paul > > > > [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
Re: [systemd-devel] mkosi question: third party repos + dnf modules
Hi, --repositories in mkosi is currently a bit limited. For Fedora and CentOS, we only support passing names of existing repositories that should be enabled. https://github.com/systemd/mkosi/issues/536 reported a similar problem. We should definitely make this work better than it does now but it's going to require a bit of thinking on how to properly support this in a way that works for all major supported distros. For now, I think postinst is the best solution. Cheers, Daan On Mon, 7 Dec 2020 at 10:28, Colin Guthrie wrote: > > Hiya, > > Trying to create some CentOS 8 images with mkosi 8 > > Is it possible to use the --repositories argument to mkosi to enable a > third party repository? If so can you tell me the secret syntax? > > I've tried: > > --repositories=https:///mirrorlist > --repositories=https:///directlink > > both say: unknown repo > > > I've tried copying in the appropriate *.repo files via > mkosi.skeleton/etc/yum.repos.d/*.repo and then referring to the repo by > name rather than URL and it doesn't work either (also tried full path > within container and file:// prefixed path) with the same unknown repo > error. > > > I know I could do this with a postinst script but I feel like this > should be possible via the --repositories argument! > > (NB, I'm actually using Repositories= in the [Distribution] section of > an mkosi.default file rather than the command line directly but this > /shouldn't/ make a difference!] > > The next question is: can we setup dnf modules as part of the initial > install? If not, then I'll likely have to go down the postinst route > anyway in this case, but the above is still interesting for e.g. custom > COPR repos etc. > > Cheers > > Col > > ___ > 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] Shut down system after all sshd instances terminate
That works! Thanks so much for the quick response.
I still feel it's a bit unintuitive though. I did find multiple open
issues asking for inhibitors that work with root as well. I think that
would be necessary for an intuitive solution.
Ideally, the following unit file would work:
```
[Unit]
Description=SSH Server for {args.devserver_name} devserver
After=network.target
After=exit.target
[Service]
ExecStart=/usr/sbin/sshd -i
StandardInput=socket
SuccessAction=exit
FailureAction=exit
Inhibit=exit:delay
InhibitDelaySec=infinite
```
This would tell systemd to start a normal exit when the first instance
exits. The Inhibit options tell systemd to delay exit infinitely if
any instance is still running.
For now, your solution is a great alternative.
Daan
On Sun, 23 Aug 2020 at 16:13, Benjamin Berg wrote:
>
> Hi,
>
> you can use Wants= to pull in another service, and then use
> StopWhenUnneeded= to make that shutdown after the last sshd@.service
> disappears.
>
> So, I guess something like the below:
>
> sshd@.service drop-in:
> ```
> [Unit]
> Wants=sshd-running.service
> ```
>
> sshd-running.service
> ```
> [Unit]
> StopWhenUnneeded=true
>
> [Service]
> Type=oneshot
> RemainAfterExit=yes
>
> # Not sure if SuccessAction works
> # probably does but you might need a dummy ExecStart=/sbin/true then
> ExecStop=systemctl poweroff
> #SuccessAction=exit
> ```
>
> Benjamin
>
> On Sun, 2020-08-23 at 16:02 +0100, Daan De Meyer wrote:
> > Nvm, that wouldn't work at all because inhibitor locks are ignored if
> > the user is privileged enough.
> >
> > So getting the system to shut down after an sshd instance exits is
> > easy enough with SuccessAction. Waiting for all sshd instances to
> > finish before shutting down turns out to be extremely hard. I've been
> > trying out stuff for multiple hours now and haven't come even close.
> > There definitely seems to be at least a documentation issue here so
> > if
> > there's a solution I intend to make a PR that clarifies this
> > somewhere
> > in the official documentation.
> >
> > My last (failed) attempt is this (sshd@.service) :
> >
> > ```
> > [Unit]
> > Description=SSH Server for {args.devserver_name} devserver
> > After=network.target
> > After=exit.target
> >
> > [Service]
> > ExecStart=/usr/sbin/sshd -i
> > KillMode=none
> > TimeoutStopSec=infinity
> > StandardInput=socket
> > SuccessAction=exit
> > FailureAction=exit
> > ```
> >
> > When an ssh connection comes in, an instance of this template is
> > started to handle the connection. Now, what I want to achieve is that
> > when all instances of this sshd template exit after at least one
> > instance has started, the system shuts down.
> >
> > Daan
> >
> > On Sun, 23 Aug 2020 at 14:47, Daan De Meyer > > wrote:
> > > Hi,
> > >
> > > After following
> > > http://0pointer.de/blog/projects/socket-activated-containers.html
> > > which details how to set up a socket activated container, I'm
> > > looking
> > > into ways to have the container automatically shut down when the
> > > last
> > > ssh connection terminates.
> > >
> > > My idea was to have each sshd instance take an inhibitor lock (the
> > > blocking kind) that prevents poweroff and make each sshd instance
> > > pull
> > > in poweroff.target. The problem is that the inhibitor documentation
> > > mentions that poweroff operations will fail if a blocking inhibitor
> > > lock is taken. For this to work, I need poweroff.target to wait
> > > indefinitely until all locks are released. Is this possible at the
> > > moment?
> > >
> > > Any other suggestions on how to achieve this are appreciated as
> > > well.
> > >
> > > Cheers,
> > >
> > > Daan
> > ___
> > 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] Shut down system after all sshd instances terminate
Nvm, that wouldn't work at all because inhibitor locks are ignored if
the user is privileged enough.
So getting the system to shut down after an sshd instance exits is
easy enough with SuccessAction. Waiting for all sshd instances to
finish before shutting down turns out to be extremely hard. I've been
trying out stuff for multiple hours now and haven't come even close.
There definitely seems to be at least a documentation issue here so if
there's a solution I intend to make a PR that clarifies this somewhere
in the official documentation.
My last (failed) attempt is this (sshd@.service) :
```
[Unit]
Description=SSH Server for {args.devserver_name} devserver
After=network.target
After=exit.target
[Service]
ExecStart=/usr/sbin/sshd -i
KillMode=none
TimeoutStopSec=infinity
StandardInput=socket
SuccessAction=exit
FailureAction=exit
```
When an ssh connection comes in, an instance of this template is
started to handle the connection. Now, what I want to achieve is that
when all instances of this sshd template exit after at least one
instance has started, the system shuts down.
Daan
On Sun, 23 Aug 2020 at 14:47, Daan De Meyer wrote:
>
> Hi,
>
> After following
> http://0pointer.de/blog/projects/socket-activated-containers.html
> which details how to set up a socket activated container, I'm looking
> into ways to have the container automatically shut down when the last
> ssh connection terminates.
>
> My idea was to have each sshd instance take an inhibitor lock (the
> blocking kind) that prevents poweroff and make each sshd instance pull
> in poweroff.target. The problem is that the inhibitor documentation
> mentions that poweroff operations will fail if a blocking inhibitor
> lock is taken. For this to work, I need poweroff.target to wait
> indefinitely until all locks are released. Is this possible at the
> moment?
>
> Any other suggestions on how to achieve this are appreciated as well.
>
> Cheers,
>
> Daan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Shut down system after all sshd instances terminate
Hi, After following http://0pointer.de/blog/projects/socket-activated-containers.html which details how to set up a socket activated container, I'm looking into ways to have the container automatically shut down when the last ssh connection terminates. My idea was to have each sshd instance take an inhibitor lock (the blocking kind) that prevents poweroff and make each sshd instance pull in poweroff.target. The problem is that the inhibitor documentation mentions that poweroff operations will fail if a blocking inhibitor lock is taken. For this to work, I need poweroff.target to wait indefinitely until all locks are released. Is this possible at the moment? Any other suggestions on how to achieve this are appreciated as well. Cheers, Daan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
> Well, --color means you request color no matter what, so this is not surprising. I actually only got color because TERM was set to xterm-256color. ls won't output color if TERM is set to vt220. It checks against a hardcoded list of terminals to determine whether it'll output colors or not. See https://github.com/coreutils/coreutils/blob/6a3d2883fed853ee01079477020091068074e12d/src/dircolors.hin > Again, I'd be happy to switch to a different default for serial > terminals if we can find a reasonable one that is available widely in > termcap, that does color, and is a subset of both TERM=linux and > TERM=xterm. So the vt220 was the first of the vt200 series and was a black and white terminal. The vt241 was the model in that series that added colors. Problem is that the vt241 is not in my terminfo database. The other problem is that vt241 is not actually in ls's list of terminals that it should output colors for so using that one is probably not a good idea. What would work is vt100 since for some weird reason that one is in ls's list of terminals with colors even though https://invisible-island.net/ncurses/ncurses.faq.html#vt100_color explicitly says the vt100 does not support colors. Switching to vt100 would break pageup/pagedown however so that's not really an option either. I didn't find any other alternatives that seemed viable. I suppose I could make a coreutils PR that adds vt220 to the list of terminals that support colors. vt100 is already in there and it doesn't support colors so who knows maybe they'll add vt220 as well for the pragmatic reason that systemd can't use anything else but it would still be nice to have colors out of the box. I don't think that's likely to be accepted though and it only fixes ls and not programs like ncurses which adhere to whatever's in the terminfo database. For now, the pragmatic solution for my use case (mkosi test VMs that only I will ever use) is to simply make it easy to override TERM in the VM to whatever TERM is in my host terminal via mkosi. Daan On Wed, 15 Jul 2020 at 17:09, Lennart Poettering wrote: > On Di, 14.07.20 22:15, Daan De Meyer (daan.j.deme...@gmail.com) wrote: > > > > About your other comments, systemd sits in user space and can query > > (depend > > > upon) terminfo. Then, it should be able to support "whatever" terminfo > > has > > > defined which could include custom terminals by the way that an end > > user has > > > added. And while all of that sounds incredibly ancient/old, I was on a > > project > > > post 2000 that had to do exactly that (of course, even that might sound > > too old). > > > > Interestingly enough, systemd's colors work even when TERM is set to > vt220, > > probably because it uses ansi escape codes regardless of the TERM > setting. > > I think there's probably lots of applications doing this except for ls in > > coreutils which has an explicit list of terminals with color support > > encoded in the dircolors configuration file. If TERM isn't one of those, > > you don't get colors. There's probably others that do this as well. I > don't > > think changing the default in systemd is a good idea since it might break > > other stuff. I'm going to submit a mkosi PR instead that adds an option > > that overrides serial-getty@ttyS0 with whatever terminal the user wants. > > Colors won't work out of the box but at least it shouldn't be too hard to > > find out how to get them to work when using mkosi. > > Again, I'd be happy to switch to a different default for serial > terminals if we can find a reasonable one that is available widely in > termcap, that does color, and is a subset of both TERM=linux and > TERM=xterm. > > Lennart > > -- > Lennart Poettering, Berlin > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
> About your other comments, systemd sits in user space and can query (depend > upon) terminfo. Then, it should be able to support "whatever" terminfo has > defined which could include custom terminals by the way that an end user has > added. And while all of that sounds incredibly ancient/old, I was on a project > post 2000 that had to do exactly that (of course, even that might sound too old). Interestingly enough, systemd's colors work even when TERM is set to vt220, probably because it uses ansi escape codes regardless of the TERM setting. I think there's probably lots of applications doing this except for ls in coreutils which has an explicit list of terminals with color support encoded in the dircolors configuration file. If TERM isn't one of those, you don't get colors. There's probably others that do this as well. I don't think changing the default in systemd is a good idea since it might break other stuff. I'm going to submit a mkosi PR instead that adds an option that overrides serial-getty@ttyS0 with whatever terminal the user wants. Colors won't work out of the box but at least it shouldn't be too hard to find out how to get them to work when using mkosi. Thanks for all the info as well. It's always fun to read how stuff was done back in the early days. Daan On Tue, 14 Jul 2020 at 21:04, Christopher Cox wrote: > On 7/14/20 1:48 PM, Daan De Meyer wrote: > > I just tried vt241 and didn't get colorized output in konsole. I looked > around a > > bit and it doesn't really seem supported at all by terminal emulators > (or at > > least none that I found). I also tried TERM=xterm-256color with 8 > different > > terminal emulators and got colors with all of them. My workflow is > simply "mkosi > > qemu -nographic" (with a modified mkosi that adds console=ttyS0 and > overrides > > TERM for serial-getty@ttyS0 in the vm)." That connects my terminal > emulator to > > the serial console of the vm. I then execute "ls -l --color /" in the vm > and get > > colored output every time in whatever terminal emulator that I try. > > > > I'm probably missing something but I'm wondering what an example > terminal > > emulator would be where xterm-256color would not work at all (even st > worked > > perfectly and that is supposed to be pretty barebones afaik). Or is it > just that > > color is a commonly supported subset of xterm and stuff breaks down with > other > > escape codes instead? Or maybe qemu is doing some kind of translation > that > > magically makes every TERM setting work in whatever terminal emulator I > try? > > Apologies if this seems ignorant, I have no experience at all with this > domain. > > So, some info (not necessarily direction). Old guys like to talk... > > So, speaking of things of old, but not ancient old, when handling server > equipment via serial, you normally do three things. You route the BIOS > (legacy) > out the serial port, you send the kernel boot messages out the serial port > and > you establish a getty for login on the serial port. > > Just being honest, the "server world" decided everything was Microsoft > Hyperterminal (up to Windows XP, what many considered to be "ansi", 80x25) > during the PC revolution. > > So.. Windows doesn't come with Hyperterminal anymore, which makes sense > since > PCs in general don't have serial ports (apart from USB-serial dongles). > > So, can you, or should you adopt a serial console solution (ansi, 80x25)? > IMHO, > this is still interesting. Especially in the Linux world. Consider that > network equipment still speaks serial for console, the concept (still, > even > though this in a old concept) of using, for example, ssh to serial console > controllers for full out of band access might still be appealing. > > Why? Well, for many reasons. Cabling is much less (that is, less dense) > as you > can use flat velum for quite some distance for serial. Since you're > having to > somehow deal with network devices anyway, by have all done serially, you > have > "one stop" shopping for out of band (more on this in a bit) console access. > > Bonus, no high cost of licensing, for example, iLO or iDrac ent. But > noting > that you don't get virtual media with a serial console head solution > either. > > But still, if running remote facilities and you need true out of band, and > by > that I mean the ability to reconfigure everything, including the network, > it > could be just the thing you need. > > But ssh? Network reconfigure? That's not going to work. Often times > those same > ssh to serial console devices have additional serial support usually with > a > option of
Re: [systemd-devel] vt220 default for serial console still relevant?
I just tried vt241 and didn't get colorized output in konsole. I looked around a bit and it doesn't really seem supported at all by terminal emulators (or at least none that I found). I also tried TERM=xterm-256color with 8 different terminal emulators and got colors with all of them. My workflow is simply "mkosi qemu -nographic" (with a modified mkosi that adds console=ttyS0 and overrides TERM for serial-getty@ttyS0 in the vm)." That connects my terminal emulator to the serial console of the vm. I then execute "ls -l --color /" in the vm and get colored output every time in whatever terminal emulator that I try. I'm probably missing something but I'm wondering what an example terminal emulator would be where xterm-256color would not work at all (even st worked perfectly and that is supposed to be pretty barebones afaik). Or is it just that color is a commonly supported subset of xterm and stuff breaks down with other escape codes instead? Or maybe qemu is doing some kind of translation that magically makes every TERM setting work in whatever terminal emulator I try? Apologies if this seems ignorant, I have no experience at all with this domain. Daan On Tue, 14 Jul 2020 at 18:22, Christopher Cox wrote: > On 7/14/20 3:19 AM, Lennart Poettering wrote: > > On Mo, 13.07.20 18:16, Christopher Cox (c...@endlessnow.com) wrote: > > > >>> No vt220 does not support colour. I used to work on one and it is > >>> monochrome hardware. > >>> Xterm and konsole support extensions beyond vt220 that add in the > colour support. > >> > >> Not sure how much (offtopic) history we want to get into. I used the > VT240 > >> in my college graphics class. The VT241 was the color variant. > >> > >> See: http://terminals-wiki.org/wiki/index.php/DEC_VT240 > >> > >> I still meet programmers what hard code ansi sequences rather than > querying > >> termcap/terminfo. You know what they say about those who "assume". > > > > Hmm, if vt241 is a bettre featured terminal type, and both xterm and > > the Linux console a superset of it, and the terminal widely available > > in termcaps and stuff we can certainly change our default TERM to be > > vt241. > > > > Daan, if this all is the case, could you prep a PR? > > I would think shooting for something low is actually good. Let the > individual > configure for something "better". > > I'm not sure I'm ready to say monochrome is obsolete. There can be beauty > in > simplicity and function. My preference, aim low, and allow easy > configuration > upward. You could take the opposite stance of course, it's just that it > could > cause some frustration. > > Just my opinion though. I'm old and I think about a lot of things like > terminals, "proxies" and callback modems... things of value, but most do > not > understand or care about anymore. > > > ___ > 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] vt220 default for serial console still relevant?
Nevermind that, I just forgot to remove my override file that set TERM=linux for serial-getty@ttyS0. Daan On Sat, 11 Jul 2020 at 20:31, Daan De Meyer wrote: > > TERM=linux means Linux console, but that's just too much, as it not > > only implies a multitude of ESC sequences specific to the Linux > > console, but also indicates that certain ioctls might work. In our own > > code we also bind certain behaviour to TERM=linux, as indicator if we > > are on the Linux console. > > > > I am not aware of any widely-supported TERM value that would be a > > reasonable subset of all currently used terminals and does color. > > I did some more research and it turns out VT220 does support colors. My > terminal emulator (Konsole) just doesn't seem to support it. I installed > xterm (which explicitly advertises support for VT220 escape codes) and got > colored output as expected. I guess this means it's up to Konsole to > support more of VT220 if I want this to work seamlessly (or I switch > terminals to xterm). > > Thanks for the extra info and context. > > Daan > > On Sat, 11 Jul 2020 at 20:04, Lennart Poettering > wrote: > >> On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com) wrote: >> >> > Hi, >> > >> > I was playing around with mkosi's qemu support, more specifically adding >> > the -nographic option to have the virtual machine output in my terminal >> > instead of a separate window. After figuring out that I had to add >> > console=ttyS0 to mkosi's kernel command line, I got the output from the >> vm >> > in my terminal as expected. However, because systemd defaults to >> TERM=vt220 >> > for serial consoles, the output is not colorized. I searched around a >> bit >> > and found that this is done for compatibility reasons. Will there ever >> be a >> > point where we can switch the default to something that supports colors >> > (like TERM=linux)? >> >> TERM=linux means Linux console, but that's just too much, as it not >> only implies a multitude of ESC sequences specific to the Linux >> console, but also indicates that certain ioctls might work. In our own >> code we also bind certain behaviour to TERM=linux, as indicator if we >> are on the Linux console. >> >> I am not aware of any widely-supported TERM value that would be a >> reasonable subset of all currently used terminals and does color. >> >> > I managed to get around the problem by overriding serial-getty@ttyS0 >> and >> > setting Environment=TERM=linux explicitly but it's a bit of a pain and >> has >> > to be added to every rootfs that wants to support colored output on its >> > serial console. >> >> Unfortunately we can't guess the right terminal, we cannot propagate >> TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or >> from a Linux console, hence the best thing we can do is stick to a >> reasonably powerful subset that is likely going to exist everywhere, >> and that's vt220 right now, as noone had a better suggestion so far... >> >> Lennart >> >> -- >> Lennart Poettering, Berlin >> > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
> TERM=linux means Linux console, but that's just too much, as it not > only implies a multitude of ESC sequences specific to the Linux > console, but also indicates that certain ioctls might work. In our own > code we also bind certain behaviour to TERM=linux, as indicator if we > are on the Linux console. > > I am not aware of any widely-supported TERM value that would be a > reasonable subset of all currently used terminals and does color. I did some more research and it turns out VT220 does support colors. My terminal emulator (Konsole) just doesn't seem to support it. I installed xterm (which explicitly advertises support for VT220 escape codes) and got colored output as expected. I guess this means it's up to Konsole to support more of VT220 if I want this to work seamlessly (or I switch terminals to xterm). Thanks for the extra info and context. Daan On Sat, 11 Jul 2020 at 20:04, Lennart Poettering wrote: > On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com) wrote: > > > Hi, > > > > I was playing around with mkosi's qemu support, more specifically adding > > the -nographic option to have the virtual machine output in my terminal > > instead of a separate window. After figuring out that I had to add > > console=ttyS0 to mkosi's kernel command line, I got the output from the > vm > > in my terminal as expected. However, because systemd defaults to > TERM=vt220 > > for serial consoles, the output is not colorized. I searched around a bit > > and found that this is done for compatibility reasons. Will there ever > be a > > point where we can switch the default to something that supports colors > > (like TERM=linux)? > > TERM=linux means Linux console, but that's just too much, as it not > only implies a multitude of ESC sequences specific to the Linux > console, but also indicates that certain ioctls might work. In our own > code we also bind certain behaviour to TERM=linux, as indicator if we > are on the Linux console. > > I am not aware of any widely-supported TERM value that would be a > reasonable subset of all currently used terminals and does color. > > > I managed to get around the problem by overriding serial-getty@ttyS0 and > > setting Environment=TERM=linux explicitly but it's a bit of a pain and > has > > to be added to every rootfs that wants to support colored output on its > > serial console. > > Unfortunately we can't guess the right terminal, we cannot propagate > TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or > from a Linux console, hence the best thing we can do is stick to a > reasonably powerful subset that is likely going to exist everywhere, > and that's vt220 right now, as noone had a better suggestion so far... > > Lennart > > -- > Lennart Poettering, Berlin > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] vt220 default for serial console still relevant?
Hi, I was playing around with mkosi's qemu support, more specifically adding the -nographic option to have the virtual machine output in my terminal instead of a separate window. After figuring out that I had to add console=ttyS0 to mkosi's kernel command line, I got the output from the vm in my terminal as expected. However, because systemd defaults to TERM=vt220 for serial consoles, the output is not colorized. I searched around a bit and found that this is done for compatibility reasons. Will there ever be a point where we can switch the default to something that supports colors (like TERM=linux)? I managed to get around the problem by overriding serial-getty@ttyS0 and setting Environment=TERM=linux explicitly but it's a bit of a pain and has to be added to every rootfs that wants to support colored output on its serial console. Cheers, Daan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-bus signal callback return value
Hi, I've opened a pull request to clarify the return values of the callbacks and their effect: https://github.com/systemd/systemd/pull/15253. It's not complete yet but the idea is to add answers for all your questions to the docs. Regards, Daan On Tue, 24 Mar 2020 at 21:44, Stanislav Angelovič wrote: > Hi folks, > > Please, what is the difference in sd-bus behavior when my D-Bus signal > callback returns a zero return value versus a positive return value? > > And what's the difference between those return values in D-Bus method > callback, D-Bus async method reply callback, D-Bus property get callback, > and D-Bus property set callback? > > Which shall I return in normal cases? Zero? > > Thanks a lot in advance for your response... Take care & stay healthy, > > Stanislav. > > ___ > 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] Reasoning behind sd_bus_error argument to sd_bus_call?
I completely agree that for errors returned by the service, a D-Bus error
is a lot better. However, from what I understand of sd-bus, any errors
returned by the service are encoded in the reply returned by sd_bus_call
and you use sd_bus_message_is_method_error and sd_bus_message_get_error on
the reply to get the actual service error. Where does that leave the
sd_bus_error argument of sd_bus_call? Is it simply another way to get the
error? It seems to be always be set when a local or remote error occurs,
but it can only contain information that I can get by checking the return
value of the function or by checking whether the reply object passed to
sd_bus_call contains an error.
How I would imagine using sd_bus_call:
r = sd_bus_call(..., reply, ...);
if (r < 0) {
// Local error
}
if (sd_bus_message_is_method_error(reply)) {
const sd_bus_error *error = sd_bus_message_get_error(reply);
// Service error
}
But if this is the intended usage, what's the use of the sd_bus_error
argument of sd_bus_call since the above code already handles both the local
error and the remote service error failure paths?
Daan
On Wed, 18 Mar 2020 at 11:57, Simon McVittie wrote:
> On Tue, 17 Mar 2020 at 20:17:05 +0100, Daan De Meyer wrote:
> > I'm documenting sd_bus_call and its async variant and I was wondering
> about the
> > sd_bus_error output parameter that's passed to it. [...] I don't
> > see immediately see the benefit of the sd_bus_error parameter in a D-Bus
> client
> > since I can simply check the return value instead which seems to contain
> the
> > same information looking at the implementation.
>
> The return value is a single int, which according to systemd conventions
> is probably a negative errno value. That's a lot less information than
> a D-Bus error (systemd sd_bus_error, libdbus DBusError or equivalent):
> D-Bus errors consist of a machine-readable name (namespaced by a reversed
> domain name) and a human-readable message.
>
> For the information about *whether* an error occurred, sure, you get the
> same information, but for information about *which* error occurred and why,
> a sd_bus_error is a lot better.
>
> Let's pretend your D-Bus client is interacting with a D-Bus service that
> resembles systemd-timedated. An errno value can give you, at best,
> something like this (where *** marks the part that came from the service's
> reply):
>
> my-client: Error: Unable to set time zone to America/Gotham:
> ***No such file or directory (errno 2)***
>
> whereas a D-Bus error (sd_bus_error) from a well-implemented service can
> give you something a lot more detailed. For example, after you ispect
> the sd_bus_error, you might find that the error above was either of these:
>
> my-client: Error: Unable to set time zone to America/Gotham:
> ***No time zone file for "America/Gotham" found (tried
> "/usr/share/zoneinfo/America/Gotham",
> "/usr/local/share/zoneinfo/America/Gotham")
> (error code com.example.NotTimedated.Error.NoSuchTimezone)***
>
> my-client: Error: Unable to set time zone to America/Gotham:
> ***No time zone data installed (tried "/usr/share/zoneinfo",
> "/usr/local/share/zoneinfo")
> (error code com.example.NotTimedated.Error.TzdataNotInstalled)***
>
> In this example a programmatic client would also be able
> to respond differently to the distinct machine-readable
> errors com.example.NotTimedated.Error.NoSuchTimezone and
> com.example.NotTimedated.Error.TzdataNotInstalled if it wanted to;
> for example it could respond to the second error by trying to use
> PackageKit to install tzdata, which obviously wouldn't be appropriate
> for the first error.
>
> D-Bus errors were inspired by GLib's GError, which is basically a triple
> { domain: interned string, code: int, message: string }, where the domain
> provides extensible uniqueness, and the code is a member of an enum
> determined by the domain.
>
> smcv
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Reasoning behind sd_bus_error argument to sd_bus_call?
Hi, I'm documenting sd_bus_call and its async variant and I was wondering about the sd_bus_error output parameter that's passed to it. Is it specifically meant for use cases where we're doing a nested D-Bus method call from a service so we have an error object to send back from the initial D-Bus method call? I don't see immediately see the benefit of the sd_bus_error parameter in a D-Bus client since I can simply check the return value instead which seems to contain the same information looking at the implementation. Regards, Daan De Meyer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
