[systemd-devel] systemd prerelease 255-rc4

2023-12-01 Thread systemd tag bot
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the 
tarball here:

https://github.com/systemd/systemd/archive/v255-rc4.tar.gz

NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:

https://github.com/systemd/systemd/issues/new?template=Bug_report.md

Changes since the previous release:

Announcements of Future Feature Removals and Incompatible Changes:

* Support for split-usr (/usr/ mounted separately during late boot,
  instead of being mounted by the initrd before switching to the rootfs)
  and unmerged-usr (parallel directories /bin/ and /usr/bin/, /lib/ and
  /usr/lib/, …) has been removed. For more details, see:
  
https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html

* We intend to remove cgroup v1 support from a systemd release after
  the end of 2023. If you run services that make explicit use of
  cgroup v1 features (i.e. the "legacy hierarchy" with separate
  hierarchies for each controller), please implement compatibility with
  cgroup v2 (i.e. the "unified hierarchy") sooner rather than later.
  Most of Linux userspace has been ported over already.

* Support for System V service scripts is now deprecated and will be
  removed in a future release. Please make sure to update your software
  *now* to include a native systemd unit file instead of a legacy
  System V script to retain compatibility with future systemd releases.

* Support for the SystemdOptions EFI variable is deprecated.
  'bootctl systemd-efi-options' will emit a warning when used. It seems
  that this feature is little-used and it is better to use alternative
  approaches like credentials and confexts. The plan is to drop support
  altogether at a later point, but this might be revisited based on
  user feedback.

* systemd-run's switch --expand-environment= which currently is disabled
  by default when combined with --scope, will be changed in a future
  release to be enabled by default.

* "systemctl switch-root" is now restricted to initrd transitions only.

  Transitions between real systems should be done with
  "systemctl soft-reboot" instead.

* The "ip=off" and "ip=none" kernel command line options interpreted by
  systemd-network-generator will now result in IPv6RA + link-local
  addressing being disabled, too. Previously DHCP was turned off, but
  IPv6RA and IPv6 link-local addressing was left enabled.

* The NAMING_BRIDGE_MULTIFUNCTION_SLOT naming scheme has been deprecated
  and is now disabled.

* SuspendMode=, HibernateState= and HybridSleepState= in the [Sleep]
  section of systemd-sleep.conf are now deprecated and have no effect.
  They did not (and could not) take any value other than the respective
  default. HybridSleepMode= is also deprecated, and will now always use
  the 'suspend' disk mode.

Service Manager:

* The way services are spawned has been overhauled. Previously, a
  process was forked that shared all of the manager's memory (via
  copy-on-write) while doing all the required setup (e.g.: mount
  namespaces, CGroup configuration, etc.) before exec'ing the target
  executable. This was problematic for various reasons: several glibc
  APIs were called that are not supposed to be used after a fork but
  before an exec, copy-on-write meant that if either process (the
  manager or the child) touched a memory page a copy was triggered, and
  also the memory footprint of the child process was that of the
  manager, but with the memory limits of the service. From this version
  onward, the new process is spawned using CLONE_VM and CLONE_VFORK
  semantics via posix_spawn(3), and it immediately execs a new internal
  binary, systemd-executor, that receives the configuration to apply
  via memfd, and sets up the process before exec'ing the target
  executable. The systemd-executor binary is pinned by file descriptor
  by each manager instance (system and users), and the reference is
  updated on daemon-reexec - it is thus important to reexec all running
  manager instances when the systemd-executor and/or libsystemd*
  libraries are updated on the filesystem.

* Most of the internal process tracking is being changed to use PIDFDs
  instead of PIDs when the kernel supports it, to improve robustness
  and reliability.

* A new option SurviveFinalKillSignal= can be used to configure the
  unit to be skipped in the final SIGTERM/SIGKILL spree on shutdown.
 

Re: [systemd-devel] Systemd-nspawn single process

2023-12-01 Thread Lennart Poettering
On Fr, 01.12.23 14:03, Warex61 YTB (thomasdabou...@gmail.com) wrote:

> Hello,
> I would like to use systemd-nspawn to create a container that can launch a
> single process as pid 1 and mount its configuration files. I want the
> container to be as light as possible. Is there any way of creating a
> container using nspawn without using bootstrap ?
>
> For example, using this command, without using a bootstrap
>
> systemd-nspawn -M process -D /etc/systemd/nspawn/process
> /etc/systemd/nspawn/process.nspawn
> I get the following error
>
> Directory /etc/systemd/nspawn/process doesn't look like it has an OS tree.
> Refusing.
> What are the conditions for nspawn to consider an OS tree in
> /etc/systemd/nspawn/process ?

You are using an ancient version of nspawn. Since 2y or so the message
reads:

Directory %s doesn't look like it has an OS tree (/usr/ directory is 
missing). Refusing.

And that's your explanation: you need an /usr/ directory.

Lennart

--
Lennart Poettering, Berlin


[systemd-devel] Systemd-nspawn single process

2023-12-01 Thread Warex61 YTB
Hello,
I would like to use systemd-nspawn to create a container that can launch a
single process as pid 1 and mount its configuration files. I want the
container to be as light as possible. Is there any way of creating a
container using nspawn without using bootstrap ?

For example, using this command, without using a bootstrap

systemd-nspawn -M process -D /etc/systemd/nspawn/process
/etc/systemd/nspawn/process.nspawn
I get the following error

Directory /etc/systemd/nspawn/process doesn't look like it has an OS tree.
Refusing.
What are the conditions for nspawn to consider an OS tree in
/etc/systemd/nspawn/process ?

Thanks.


Re: [systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub

2023-12-01 Thread Luca Boccassi
Why does the kernel need to know all that?

On Fri, 1 Dec 2023, 06:43 VENKAT Nagaraj THOGARU (QUIC), <
quic_thog...@quicinc.com> wrote:

> HI @Luca Boccassi,
>
> Looks like this addons is to append additional cmd-line parameters with
> static data.
> Our requirement is to append additional cmd-line parameters with dynamic
> device specific data like, serial number read from the device during
> runtime.
>
> Thanks & Regards,
> Venkat Thogaru
>
> -Original Message-
> From: Luca Boccassi 
> Sent: Tuesday, November 28, 2023 4:34 PM
> To: VENKAT Nagaraj THOGARU (QUIC) 
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] Fixup-support for kernel command line
> provided from UKI in systemd-stub
>
> On Tue, 28 Nov 2023 at 10:30, VENKAT Nagaraj THOGARU (QUIC) <
> quic_thog...@quicinc.com> wrote:
> >
> > Hi @systemd-devel@lists.freedesktop.org,
> >
> >
> >
> > We have a query on Fixup-support for kernel command line provided from
> UKI in system-stub.
> >
> >
> >
> > Just like we have the Fixup support for DTB provided from UKI in
> systemd-stub[via EFI_DT_FIXUP_PROTOCOL], do we have any similar fixup
> support for Kernel command line provided from UKI ? If not, is there any
> ongoing effort to support this?
> >
> >
> >
> > Our requirement is to dynamically append the additional command line
> parameters to the command line provided from UKI.
>
> Check the addons section:
>
>
> https://www.freedesktop.org/software/systemd/man/latest/systemd-stub.html#Companion%20Files
>