Re: [systemd-devel] openSUSE MicroOS/Tumbleweed with systemd-boot available
Ludwig Nussel wrote: JFYI openSUSE now has a MicroOS (transactional system with read-only /) qcow image¹ suitable for use in qemu that uses systemd-boot. The image is part of the Tumbleweed development process and automatically released (ie potentially daily). It's fully integrated with btrfs snapshots and rollback. As a special gimmick the image automatically encrypts itself on first boot. Optionally the image can also leverage a TPM or FIDO2 key to unlock the volume. Still quite WIP so I wouldn't recommend this for production use. Nevertheless worth trying out to see how a mainstream distro may leverage the technology. The image implements what I talked about at ASG². A more detailed article is available on news.o.o³. Some screenshots in the wiki⁴ and a video⁵ from openQA for the impatient :-) A Tumbleweed image with traditional writable file system will follow soon. That one will be more convenient for development. The Tumbleweed image is now released as well: http://download.opensuse.org/tumbleweed/appliances/openSUSE-Tumbleweed-Minimal-VM.x86_64-kvm-and-xen-sdboot.qcow2 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; HRB 36809 (AG Nürnberg)
[systemd-devel] Build failure with sshconfdir=no
Hello,
There's a build failure with the meson option sshconfdir=no. The error is as
follows:
Running custom install script '/usr/bin/sh -c /usr/bin/ln -frsT --
"${DESTDIR:-}/usr/lib/systemd/ssh_config.d/20-systemd-ssh-proxy.conf"
"${DESTDIR:-}no/20-systemd-ssh-proxy.conf"'
/usr/bin/ln: failed to create symbolic link
'$/systemd-git/pkg/systemd-gitno/20-systemd-ssh-proxy.conf': No such file or
directory
Best,
Daechir
Sent with Proton Mail secure email.
signature.asc
Description: OpenPGP digital signature
Re: [systemd-devel] Activation environment(s)?
At least signals seem to be sent only only once. A process in a login shell can wait for TERM (and two HUPs if on console), wait a bit after this, then safely fork cleanup tasks and exit before KILL comes. On 15/01/2024 13.08, Lennart Poettering wrote: When the goal is to shut down a service/session, then intend to give guarantees that the shut down time is bounded: we first send SIGTERM, and start a timeout. If by that timeout there are still processes left we SIGKILL to put an end to things. If we'd somehow distinguish new/old processes then we couldn't put the boundary on the shutdown process... So no, this does not exist. You can fork if you want, but it won't add time to the time-out. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Activation environment(s)?
On Fr, 12.01.24 18:16, Vladimir Kudrya (vladimir-...@yandex.ru) wrote: > On 08/01/2024 22.26, Simon McVittie wrote: > > It is not possible to unset a variable in the dbus-daemon's activation > > environment, or with `dbus-update-activation-environment`: that's an > > API limitation in the org.freedesktop.DBus interface. I've thought about > > adding an UnsetAndSetActivationEnvironment() that could do this. > > > > It *is* possible to unset a variable in the `systemd --user` > > activation environment, with `systemctl --user unset-environment` or > > the UnsetEnvironment() and UnsetAndSetEnvironment() D-Bus methods on the > > systemd manager. If your distribution is using dbus-broker rather than > > dbus-daemon, and if Mantas was correct to say that dbus-broker does not > > have its own separate activation environment, then that should be enough > > to affect all D-Bus session services. It will also affect all other > > systemd user services. > > Thank you. I now recommend dbus-broker in my session manager's readme > (https://github.com/Vladimir-csp/uwsm), and management of dbus activation > environmentis now conditional on dbus unit true name not being > dbus-broker.service. > > BTW, the whole reason I even decided to interact with dbus is rather > aggressive session termination by systemd. It seems to send signals not only > to existing processes in the session, but even to new ones which were > spawned in response to those signals. This makes it impossible to fork a > systemctl process to stop related user units. > > I solved this by interacting with dbus without spawning new processes, but, > just for info, is there a proper way to fork something that survives for a > bit in a session that is being terminated? With simple tools like `trap > 'something' TERM HUP` in a shell? Or maybe there is some other more native > way to bind a user level unit to a particular session scope? When the goal is to shut down a service/session, then intend to give guarantees that the shut down time is bounded: we first send SIGTERM, and start a timeout. If by that timeout there are still processes left we SIGKILL to put an end to things. If we'd somehow distinguish new/old processes then we couldn't put the boundary on the shutdown process... So no, this does not exist. You can fork if you want, but it won't add time to the time-out. Lennart -- Lennart Poettering, Berlin
