|
|
Subscribe / Log in / New account

Systemd 254 released

Systemd 254 has been released. As usual, there is a long list of changes, including a new list-paths command for systemctl, the ability to send POSIX signals to services, a "soft reboot" feature that restarts user space while leaving the kernel in place, improved support for "confidential virtual machines", and a lot more.

The announcement also notes the support for split-/usr systems will be removed in the next release, and support for version-one control groups and for System V service scripts will be deleted in the near future as well.


From:  systemd tag bot <donotreply-systemd-tag-AT-refi64.com>
To:  systemd-devel-AT-lists.freedesktop.org
Subject:  systemd 254 released
Date:  Fri, 28 Jul 2023 08:28:50 +0000
Message-ID:  <20230728082850.4d04c5c1d94d2b73@refi64.com>
Archive-link:  Article

🎆 A new, official systemd release has just 🎉 been 🎊 tagged 🍾. Please download the tarball here:

        https://github.com/systemd/systemd/archive/v254.tar.gz

Changes since the previous release:

        Announcements of Future Feature Removals and Incompatible Changes:

        * The next release (v255) will remove 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/, …). For more
          details, see:
          https://lists.freedesktop.org/archives/systemd-devel/2022...

        * 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.

        * EnvironmentFile= now treats the line following a comment line
          trailing with escape as a non comment line. For details, see:
          https://github.com/systemd/systemd/issues/27975

        * Behaviour of sandboxing options for the per-user service manager
          units has changed. They now imply PrivateUsers=yes, which means user
          namespaces will be implicitly enabled when a sandboxing option is
          enabled in a user unit. Enabling user namespaces has the drawback
          that system users will no longer be visible (and processes/files will
          appear as owned by 'nobody') in the user unit.

          By definition a sandboxed user unit should run with reduced
          privileges, so impact should be small. This will remove a great
          source of confusion that has been reported by users over the years,
          due to how these options require an extra setting to be manually
          enabled when used in the per-user service manager, which is not
          needed in the system service manager. For more details, see:
          https://lists.freedesktop.org/archives/systemd-devel/2022...

        * 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.

        Security Relevant Changes:

        * pam_systemd will now by default pass the CAP_WAKE_ALARM ambient
          process capability to invoked session processes of regular users on
          local seats (as well as to systemd --user), unless configured
          otherwise via data from JSON user records, or via the PAM module's
          parameter list. This is useful in order allow desktop tools such as
          GNOME's Alarm Clock application to set a timer for
          CLOCK_REALTIME_ALARM that wakes up the system when it elapses. A
          per-user service unit file may thus use AmbientCapability= to pass
          the capability to invoked processes. Note that this capability is
          relatively narrow in focus (in particular compared to other process
          capabilities such as CAP_SYS_ADMIN) and we already — by default —
          permit more impactful operations such as system suspend to local
          users.

        Service Manager:

        * "Startup" memory settings are now supported. Previously IO and CPU
          settings were already supported via StartupCPUWeight= and similar.
          The same logic has been added for the various per-unit memory
          settings StartupMemoryMax= and related.

        * The service manager gained support for enqueuing POSIX signals to
          services that carry an additional integer value, exposing the
          sigqueue() system call. This is accessible via new D-Bus calls
          org.freedesktop.systemd1.Manager.QueueSignalUnit() and
          org.freedesktop.systemd1.Unit.QueueSignal(), as well as in systemctl
          via the new --kill-value= option.

        * systemctl gained a new "list-paths" verb, which shows all currently
          active .path units, similarly to how "systemctl list-timers" shows
          active timers, and "systemctl list-sockets" shows active sockets.

        * systemctl gained a new --when= switch which is honoured by the various
          forms of shutdown (i.e. reboot, kexec, poweroff, halt) and allows
          scheduling these operations by time, similar in fashion to how this
          has been supported by SysV shutdown.

        * If MemoryDenyWriteExecute= is enabled for a service and the kernel
          supports the new PR_SET_MDWE prctl() call, it is used instead of the
          seccomp()-based system call filter to achieve the same effect.

        * A new set of kernel command line options is now understood:
          systemd.tty.term.<name>=, systemd.tty.rows.<name>=,
          systemd.tty.columns.<name>= allow configuring the TTY type and
          dimensions for the tty specified via <name>. When systemd invokes a
          service on a tty (via TTYName=) it will look for these and configure
          the TTY accordingly. This is particularly useful in VM environments
          to propagate host terminal settings into the appropriate TTYs of the
          guest.

        * A new RootEphemeral= setting is now understood in service units. It
          takes a boolean argument. If enabled for services that use RootImage=
          or RootDirectory= an ephemeral copy of the disk image or directory
          tree is made when the service is started. It is removed automatically
          when the service is stopped. That ephemeral copy is made using
          btrfs/xfs reflinks or btrfs snapshots, if available.

        * The service activation logic gained new settings RestartSteps= and
          RestartMaxDelaySec= which allow exponentially-growing restart
          intervals for Restart=.

        * The service activation logic gained a new setting RestartMode= which
          can be set to 'direct' to skip the inactive/failed states when
          restarting, so that dependent units are not notified until the service
          converges to a final (successful or failed) state. For example, this
          means that OnSuccess=/OnFailure= units will not be triggered until the
          service state has converged.

        * PID 1 will now automatically load the virtio_console kernel module
          during early initialization if running in a suitable VM. This is done
          so that early-boot logging can be written to the console if available.

        * Similarly, virtio-vsock support is loaded early in suitable VM
          environments. PID 1 will send sd_notify() notifications via AF_VSOCK
          to the VMM if configured, thus loading this early is beneficial.

        * A new verb "fdstore" has been added to systemd-analyze to show the
          current contents of the file descriptor store of a unit. This is
          backed by a new D-Bus call DumpUnitFileDescriptorStore() provided by
          the service manager.

        * The service manager will now set a new $FDSTORE environment variable
          when invoking processes for services that have the file descriptor
          store enabled.

        * A new service option FileDescriptorStorePreserve= has been added that
          allows tuning the life-cycle of the per-service file descriptor
          store. If set to "yes", the entries in the fd store are retained even
          after the service has been fully stopped.

        * The "systemctl clean" command may now be used to clear the fdstore of
          a service.

        * Unit *.preset files gained a new directive "ignore", in addition to
          the existing "enable" and "disable". As the name suggests, matching
          units are left unchanged, i.e. neither enabled nor disabled.

        * Service units gained a new setting DelegateSubgroup=. It takes the
          name of a sub-cgroup to place any processes the service manager forks
          off in. Previously, the service manager would place all service
          processes directly in the top-level cgroup it created for the
          service. This usually meant that main process in a service with
          delegation enabled would first have to create a subgroup and move
          itself down into it, in order to not conflict with the "no processes
          in inner cgroups" rule of cgroup v2. With this option, this step is
          now handled by PID 1.

        * The service manager will now look for .upholds/ directories,
          similarly to the existing support for .wants/ and .requires/
          directories. Symlinks in this directory result in Upholds=
          dependencies.

          The [Install] section of unit files gained support for a new
          UpheldBy= directive to generate .upholds/ symlinks automatically when
          a unit is enabled.

        * The service manager now supports a new kernel command line option
          systemd.default_device_timeout_sec=, which may be used to override
          the default timeout for .device units.

        * A new "soft-reboot" mechanism has been added to the service manager.
          A "soft reboot" is similar to a regular reboot, except that it
          affects userspace only: the service manager shuts down any running
          services and other units, then optionally switches into a new root
          file system (mounted to /run/nextroot/), and then passes control to a
          systemd instance in the new file system which then starts the system
          up again. The kernel is not rebooted and neither is the hardware,
          firmware or boot loader. This provides a fast, lightweight mechanism
          to quickly reset or update userspace, without the latency that a full
          system reset involves. Moreover, open file descriptors may be passed
          across the soft reboot into the new system where they will be passed
          back to the originating services. This allows pinning resources
          across the reboot, thus minimizing grey-out time further. This new
          reboot mechanism is accessible via the new "systemctl soft-reboot"
          command.

        * Services using RootDirectory= or RootImage= will now have read-only
          access to a copy of the host's os-release file under
          /run/host/os-release, which will be kept up-to-date on 'soft-reboot'.
          This was already the case for Portable Services, and the feature has
          now been extended to all services that do not run off the host's
          root filesystem.

        * A new service setting MemoryKSM= has been added to enable kernel
          same-page merging individually for services.

        * A new service setting ImportCredentials= has been added that augments
          LoadCredential= and LoadCredentialEncrypted= and searches for
          credentials to import from the system, and supports globbing.

        * A new job mode "restart-dependencies" has been added to the service
          manager (exposed via systemctl --job-mode=). It is only valid when
          used with "start" jobs, and has the effect that the "start" job will
          be propagated as "restart" jobs to currently running units that have
          a BindsTo= or Requires= dependency on the started unit.

        * A new verb "whoami" has been added to "systemctl" which determines as
          part of which unit the command is being invoked. It writes the unit
          name to standard output. If one or more PIDs are specified reports
          the unit names the processes referenced by the PIDs belong to.

        * The system and service credential logic has been improved: there's
          now a clearly defined place where system provisioning tools running
          in the initrd can place credentials that will be imported into the
          system's set of credentials during the initrd → host transition: the
          /run/credentials/@initrd/ directory. Once the credentials placed
          there are imported into the system credential set they are deleted
          from this directory, and the directory itself is deleted afterwards
          too.

        * A new kernel command line option systemd.set_credential_binary= has
          been added, that is similar to the pre-existing
          systemd.set_credential= but accepts arbitrary binary credential data,
          encoded in Base64. Note that the kernel command line is not a
          recommend way to transfer credentials into a system, since it is
          world-readable from userspace.

        * The default machine ID to use may now be configured via the
          system.machine_id system credential. It will only be used if no
          machine ID was set yet on the host.

        * On Linux kernel 6.4 and newer system and service credentials will now
          be placed in a tmpfs instance that has the "noswap" mount option
          set. Previously, a "ramfs" instance was used. By switching to tmpfs
          ACL support and overall size limits can now be enforced, without
          compromising on security, as the memory is never paged out either
          way.

        * The service manager now can detect when it is running in a
          'Confidential Virtual Machine', and a corresponding 'cvm' value is now
          accepted by ConditionSecurity= for units that want to conditionalize
          themselves on this. systemd-detect-virt gained new 'cvm' and
          '--list-cvm' switches to respectively perform the detection or list
          all known flavours of confidential VM, depending on the vendor. The
          manager will publish a 'ConfidentialVirtualization' D-Bus property,
          and will also set a SYSTEMD_CONFIDENTIAL_VIRTUALIZATION= environment
          variable for unit generators. Finally, udev rules can match on a new
          'cvm' key that will be set when in a confidential VM.
          Additionally, when running in a 'Confidential Virtual Machine', SMBIOS
          strings and QEMU's fw_cfg protocol will not be used to import
          credentials and kernel command line parameters by the system manager,
          systemd-boot and systemd-stub, because the hypervisor is considered
          untrusted in this particular setting.

        Journal:

        * The sd-journal API gained a new call sd_journal_get_seqnum() to
          retrieve the current log record's sequence number and sequence number
          ID, which allows applications to order records the same way as
          journal does internally. The sequence number is now also exported in
          the JSON and "export" output of the journal.

        * journalctl gained a new switch --truncate-newline. If specified
          multi-line log records will be truncated at the first newline,
          i.e. only the first line of each log message will be shown.

        * systemd-journal-upload gained support for --namespace=, similar to
          the switch of the same name of journalctl.

        systemd-repart:

        * systemd-repart's drop-in files gained a new ExcludeFiles= option which
          may be used to exclude certain files from the effect of CopyFiles=.

        * systemd-repart's Verity support now implements the Minimize= setting
          to minimize the size of the resulting partition.

        * systemd-repart gained a new --offline= switch, which may be used to
          control whether images shall be built "online" or "offline",
          i.e. whether to make use of kernel facilities such as loopback block
          devices and device mapper or not.

        * If systemd-repart is told to populate a newly created ESP or XBOOTLDR
          partition with some files, it will now default to VFAT rather than
          ext4.

        * systemd-repart gained a new --architecture= switch. If specified, the
          per-architecture GPT partition types (i.e. the root and /usr/
          partitions) configured in the partition drop-in files are
          automatically adjusted to match the specified CPU architecture, in
          order to simplify cross-architecture DDI building.

        * systemd-repart will now default to a minimum size of 300MB for XFS
          filesystems if no size parameter is specified. This matches what the
          XFS tools (xfsprogs) can support.

        systemd-boot, systemd-stub, ukify, bootctl, kernel-install:

        * gnu-efi is no longer required to build systemd-boot and systemd-stub.
          Instead, pyelftools is now needed, and it will be used to perform the
          ELF -> PE relocations at build time.

        * bootctl gained a new switch --print-root-device/-R that prints the
          block device the root file system is backed by. If specified twice,
          it returns the whole disk block device (as opposed to partition block
          device) the root file system is on. It's useful for invocations such
          as "cfdisk $(bootctl -RR)" to quickly show the partition table of the
          running OS.

        * systemd-stub will now look for the SMBIOS Type 1 field
          "io.systemd.stub.kernel-cmdline-extra" and append its value to the
          kernel command line it invokes. This is useful for VMMs such as qemu
          to pass additional kernel command lines into the system even when
          booting via full UEFI. The contents of the field are measured into
          TPM PCR 12.

        * The KERNEL_INSTALL_LAYOUT= setting for kernel-install gained a new
          value "auto". With this value, a kernel will be automatically
          analyzed, and if it qualifies as UKI, it will be installed as if the
          setting was to set to "uki", otherwise as "bls".

        * systemd-stub can now optionally load UEFI PE "add-on" images that may
          contain additional kernel command line information. These "add-ons"
          superficially look like a regular UEFI executable, and are expected
          to be signed via SecureBoot/shim. However, they do not actually
          contain code, but instead a subset of the PE sections that UKIs
          support. They are supposed to provide a way to extend UKIs with
          additional resources in a secure and authenticated way. Currently,
          only the .cmdline PE section may be used in add-ons, in which case
          any specified string is appended to the command line embedded into
          the UKI itself. A new 'addon<EFI-ARCH>.efi.stub' is now provided that
          can be used to trivially create addons, via 'ukify' or 'objcopy'. In
          the future we expect other sections to be made extensible like this as
          well.

        * ukify has been updated to allow building these UEFI PE "add-on"
          images, using the new 'addon<EFI-ARCH>.efi.stub'.

        * ukify gained a new "genkey" verb for generating a set of of key pairs
          to sign UKIs and their PCR data with.

        * ukify now accepts SBAT information to place in the .sbat PE section
          of UKIs and addons. If a UKI is built the SBAT information from the
          inner kernel is merged with any SBAT information associated with
          systemd-stub and the SBAT data specified on the ukify command line.

        * The kernel-install script has been rewritten in C, and reuses much of
          the infrastructure of existing tools such as bootctl. It also gained
          --esp-path= and --boot-path= options to override the path to the ESP,
          and the $BOOT partition. Options --make-entry-directory= and
          --entry-token= have been added as well, similar to bootctl's options
          of the same name.

        * A new kernel-install plugin 60-ukify has been added which will
          combine kernel/initrd locally into a UKI and optionally sign them
          with a local key. This may be used to switch to UKI mode even on
          systems where a local kernel or initrd is used. (Typically UKIs are
          built and signed by the vendor.)

        * The ukify tool now supports "pesign" in addition to the pre-existing
          "sbsign" for signing UKIs.

        * systemd-measure and systemd-stub now look for the .uname PE section
          that should contain the kernel's "uname -r" string.

        * systemd-measure and ukify now calculate expected PCR hashes for a UKI
          "offline", i.e. without access to a TPM (physical or
          software-emulated).

        Memory Pressure & Control:

        * The sd-event API gained new calls sd_event_add_memory_pressure(),
          sd_event_source_set_memory_pressure_type(),
          sd_event_source_set_memory_pressure_period() to create and configure
          an event source that is called whenever the OS signals memory
          pressure. Another call sd_event_trim_memory() is provided that
          compacts the process' memory use by releasing allocated but unused
          malloc() memory back to the kernel. Services can also provide their
          own custom callback to do memory trimming. This should improve system
          behaviour under memory pressure, as on Linux traditionally provided
          no mechanism to return process memory back to the kernel if the
          kernel was under memory pressure. This makes use of the kernel's PSI
          interface. Most long-running services in systemd have been hooked up
          with this, and in particular systems with low memory should benefit
          from this.

        * Service units gained new settings MemoryPressureWatch= and
          MemoryPressureThresholdSec= to configure the PSI memory pressure
          logic individually. If these options are used, the
          $MEMORY_PRESSURE_WATCH and $MEMORY_PRESSURE_WRITE environment
          variables will be set for the invoked processes to inform them about
          the requested memory pressure behaviour. (This is used by the
          aforementioned sd-events API additions, if set.)

        * systemd-analyze gained a new "malloc" verb that shows the output
          generated by glibc's malloc_info() on services that support it. Right
          now, only the service manager has been updated accordingly. This
          call requires privileges.

        User & Session Management:

        * The sd-login API gained a new call sd_session_get_username() to
          return the user name of the owner of a login session. It also gained
          a new call sd_session_get_start_time() to retrieve the time the login
          session started. A new call sd_session_get_leader() has been added to
          return the PID of the "leader" process of a session. A new call
          sd_uid_get_login_time() returns the time since the specified user has
          most recently been continuously logged in with at least one session.

        * JSON user records gained a new set of fields capabilityAmbientSet and
          capabilityBoundingSet which contain a list of POSIX capabilities to
          set for the logged in users in the ambient and bounding sets,
          respectively. homectl gained the ability to configure these two sets
          for users via --capability-bounding-set=/--capability-ambient-set=.

        * pam_systemd learnt two new module options
          default-capability-bounding-set= and default-capability-ambient-set=,
          which configure the default bounding sets for users as they are
          logging in, if the JSON user record doesn't specify this explicitly
          (see above). The built-in default for the ambient set now contains
          the CAP_WAKE_ALARM, thus allowing regular users who may log in
          locally to resume from a system suspend via a timer.

        * The Session D-Bus objects systemd-logind gained a new SetTTY() method
          call to update the TTY of a session after it has been allocated. This
          is useful for SSH sessions which are typically allocated first, and
          for which a TTY is added later.

        * The sd-login API gained a new call sd_pid_notifyf_with_fds() which
          combines the various other sd_pid_notify() flavours into one: takes a
          format string, an overriding PID, and a set of file descriptors to
          send. It also gained a new call sd_pid_notify_barrier() call which is
          equivalent to sd_notify_barrier() but allows the originating PID to
          be specified.

        * "loginctl list-users" and "loginctl list-sessions" will now show the
          state of each logged in user/session in their tabular output. It will
          also show the current idle state of sessions.

        DDIs:

        * systemd-dissect will now show the intended CPU architecture of an
          inspected DDI.

        * systemd-dissect will now install itself as mount helper for the "ddi"
          pseudo-file system type. This means you may now mount DDIs directly
          via /bin/mount or /etc/fstab, making full use of embedded Verity
          information and all other DDI features.

          Example: mount -t ddi myimage.raw /some/where

        * The systemd-dissect tool gained the new switches --attach/--detach to
          attach/detach a DDI to a loopback block device without mounting it.
          It will automatically derive the right sector size from the image
          and set up Verity and similar, but not mount the file systems in it.

        * When systemd-gpt-auto-generator or the DDI mounting logic mount an
          ESP or XBOOTLDR partition the MS_NOSYMFOLLOW mount option is now
          implied. Given that these file systems are typically untrusted, this
          should make mounting them automatically have less of a security
          impact.

        * All tools that parse DDIs (such as systemd-nspawn, systemd-dissect,
          systemd-tmpfiles, …) now understand a new switch --image-policy= which
          takes a string encoding image dissection policy. With this mechanism
          automatic discovery and use of specific partition types and the
          cryptographic requirements on the partitions (Verity, LUKS, …) can be
          restricted, permitting better control of the exposed attack surfaces
          when mounting disk images. systemd-gpt-auto-generator will honour such
          an image policy too, configurable via the systemd.image_policy= kernel
          command line option. Unit files gained the RootImagePolicy=,
          MountImagePolicy= and ExtensionImagePolicy= to configure the same for
          disk images a service runs off.

        * systemd-analyze gained a new verb "image-policy" to validate and
          parse image policy strings.

        * systemd-dissect gained support for a new --validate switch to
          superficially validate DDI structure, and check whether a specific
          image policy allows the DDI.

        * systemd-dissect gained support for a new --mtree-hash switch to
          optionally disable calculating mtree hashes, which can be slow on
          large images.

        * systemd-dissect --copy-to, --copy-from, --list and --mtree switches
          are now able to operate on directories too, other than images.

        Network Management:

        * networkd's GENEVE support as gained a new .network option
          InheritInnerProtocol=.

        * The [Tunnel] section in .netdev files has gained a new setting
          IgnoreDontFragment for controlling the IPv4 "DF" flag of datagrams.

        * A new global IPv6PrivacyExtensions= setting has been added that
          selects the default value of the per-network setting of the same
          name.

        * The predictable network interface naming logic will now include
          SR-IOV-R "representor" information in network interface names.

        * The DHCPv4 + DHCPv6 + IPv6 RA logic in networkd gained support for
          the RFC8910 captive portal option.

        Device Management:

        * udevadm gained the new "verify" verb for validating udev rules files
          offline.

        * udev gained a new tool "iocost" that can be used to configure QoS IO
          cost data based on hwdb information onto suitable block devices. Also
          see https://github.com/iocost-benchmark/iocost-benchmarks.

        TPM2 Support + Disk Encryption & Authentication:

        * systemd-cryptenroll/systemd-cryptsetup will now install a TPM2 SRK
          ("Storage Root Key") as first step in the TPM2, and then use that
          for binding FDE to, if TPM2 support is used. This matches
          recommendations of TCG (see

https://trustedcomputinggroup.org/wp-content/uploads/TCG-...)

        * systemd-cryptenroll and other tools that take TPM2 PCR parameters now
          understand textual identifiers for these PCRs.

        * systemd-veritysetup + /etc/veritytab gained support for a series of
          new options: hash-offset=, superblock=, format=, data-block-size=,
          hash-block-size=, data-blocks=, salt=, uuid=, hash=, fec-device=,
          fec-offset=, fec-roots= to configure various aspects of a Verity
          volume.

        * systemd-cryptsetup + /etc/crypttab gained support for a new
          veracrypt-pim= option for setting the Personal Iteration Multiplier
          of veracrypt volumes.

        * systemd-integritysetup + /etc/integritytab gained support for a new
          mode= setting for controlling the dm-integrity mode (journal, bitmap,
          direct) for the volume.

        * systemd-analyze gained a new verb "pcrs" that shows the known TPM PCR
          registers, their symbolic names and current values.

        systemd-tmpfiles:

        * The ACL support in tmpfiles.d/ has been updated: if an uppercase "X"
          access right is specified this is equivalent to "x" but only if the
          inode in question already has the executable bit set for at least
          some user/group. Otherwise the "x" bit will be turned off.

        * tmpfiles.d/'s C line type now understands a new modifier "+": a line
          with C+ will result in a "merge" copy, i.e. all files of the source
          tree are copied into the target tree, even if that tree already
          exists, resulting in a combined tree of files already present in the
          target tree and those copied in.

        * systemd-tmpfiles gained a new --graceful switch. If specified lines
          with unknown users/groups will silently be skipped.

        systemd-notify:

        * systemd-notify gained two new options --fd= and --fdname= for sending
          arbitrary file descriptors to the service manager (while specifying an
          explicit name for it).

        * systemd-notify gained a new --exec switch, which makes it execute the
          specified command line after sending the requested messages. This is
          useful for sending out READY=1 first, and then continuing invocation
          without changing process ID, so that the tool can be nicely used
          within an ExecStart= line of a unit file that uses Type=ready.

        sd-event + sd-bus APIs:

        * The sd-event API gained a new call sd_event_source_leave_ratelimit()
          which may be used to explicitly end a rate-limit state an event
          source might be in, resetting all rate limiting counters.

        * When the sd-bus library is used to make connections to AF_UNIX D-Bus
          sockets, it will now encode the "description" set via
          sd_bus_set_description() into the source socket address. It will also
          look for this information when accepting a connection. This is useful
          to track individual D-Bus connections on a D-Bus broker for debug
          purposes.

        systemd-resolved:

        * systemd-resolved gained a new resolved.conf setting
          StateRetentionSec= which may be used to retain cached DNS records
          even after their nominal TTL, and use them in case upstream DNS
          servers cannot be reached. This can be sued to make name resolution
          more resilient in case of network problems.

        * resolvectl gained a new verb "show-cache" to show the current cache
          contents of systemd-resolved. This verb communicates with the
          systemd-resolved daemon and requires privileges.

        Other:

        * Meson >= 0.60.0 is now required to build systemd.

        * The default keymap to apply may now be chosen at build-time via the
          new -Ddefault-keymap= meson option.

        * Most of systemd's long-running services now have a generic handler of
          the SIGRTMIN+18 signal handler which executes various operations
          depending on the sigqueue() parameter sent along. For example, values
          0x100…0x107 allow changing the maximum log level of such
          services. 0x200…0x203 allow changing the log target of such
          services. 0x300 make the services trim their memory similarly to the
          automatic PSI-triggered action, see above. 0x301 make the services
          output their malloc_info() data to the logs.

        * machinectl gained new "edit" and "cat" verbs for editing .nspawn
          files, inspired by systemctl's verbs of the same name which edit unit
          files. Similarly, networkctl gained the same verbs for editing
          .network, .netdev, .link files.

        * A new syscall filter group "@sandbox" has been added that contains
          syscalls for sandboxing system calls such as those for seccomp and
          Landlock.

        * New documentation has been added:

          https://systemd.io/COREDUMP
          https://systemd.io/MEMORY_PRESSURE
          smbios-type-11(7)

        * systemd-firstboot gained a new --reset option. If specified, the
          settings in /etc/ it knows how to initialize are reset.

        * systemd-sysext is now a multi-call binary and is also installed under
          the systemd-confext alias name (via a symlink). When invoked that way
          it will operate on /etc/ instead of /usr/ + /opt/. It thus becomes a
          powerful, atomic, secure configuration management of sorts, that
          locally can merge configuration from multiple confext configuration
          images into a single immutable tree.

        * The --network-macvlan=, --network-ipvlan=, --network-interface=
          switches of systemd-nspawn may now optionally take the intended
          network interface inside the container.

        * All our programs will now send an sd_notify() message with their exit
          status in the EXIT_STATUS= field when exiting, using the usual
          protocol, including PID 1. This is useful for VMMs and container
          managers to collect an exit status from a system as it shuts down, as
          set via "systemctl exit …". This is particularly useful in test cases
          and similar, as invocations via a VM can now nicely propagate an exit
          status to the host, similar to local processes.

        * systemd-run gained a new switch --expand-environment=no to disable
          server-side environment variable expansion in specified command
          lines. Expansion defaults to enabled for all execution types except
          --scope, where it defaults to off (and prints a warning) for backward
          compatibility reasons. --scope will be flipped to default enabled too
          in a future release, so if you are using --scope and passing a '$'
          character in the payload you should start explicitly using
          --expand-environment=yes/no according to the use case.

        * The systemd-system-update-generator has been updated to also look for
          the special flag file /etc/system-update in addition to the existing
          support for /system-update to decide whether to enter system update
          mode.

        * The /dev/hugepages/ file system is now mounted with nosuid + nodev
          mount options by default.

        * systemd-fstab-generator now understands two new kernel command line
          options systemd.mount-extra= and systemd.swap-extra=, which configure
          additional mounts or swaps in a format similar to /etc/fstab. 'fsck'
          will be ran on these block devices, like it already happens for
          'root='. It also now supports the new fstab.extra and
          fstab.extra.initrd credentials that may contain additional /etc/fstab
          lines to apply at boot.

        * systemd-getty-generator now understands two new credentials
          getty.ttys.container and getty.ttys.serial. These credentials may
          contain a list of TTY devices – one per line – to instantiate
          container-getty@.service and serial-getty@.service on.

        * The getty/serial-getty/container-getty units now import the 'agetty.*'
          and 'login.*' credentials, which are consumed by the 'login' and
          'agetty' programs starting from util-linux v2.40.

        * systemd-sysupdate's sysupdate.d/ drop-ins gained a new setting
          PathRelativeTo=, which can be set to "esp", "xbootldr", "boot", in
          which case the Path= setting is taken relative to the ESP or XBOOTLDR
          partitions, rather than the system's root directory /. The relevant
          directories are automatically discovered.

        * The systemd-ac-power tool gained a new switch --low, which reports
          whether the battery charge is considered "low", similar to how the
          s2h suspend logic checks this state to decide whether to enter system
          suspend or hibernation.

        * The /etc/os-release file can now have two new optional fields
          VENDOR_NAME= and VENDOR_URL= to carry information about the vendor of
          the OS.

        * When the system hibernates, information about the device and offset
          used is now written to a non-volatile EFI variable. On next boot the
          system will attempt to resume from the location indicated in this EFI
          variable. This should make hibernation a lot more robust, while
          requiring no manual configuration of the resume location.

        * The $XDG_STATE_HOME environment variable (added in more recent
          versions of the XDG basedir specification) is now honoured to
          implement the StateDirectory= setting in user services.

        * A new component "systemd-battery-check" has been added. It may run
          during early boot (usually in the initrd), and checks the battery
          charge level of the system. In case the charge level is very low the
          user is notified (graphically via Plymouth – if available – as well
          as in text form on the console), and the system is turned off after a
          10s delay. The feature can be disabled by passing
          systemd.battery-check=0 through the kernel command line.

        * The 'passwdqc' library is now supported as an alternative to the
          'pwquality' library and it can be selected at build time.

        Contributions from: 김인수, 07416, Addison Snelling, Adrian Vovk,
        Aidan Dang, Alexander Krabler, Alfred Klomp, Anatoli Babenia,
        Andrei Stepanov, Andrew Baxter, Antonio Alvarez Feijoo,
        Arian van Putten, Arthur Shau, A S Alam,
        Asier Sarasua Garmendia, Balló György, Bastien Nocera,
        Benjamin Herrenschmidt, Benjamin Raison, Bill Peterson,
        Brad Fitzpatrick, Brett Holman, bri, Chen Qi, Chitoku,
        Christian Hesse, Christoph Anton Mitterer, Christopher Gurnee,
        Colin Walters, Cornelius Hoffmann, Cristian Rodríguez, cunshunxia,
        cvlc12, Cyril Roelandt, Daan De Meyer, Daniele Medri,
        Daniel P. Berrangé, Daniel Rusek, Dan Streetman, David Edmundson,
        David Schroeder, David Tardon, dependabot[bot],
        Dimitri John Ledkov, Dmitrii Fomchenkov, Dmitry V. Levin, dmkUK,
        Dominique Martinet, don bright, drosdeck, Edson Juliano Drosdeck,
        Egor Ignatov, EinBaum, Emanuele Giuseppe Esposito, Eric Curtin,
        Erik Sjölund, Evgeny Vereshchagin, Florian Klink, Franck Bui,
        François Rigault, Fran Diéguez, Franklin Yu, Frantisek Sumsal,
        Fuminobu TAKEYAMA, Gaël PORTAY, Gerd Hoffmann, Gertalitec,
        Gibeom Gwon, Gustavo Noronha Silva, Hannu Lounento,
        Hans de Goede, Haochen Tong, HATAYAMA Daisuke, Henrik Holst,
        Hoe Hao Cheng, Igor Tsiglyar, Ivan Vecera, James Hilliard,
        Jan Engelhardt, Jan Janssen, Jan Luebbe, Jan Macku, Janne Sirén,
        jcg, Jeidnx, Joan Bruguera, Joerg Behrmann, jonathanmetzman,
        Jordan Rome, Josef Miegl, Joshua Goins, Joyce, Joyce Brum,
        Juno Computers, Kai Lueke, Kevin P. Fleming, Kiran Vemula, Klaus,
        Klaus Zipfel, Lawrence Thorpe, Lennart Poettering, licunlong,
        Lily Foster, Luca Boccassi, Ludwig Nussel, Luna Jernberg,
        maanyagoenka, Maanya Goenka, Maksim Kliazovich, Malte Poll,
        Marko Korhonen, Masatake YAMATO, Mateusz Poliwczak, Matt Johnston,
        Miao Wang, Micah Abbott, Michael A Cassaniti, Michal Koutný,
        Michal Sekletár, Mike Yuan, mooo, Morten Linderud, msizanoen,
        Nick Rosbrook, nikstur, Olivier Gayot, Omojola Joshua,
        Paolo Velati, Paul Barker, Pavel Borecki, Petr Menšík,
        Philipp Kern, Philip Withnall, Piotr Drąg, Quintin Hill,
        Rene Hollander, Richard Phibel, Robert Meijers, Robert Scheck,
        Roger Gammans, Romain Geissler, Ronan Pigott, Russell Harmon,
        saikat0511, Samanta Navarro, Sam James, Sam Morris,
        Simon Braunschmidt, Sjoerd Simons, Sorah Fukumori,
        Stanislaw Gruszka, Stefan Roesch, Steven Luo, Steve Ramage,
        Susant Sahani, taniishkaaa, Tanishka, Temuri Doghonadze,
        Thierry Martin, Thomas Blume, Thomas Genty, Thomas Weißschuh,
        Thorsten Kukuk, Times-Z, Tobias Powalowski, tofylion,
        Topi Miettinen, Uwe Kleine-König, Velislav Ivanov,
        Vitaly Kuznetsov, Vít Zikmund, Weblate, Will Fancher,
        William Roberts, Winterhuman, Wolfgang Müller, Xeonacid,
        Xiaotian Wu, Xi Ruoyao, Yuri Chornoivan, Yu Watanabe, Yuxiang Zhu,
        Zbigniew Jędrzejewski-Szmek, zhmylove, ZjYwMj,
        Дамјан Георгиевски, наб

        — Edinburgh, 2023-07-28


to post comments

Systemd 254 released

Posted Jul 28, 2023 19:39 UTC (Fri) by jccleaver (guest, #127418) [Link] (82 responses)

>The announcement also notes the support for split-/usr systems will be removed in the next release, and support for version-one control groups and for System V service scripts will be deleted in the near future as well.

Well a very hearty middle finger back to the "systemd kabal" too!

Now that LP doesn't work for RH any more, can we start to undo any of this un-necessary burning of anything that LP and his team don't specifically use on their personal laptops? Thanks.

Baseless whining

Posted Jul 28, 2023 19:54 UTC (Fri) by zdzichu (guest, #17118) [Link] (1 responses)

https://github.com/systemd/systemd/pulls

There's "New pull request" button.

Go for it.

Baseless whining

Posted Jul 28, 2023 20:11 UTC (Fri) by jccleaver (guest, #127418) [Link]

> There's "New pull request" button.
> Go for it.

Go for what, exactly? Remove the "stated intention" to remove SysV initscript support from the current release notes?

When the change is made, I'll post a comment that I would prefer this support kept. It will be ignored by the kabal, just like everything else is, while they purge whatever it is they don't like. Like you, they may refer to it as "baseless whining" as well.

A comment about this to the Fedora list will return a "This is upstream's decision; hands tied *shrug*" response… possibly by the same upstream person wearing a different hat. After 10 or so years, the pattern around this is fairly salient.

Systemd 254 released

Posted Jul 28, 2023 19:55 UTC (Fri) by NightMonkey (subscriber, #23051) [Link] (1 responses)

OpenRC is still alive. (https://en.wikipedia.org/wiki/OpenRC) :)

At least for now, there are a few binary and meta distros useful for the desktop that still don't force you to use systemd(*). Non-systemd desktop setups are getting marginalized, tho, and more packages are arriving that just assume systemd is the init system, sadly.

I have a split /usr on my desktop, and happy to use Gentoo, so I'm not directly affected. But, I can't escape systemd in my work... and I wish Linux userspace was still about offering choices - *my* choices, not only someone else's... Make a 'golden path', sure, but don't make it impossible to choose any other way.

* There are some non-core systemd bits now required on Gentoo no matter the init system, but they're in https://packages.gentoo.org/packages/sys-apps/systemd-utils and are basically glue code for udev and tmp file management.

Systemd 254 released

Posted Jul 29, 2023 8:59 UTC (Sat) by tuna (guest, #44480) [Link]

If you choose to use a distro that is based on systemd (and Linux etc) you are not "forced" to use systemd. If you use that word in these cases you dilute the meaning of it and it makes it harder to discuss cases where you are actually forced to use certain software/devices such as the need to use iOS/Android devices (with an active phone number) when traveling or purchasing things.

Systemd 254 released

Posted Jul 28, 2023 20:55 UTC (Fri) by bluca (subscriber, #118303) [Link]

The kabal send their regards

Systemd 254 released

Posted Jul 29, 2023 5:45 UTC (Sat) by oldtomas (guest, #72579) [Link] (1 responses)

Please, stop this vitriol.

I don't like systemd, for reasons I won't go into (it feels like all valid and many invalid arguments on both sides have been heard several times).

The attitude conveyed by your comment has derailed any rational discussion we could have had back then.

Remember that MikeeeUSA? That's when I stopped arguing against systemd. If you have energy left over,you could help maintain SysV on Debian.

Systemd 254 released

Posted Jul 29, 2023 8:38 UTC (Sat) by Wol (subscriber, #4433) [Link]

> I don't like systemd, for reasons I won't go into (it feels like all valid and many invalid arguments on both sides have been heard several times).

Well said.

We don't have to agree with each other (and on this particular occasion I don't), but you have to respect each others' decisions. I'm well known for railing against the route computing has gone down (word processors, databases) because I think it's taken a wrong turn, but NEVER EVER turn it into a personal attack.

And as I always say, TRY AND UNDERSTAND THE OTHER PERSON'S POV. Half the time you'll find the error is in YOUR perception of the situation. And if you really want to win the discussion, the easy way to do it is to ask them to explain their logic - and point them at their mistake to let THEM find it.

I agree with tomas - if you don't like systemd, go help OpenRC, go help SystemV, go DO something. I've tried to guide LibreOffice down the route I want, I'm now working on Scarlet. I'm trying to change the world. Just accept that a couple of people versus a Juggernaut is going to have a hard time of it :-(

Cheers,
Wol

Systemd 254 released

Posted Jul 30, 2023 2:55 UTC (Sun) by mirabilos (subscriber, #84359) [Link] (2 responses)

Yeah, this is an appalling example of embrace-extend-extinguish.

This is causing no small amount of trouble in Debian and makes it an unsuitable upstream. The “Universal OS” is long gone.

Systemd 254 released

Posted Jul 30, 2023 11:37 UTC (Sun) by bluca (subscriber, #118303) [Link] (1 responses)

What trouble are you talking about? The only thing it's causing is for some old, broken and crusty cruft that should have been RMed long time ago, to finally be removed. That's a good thing.

Systemd 254 released

Posted Jul 30, 2023 19:42 UTC (Sun) by mirabilos (subscriber, #84359) [Link]

We’ve also encountered trouble that could have been resolved by an RoDD. Alas…

Systemd 254 released

Posted Jul 30, 2023 5:56 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (71 responses)

Note, you can write trivial systemd wrappers for sysv scripts (that's what systemd-sysv-generator does). I guess it just means that systemd simply won't maintain it anymore.

This is kind of a dick move, but it's not the end of the world. The generator is pretty trivial ( https://github.com/systemd/systemd/blob/main/src/sysv-gen... ), and can be supported as a third-party project indefinitely.

Systemd 254 released

Posted Jul 30, 2023 9:20 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

That's what was puzzling me, too. I thought you could just fire up a SysV script from a trivial systemd config file.

Cheers,
Wol

Systemd 254 released

Posted Jul 30, 2023 10:22 UTC (Sun) by mchapman (subscriber, #66589) [Link]

There is also a small amount of integration between systemctl and the system's SysV initscript management, via systemd-sysv-install. This will be dropped too. I expect distributions that still care about initscripts to just patch this logic back in again. It's reasonably simple code, and I don't expect systemctl to change so significantly that that becomes difficult in the future.

Systemd 254 released

Posted Jul 30, 2023 11:53 UTC (Sun) by bluca (subscriber, #118303) [Link] (68 responses)

Look, it's been 15 years. This is way way longer than compilers keep compatibility for, most non-trivial C programs require at least some minimal work every time there's a new major version of GCC. If in 15 years there's been no time to write a 3-lines INI file for a given package, then that package is either completely unmaintained or offers nothing of value and can be dropped. Keeping a distribution in good shape requires constant maintenance, and periodic spring cleanings to prune the cruft are good practice.

Systemd 254 released

Posted Jul 30, 2023 16:50 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (67 responses)

I still have fairly new software (less than 3 years old!) that only has SysV scripts. Yeah, I can easily writer a wrapper script, I know. However, having a tool to do it is nice.

SysV support is also not a high-maintenance part of systemd.

So yep, removing it is a dick move.

Systemd 254 released

Posted Jul 30, 2023 17:28 UTC (Sun) by bluca (subscriber, #118303) [Link] (60 responses)

Have you considered that maybe the reason why new software still ships _only_ subpar, inferior and half-broken scripts that provide no value on 99.5% of installations is because of inertia? This made sense 15 years ago to facilitate the transition. Today, it just cements bad patterns and bad quality solutions. Forcing those to either also provide a higher quality native solution, or be deprecated and replaced if they are so unmaintained that even adding a 3 lines config file is an impossible goal, is a win/win in my book, and the right thing to do _today_ (would not have been 15 years ago ofc).

Very few software are so crucial that they really need to work completely unchanged (on brand new distributions!) for 15 years, and the venn diagram between that and those that ship crufty init scripts is an empty set. For the rest, legacy software can always run on old LTS distributions which will be around for a long long time still, this is not a retroactive change.

Systemd 254 released

Posted Jul 30, 2023 17:32 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

> Have you considered that maybe the reason why new software still ships _only_ subpar, inferior and half-broken scripts that provide no value on 99.5% of installations is because of inertia?

It has native support for another init system (OpenRC) and the legacy SysV.

> This made sense 15 years ago to facilitate the transition

Sure. Not all people see the advantages of that, though. Other init systems exist, and other OSes also exist. And finally, 15 years is about the same duration as RedHat's long-term maintenance period.

Systemd 254 released

Posted Jul 30, 2023 17:44 UTC (Sun) by mb (subscriber, #50428) [Link] (6 responses)

The problem is not that an init script is available for old or non-systemd systems. That doesn't hurt anybody.
But there is a problem, if no systemd service file is available.

Systemd 254 released

Posted Jul 31, 2023 19:08 UTC (Mon) by calumapplepie (guest, #143655) [Link] (5 responses)

Except that maintaining something in two different forms is asking for bugs. Why should I maintain a a service file when my init script works just fine on SystemD systems? If you want me to do both, you're asking me to introduce bugs when they fall out of sync with changes

I'm pro-systemd, but dropping compatibility layers that are cheap and which are actively used is not good. It isn't a problem if I chose to code to a more general standard than systemd. It's a problem is SystemD decides to drop all support for that standard for no reason other than they want to.

Systemd 254 released

Posted Jul 31, 2023 19:47 UTC (Mon) by bluca (subscriber, #118303) [Link] (4 responses)

First of all, it's 'systemd', not 'SystemD'. Secondly, the reason as already explained is that your init script does not work just fine on systemd, as the translation is extremely limited, has severe shortcomings and blind spots that just cannot be solved because the formats are just incompatible. sysv init scripts are not a "more general standard", in fact they are the furthest thing there is from a 'standard', and they are not even expected to work in the same way across distributions. So, the translation layer is going to be dropped, as it is no longer necessary to facilitate the transition but it is just causing ossification of known broken patterns.

Systemd 254 released

Posted Jul 31, 2023 20:50 UTC (Mon) by sfeam (subscriber, #2841) [Link] (3 responses)

"ossification of known patterns" is a good thing. It is otherwise known as "stability". "broken" is another matter, but fixing something broken is not accomplished by dropping it altogether.

Systemd 254 released

Posted Jul 31, 2023 21:41 UTC (Mon) by bluca (subscriber, #118303) [Link] (2 responses)

Unit files are stable. Old and crufty init scripts were known for many things, but being stable is definitely not one of them. You will still be able to use them of course, if you like them - not on systemd though.

Systemd 254 released

Posted Aug 3, 2023 14:35 UTC (Thu) by jccleaver (guest, #127418) [Link] (1 responses)

>Unit files are stable. Old and crufty init scripts were known for many things, but being stable is definitely not one of them. You will still be able to use them of course, if you like them - not on systemd though.

Thank you for so clearly demonstrating my original point in this thread.

What you're calling "old and crufty" others call stability. Some of us (many of us) prefer imperative to declarative during important phases of operation because it makes it easier for a human to debug. Even leaving aside the fact that init scripts have been updated less and less due to systemd-migration, init scripts haven't changed much because they *just worked*... This is especially the case on the Red Hat/Fedora side of the ecosystem, instead of the Debian landscape where things actually were a bit more painful. But init script conventions in Fedora-world had been locked down pretty well for a long while.

Regardless, your "you can use them, but since I don't, you're not going to use them on systemd" attitude is *PRECISELY* what earns you such vitriol from admins downstream of your decisions.

I'm sorry YOU don't want initscripts on YOUR laptop, bluca. Some others of us would prefer that that compatibility layer stay. Thanks.

Systemd 254 released

Posted Aug 3, 2023 17:21 UTC (Thu) by anselm (subscriber, #2796) [Link]

I'm sorry YOU don't want initscripts on YOUR laptop, bluca. Some others of us would prefer that that compatibility layer stay. Thanks.

Nobody will prevent your init scripts from working. All that changes is that you will have to come up with your own systemd service units that call them. If your service is running now you can copy a simple one from /run/systemd/generator.late for later.

This is independent from the fact that on a systemd-based machine, when you're using init scripts – especially with a very simple (auto-generated) service unit – you're deliberately forgoing a bunch of cool and useful features which systemd provides out of the box, which could make your service easier to control, more stable, and more secure, and which SysV init files generally do not bother with. Of course this is your privilege, but it may be worth considering whether making a dedicated systemd service unit for your service which works without the init script and takes more direct advantage of systemd's features might not be a good idea after all.

Systemd 254 released

Posted Jul 30, 2023 18:31 UTC (Sun) by bluca (subscriber, #118303) [Link] (1 responses)

> It has native support for another init system (OpenRC) and the legacy SysV.

and they can keep shipping it for those, nothing against that. I will not do that for my packages because I just don't have time to cater to the 0.5%, but those who do can keep maintaining those, Debian is already set up to do exactly that, with a source package collecting and shipping old init scripts, so that those who want to keep them alive can do the required work to make it happen. But a good quality package needs to _at least_ support the 99.5% natively, providing an optimal out-of-the box integrated and consistent experience.

> Sure. Not all people see the advantages of that, though. Other init systems exist, and other OSes also exist.

And they can support those too, separately. Forcing the 99.5% down to the minimum common denominator is not acceptable anymore though.

Systemd 254 released

Posted Jul 30, 2023 19:33 UTC (Sun) by Wol (subscriber, #4433) [Link]

Okay, I think it's currently broken, but that's the attitude I take with Scarlet. For my sins, I rewrote (and broke :-) the makefile (but it did have idiocies like calling sudo ... :-).

I originally wrote it for gentoo, because that's what I run, and it promptly broke on SUSE because of unified-usr. I'm now getting reports it's broken on Ubuntu - don't know why but I can guess ...

But it installs the systemd stuff, inasmuch as I can do anything about it it installs SysV stuff, it would support OpenRC except I don't run it, ... why should I care what other systems it supports so long as it supports mine, but if I'm looking after it, I want it to support every system I can make it support ...

Cheers,
Wol

Systemd 254 released

Posted Jul 31, 2023 9:58 UTC (Mon) by rcampos (subscriber, #59737) [Link] (49 responses)

If it is subpar, inferior and half broken is a very subjective opinion. Clearly not everyone thinks that, it doesn't matter how "objective" and based on facts you think your opinion is. Forcing people to migrate just because you think it is better for them, is questionable IMHO.

If this is something people is still using and it is trivial to maintain on the systemd side, why not keep it?

If it has a big cost, of course it's simpler to explain. But so far no one brought up that argument.

Systemd 254 released

Posted Jul 31, 2023 10:26 UTC (Mon) by bluca (subscriber, #118303) [Link] (48 responses)

No, it's not an opinion, a translated non-native script will never be the same quality as the native solution, as there's no way to have a 1:1 match. There are tons of well-known limitations that make this solution broadly speaking inferior and very often half broken, and was always intended as a way to help transition forward. It is time to move on and finish that transition.
These old scripts don't have to be deleted, they can still be shipped, together with native units, to cover for that 0.5% of installations.

Systemd 254 released

Posted Jul 31, 2023 19:21 UTC (Mon) by calumapplepie (guest, #143655) [Link] (47 responses)

If a developer is choosing to maintain a init script and not a systemd unit, let us assume that they know those limitations and choose to accept them. Since 99.5% of people are running systemd, we can conclude that any bugs that are arising from the translation layer are being handled by them; otherwise, they'd have introduced a service file themselves.

You earlier compared systemd to a compiler. But compilers still support C89; you need to specify an option, but it works just fine*. C89 is 33 years old; there is no sane reason to support it. Anyone writing C89 programs should bite the bullet and upgrade to a modern standard. "There are tons of well-known limitations that make [C89] broadly speaking inferior and very often half broken, and [having it as an option] was always intended as a way to help transition forward. It is time to move on and finish that transition".

* To my knowledge and the claims of the man page.

It isn't even really fair to compare systemd to successive compiler versions; systemd is an independent project, which commonly replaces other init systems, but it is not from the same developers and is therefore not strictly 'better'. It exists in parallel, just like the BSDs do with Linux. Do many people use the BSDs? Not at all. But is that any reason for Linux to remove support for BSD-style programs just because they can? Not in the slightest.

Systemd 254 released

Posted Jul 31, 2023 19:57 UTC (Mon) by bluca (subscriber, #118303) [Link] (46 responses)

> If a developer is choosing to maintain a init script and not a systemd unit, let us assume that they know those limitations and choose to accept them.

No, it's mostly inertia. That's why it needs a gentle push in the opposite direction.

> You earlier compared systemd to a compiler. But compilers still support C89; you need to specify an option, but it works just fine

Yeah, no, that is not remotely how any of this works. Just go and look at the number of build failure bugs filed in Debian every time GCC is bumped to a new major version. Hint: it's not zero, and it has nothing to do with 'specifying options'. And it's all fine - compilers need to make progress and break some things to improve performance and security, so we just have to deal with it.

> Do many people use the BSDs? Not at all. But is that any reason for Linux to remove support for BSD-style programs just because they can? Not in the slightest.

Yes, it absolutely is. The people who are interested in the 0.01% can put their money where their mouth is and to the work to support that, nothing is going to stop them. But the rest of us will just move forward and improve performance, security and featuresets for the 99.99%.

Systemd 254 released

Posted Jul 31, 2023 21:44 UTC (Mon) by calumapplepie (guest, #143655) [Link] (45 responses)

> No, it's mostly inertia. That's why it needs a gentle push in the opposite direction.

Your entire case centers upon this claim. What evidence do you have for it? Are you sure that everything you perceive as interta is just that? Are you sure that it is worth it to you and every downstream maintainer to reverse the direction of this inertia?

> Hint: it's not zero, and it has nothing to do with 'specifying options'.

Actually, it generally is to do with specifying options. Changed GCC versions change the default options, adding additional checks. They rarely drop support for compliant features. Reading through GCC-12, GCC-11, GCC-10, GCC-9, and GCC-8, we see that only 3 of those even have changes in C that break compatibility with existing programs, and all are quite niche. Most can be overridden by compiler options, or involve very specific constructs that should never have been allowed. For instance, the one change in GCC-12 is that goto now requires that the pointer it takes... be of a pointer type.

> But the rest of us will just move forward and improve performance, security and featuresets for the 99.99%.

How does removing init script support improve any of those things? Don't tell me "it forces those who are using this feature which I consider broken to stop using it". Developers are just as much your users as users are; removing a developer-only feature is still a removed feature.

The change you are making will require significant work for a lot of people other than you. There are 301 packages in Debian Bookworm[1] which ship files in /etc/init.d but not /lib/systemd. Those packages aren't unmaintained; the developers simply chose to use the features of systemd (backwards-compatability with existing scritps) to ensure they could easily support all init systems. Do the benefits you see from removing this feature justify the costs you are imposing across the ecosystem? What makes you so certain that the benefits you see will be experienced by all, which is needed for this to be anything other than a regression?

Systemd 254 released

Posted Jul 31, 2023 21:50 UTC (Mon) by mb (subscriber, #50428) [Link]

>> But the rest of us will just move forward and improve performance, security and featuresets for the 99.99%.
>How does removing init script support improve any of those things?

If I had to name one thing that systemd improved, I would name system startup time.
So yes, replacing init scripts with systemd files improves performance by a lot.

Systemd 254 released

Posted Jul 31, 2023 22:05 UTC (Mon) by bluca (subscriber, #118303) [Link] (43 responses)

> Your entire case centers upon this claim. What evidence do you have for it? Are you sure that everything you perceive as interta is just that? Are you sure that it is worth it to you and every downstream maintainer to reverse the direction of this inertia?

Yes, the list of affected packages peaks for itself. Vast majority is barely maintained stuff, if not outright abandoned. In fact many aren't even shipping anymore already.

> Actually, it generally is to do with specifying options.

No. This is the list of build failures caused by GCC 13, 345 build failures, nothing to do with new options: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debia...

> How does removing init script support improve any of those things? Don't tell me "it forces those who are using this feature which I consider broken to stop using it". Developers are just as much your users as users are; removing a developer-only feature is still a removed feature.

As already mentioned, init scripts support is fraught with issues that cannot be solved, so removing it and replacing it with native support will improve the situation overall. This is objective truth. If you want to claim that there are no issues with using init scripts on systemd, then you simply have no idea what you are talking about.

> The change you are making will require significant work for a lot of people other than you. There are 301 packages in Debian Bookworm[1] which ship files in /etc/init.d but not /lib/systemd. Those packages aren't unmaintained; the developers simply chose to use the features of systemd (backwards-compatability with existing scritps) to ensure they could easily support all init systems. Do the benefits you see from removing this feature justify the costs you are imposing across the ecosystem? What makes you so certain that the benefits you see will be experienced by all, which is needed for this to be anything other than a regression?

Actually it's 257, and lots of them are barely maintained, on top of a bunch of false positive because lintian.debian.org is broken. Quite a few have already been migrated since, and the rest will either migrate (if they are truly still maintained) or will simply be removed and not ship anymore. The cost and benefit is not that different from introducing GCC 13 and causing 345 packages to need patching. Actually it's probably easier and quicker to solve than a GCC13 FTBFS, as adding a basic unit file is trivial. If you care about any of those 257, in the time you have spent complaining on LWN, you could have helped the maintainers convert at least a dozen if not more. Why not just do that?

Systemd 254 released

Posted Aug 1, 2023 8:13 UTC (Tue) by Wol (subscriber, #4433) [Link] (38 responses)

> If you care about any of those 257, in the time you have spent complaining on LWN, you could have helped the maintainers convert at least a dozen if not more. Why not just do that?

Because writing a trivial systemd unit file is not, in fact, trivial?

Speaking from experience, I wrote a unit file, and I have no clue why, but the resulting breakage to my system (ie BEYOND the application I wrote the unit file for) was a MESS. The application itself was clearly not expecting to be called from a unit file, needs fixing (I can guess what the problem is), and as a result it's impossible to write a properly functional unit file.

Cheers,
Wol

Systemd 254 released

Posted Aug 1, 2023 14:28 UTC (Tue) by pizza (subscriber, #46) [Link] (37 responses)

> Because writing a trivial systemd unit file is not, in fact, trivial?

Um, it's a lot easier than writing a "trivial" init script, because there are far fewer footguns and error conditions that need to be handled.

Alternatively, if your init script is obfuscated to oblivion and you can't be bothered to look into it deeper, you can always just call it directly from a trivial unit file:

[Unit]
Description = MySuperSpecialDaemon
After = network.target

[Service]
Type = forking
ExecStart = /usr/local/etc/init.d/superspecial start
ExecStop = /usr/local/etc/init.d/superspecial stop

Systemd 254 released

Posted Aug 1, 2023 14:53 UTC (Tue) by Wol (subscriber, #4433) [Link] (36 responses)

Thanks.

I'll have to see whether I've tried stuff like that (I probably have :-(

The symptoms were that adding an execstop line, it seemed to be executed on daemon start, and did a scattergun kill of loads of processes including other processes that were starting up :-(

Removing the execstop fixed it, but of course the script is then not doing its job properly ...

(Oh, and no scripts are involved, it is the daemon that is invoked directly, whether it should be or not I don't know.)

Cheers,
Wol

Systemd 254 released

Posted Aug 1, 2023 15:33 UTC (Tue) by paulj (subscriber, #341) [Link] (35 responses)

Easiest way to convert, where your script is doing lots of prep work say (generating arguments, creating files, checking stuff ,whatever), is to just change it so it does /not/ daemonise the process it is launching. So your script shouldn't exit till the process does. Sometimes this is as simple as removing some kind of "--daemon" argument from the commandline.

Systemd does /not/ want your process to daemonise basically. Just let systemd manage the process.

Systemd 254 released

Posted Aug 1, 2023 21:12 UTC (Tue) by Wol (subscriber, #4433) [Link] (34 responses)

As I said, there's no script. The binary is invoked directly, and I don't know what it does. I suspect it daemonises, but that will involve digging into a load of C code.

Cheers,
Wol

Systemd 254 released

Posted Aug 1, 2023 23:29 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (33 responses)

It's a binary that's directly symlinked into /etc/rc?.d? How do you restart it or shut it down?

Systemd 254 released

Posted Aug 2, 2023 7:39 UTC (Wed) by Wol (subscriber, #4433) [Link] (32 responses)

> It's a binary that's directly symlinked into /etc/rc?.d? How do you restart it or shut it down?

As I said, I use a systemd unit file. In response to a comment that said writing such files was easy.

Except as soon as I put an execstop in there, it triggers a mad killing spree at boot that kills loads of unrelated services.

I don't know why (and haven't got round to trying to debug it).

Cheers,
Wol

Systemd 254 released

Posted Aug 2, 2023 7:58 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (28 responses)

The suggestion was that you write a systemd unit that runs the old sysv script, not that the program you were trying to run was a script.

Systemd 254 released

Posted Aug 2, 2023 10:39 UTC (Wed) by Wol (subscriber, #4433) [Link] (27 responses)

> The suggestion was that you write a systemd unit that runs the old sysv script, not that the program you were trying to run was a script.

And where did that come from? Not from me. Yes I think I can see the confusion, but at no point did *I* mention scripts at all. My comment was

"Because writing a trivial systemd unit file is not, in fact, trivial?"

Which it isn't. Writing my first unit file, and getting it to work with a simple ExecStart, wasn't easy. Then someone else added that ExecStop and the killing sprees started.

At some point I need to dig into the code to find out why this perfectly functional daemon does not function correctly with a very simple unit file :-(

Too many people seem to think that *their* normal applies to everyone else ...

Cheers,
Wol

Systemd 254 released

Posted Aug 2, 2023 11:37 UTC (Wed) by mb (subscriber, #50428) [Link] (7 responses)

> "Because writing a trivial systemd unit file is not, in fact, trivial?"
> Which it isn't.

Well, it actually is trivial for many many cases.

I really think you are hitting a corner case here and your application is doing something absolutely crazy.
We obviously can't debug that here on LWN.
But please stop saying that writing systemd unit files was hard, just because you have *one* case that might be a bit harder. In general it is easy.

Systemd 254 released

Posted Aug 2, 2023 14:21 UTC (Wed) by Wol (subscriber, #4433) [Link] (6 responses)

"not easy", or "hard".

Not necessarily the same thing.

But you can't expect a complete novice at writing them, to churn out several in the first hour, as the OP implied. My first attempt did nothing. I scrabbled around in the documentation, emailed the mailing list, and got exec start to work. It wasn't hard, but it was quite of lot of frustration trying to find out information.

Then as I say someone else added the exec stop and all hell broke loose.

It probably is true that writing unit files is pretty easy. But not to a novice. If I stuck TCL in front of you, even with excellent documentation you'd struggle, and it really is easy.

And it may also seem odd for someone on LWN so much, but I'm not that familiar with (or a fan of) "the Unix way". What little I know is what I've had to learn (and no, I wouldn't put Windows in my "favourite OS" list, either).

If you're a Unix fan, unit files probably felt familiar to you, even when meeting them for the first time. They still feel alien to me.

Cheers,
Wol

Systemd 254 released

Posted Aug 2, 2023 15:09 UTC (Wed) by mb (subscriber, #50428) [Link]

>If you're a Unix fan, unit files probably felt familiar to you

I'm sorry. That doesn't really make any sense. At all.

And you're also running in circles. Multiple times. We all understand that you do have trouble writing a unit file and didn't succeed so far. But that's far from being the norm.

Systemd 254 released

Posted Aug 2, 2023 23:01 UTC (Wed) by rschroev (subscriber, #4164) [Link] (4 responses)

If I understood everything correctly, you're trying to manage third-party software of which you don't really know how it expects to be managed properly. That's always going to be an uphill battle, regardless of which supervisor you use. Writing code, or config files in this case, doesn't work very well when you don't have a specification for what the code is supposed to do.

Systemd 254 released

Posted Aug 3, 2023 10:00 UTC (Thu) by Wol (subscriber, #4433) [Link] (3 responses)

Bingo.

This thread all started because the OP to whom I replied said that someone else could port 30 or so SysV init scripts to systemd unit files in a few hours. If you don't know what that script is doing, what the daemon it's starting is doing, not it's NOT that trivial. And you don't stand a hope in hell of knocking them out that quick.

And I just gave my experience as an example, where an attempt to start a binary with a systemd unit file blew up in my face spectacularly, precisely because I didn't know what exactly that binary was doing. I know there are landmines. I know I clearly stepped on one. I just haven't debugged which one, yet :-)

Cheers,
Wol

Systemd 254 released

Posted Aug 3, 2023 10:45 UTC (Thu) by paulj (subscriber, #341) [Link]

In my experience it _is_ pretty simple:

1. Open the init script
2. Find where it launches your daemon
3. Remove the argument telling the daemon to daemonise
4a. If this is the first one you're doing: Write the trivial systemd unit file to ExecStart that script
4b. If not the first, copy the trivial systemd unit file you've already got and change the ExecStart line.

Pretty much every daemon I've ever used, there is an argument to enable or disable daemonisation, cause a) developers want to be able to debug daemons (run under GDB usefully); b) there already are other init systems (inc. various SysVs Unixes in the olden days, like AIX, that already have various process managers; and other hacky homebrew and vendor-hacky process managers) that want processes to not daemonise; and so this is nearly always easy to figure out and set.

Systemd 254 released

Posted Aug 3, 2023 10:57 UTC (Thu) by bluca (subscriber, #118303) [Link]

There's 2 cases here: either you have nothing at all, and then this change to the generator doesn't affect you in any way, or you have an init script used through the deprecated generator. In the latter case, it is as simple as taking the generated unit and initially just shipping that as-is. That _is_ trivial, it's just a copy and a git add!
Why is it better? Because you can then iteratively improve on that, pick up recommended patterns, add sandboxing, etc etc, so that it can evolve and improve over time, rather than being ossified to the lowest common denominator of whatever silliness was happening back in the 80s.

Systemd 254 released

Posted Aug 3, 2023 11:17 UTC (Thu) by anselm (subscriber, #2796) [Link]

If you don't know what that script is doing, what the daemon it's starting is doing, not it's NOT that trivial.

And that should help convince anyone that allowing arbitrary shell code for daemon startup is, with hindsight, not the greatest of ideas. At least with systemd you know where you stand.

And you don't stand a hope in hell of knocking them out that quick.

For most if not all SysV init scripts it's not a huge problem to come up with simple service units that call them (nobody said you had to get rid of the init script altogether, after all). Systemd even does that automatically, for now anyway. That way you're not taking advantage of many of the helpful and convenient things systemd can do, but it's a start. If you're only interested in keeping the service working as before once the automatic support for SysV init scripts is removed from systemd, it may be all you need to do. You could even take a peek in /run/systemd/generator.late to see what you can find there.

It's when you want to replace the init script completely with a service unit that you need to look at the init script to see what exactly it does, and that of course takes time (especially with some of the more gnarly init scripts out there). I don't think anyone has seriously doubted that.

Systemd 254 released

Posted Aug 2, 2023 12:28 UTC (Wed) by jem (subscriber, #24231) [Link] (17 responses)

We need more details of what the program does. Does it daemonise? If it does, you need to add Type=forking to the unit file, if not, don't add a Type= line. (What happens if the program is started from an interactive shell? Does it go into the background?)

If the program daemonises, it probably writes its PID to a file. From man systemd.service: "If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can reliably identify the main process of the service."

If the program expects to shut down in some special way, like running the program binary with a special command line parameter, add this to the ExecStop= option. The ExecStop= option is not mandatory; the default is for systemd to send a SIGTERM signal to the process, followed by a SIGTERM (if needed), with the assumption that the program catches one of these signals and does a graceful shutdown.

Systemd 254 released

Posted Aug 2, 2023 14:37 UTC (Wed) by Wol (subscriber, #4433) [Link] (16 responses)

Thanks. I think you're pretty spot on.

I believe I've tried "forking = yes".

You do start and stop it with special command line arguments (--start and --stop would you believe :-), and yes with --start it does go into the background.

Beyond that, I need to investigate what's going on. I suspect the fact that it's backgrounding makes systemd think it's stopped and triggers the exec stop. And when it gets that, I suspect it gets confused as to what services are its own and what are not, and sends kills to the wrong processes. But that's a debugging session I need to get into when I have time. At present I just don't use exec stop.

Because if exec stop is enabled, I can guarantee a bunch of random services will fail to start, with systemd reporting they've been killed on startup :-(

Cheers,
Wol

Systemd 254 released

Posted Aug 2, 2023 23:14 UTC (Wed) by rschroev (subscriber, #4164) [Link] (15 responses)

> I suspect the fact that it's backgrounding makes systemd think it's stopped and triggers the exec stop.

If that's what you see then that's what happening, but it goes completely against my understanding of how systemd behaves. It is my understanding that systemd runs the ExecStop commands when it wants to stop the service, not when it detects that the service is stopped.

Systemd 254 released

Posted Aug 3, 2023 6:28 UTC (Thu) by zdzichu (guest, #17118) [Link] (14 responses)

Your understanding is incomplete. Quoting man systemd.service:
Also note that the stop operation is always performed if the service started successfully, even if the processes in the service terminated on their own or were killed.
Nevertheless, Wol's stories about one service stop killing unrelated services are hard to believe in. Unless he wrote ExecStop=/usr/bin/killall…

Systemd 254 released

Posted Aug 3, 2023 6:41 UTC (Thu) by jem (subscriber, #24231) [Link] (13 responses)

The key thing here is what *triggers* the invocation of the command in ExecStop. The command is run as a result of systemd actively wanting to stop the service, not because it has suddenly detected that the process has exited. The sentence from "man systemd.service" you quoted means that systemd does *not* check whether the program is alive or not, it runs it anyway.

Systemd 254 released

Posted Aug 3, 2023 7:35 UTC (Thu) by zdzichu (guest, #17118) [Link] (12 responses)

I disagree, ExecStop can be invoked if is defined and

  1. when sysadmin run systemctl stop unit;
  2. when systemd decides to stop unit;
  3. when unit exited/failed by itself.

By coincidence, systemd is open source so we don't have to guess!

Function service_enter_stop() runs ExecStop= if the section defined. service_enter_stop() is invoked in 10 cases:

  1. line 2264 – service did not start successfully and is not RemainAfterExit=true
  2. line 2294 – ExecStartPost failed
  3. line 2663 – command_next failed? (I don't know this mechanism)
  4. line 2692 – failed to start main task
  5. line 2801 – stop command is invoked
  6. line 3632 – PIDFile was specified but never wrote by the service
  7. line 3688 – Out of Memory condition manifested
  8. line 3815 – both main and control processes exited
  9. line 4004 – another failure of PIDFile
  10. line 4128 – RuntimeMaxSec= was reached

In summary, when ExecStop= is defined, it is run in multitude of cases, including service failure to start*. Not only when administrator requests service to stop.

* - I suspect failures to start are most often caused by wrong Type=. I once wrote a blog note with a table explaning the symptoms of mismatch.

Systemd 254 released

Posted Aug 3, 2023 8:33 UTC (Thu) by rschroev (subscriber, #4164) [Link] (11 responses)

I feel some of these conflict with the documentation. From https://www.freedesktop.org/software/systemd/man/systemd....

"Note that the commands specified in ExecStop= are only executed when the service started successfully first. They are not invoked if the service was never started at all, or in case its start-up failed, for example because any of the commands specified in ExecStart=, ExecStartPre= or ExecStartPost= failed (and weren't prefixed with "-", see above) or timed out."

That directly conflicts with your items 1, 2, and 4, and I feel it also conflicts with 6 and 9. And I don't see where it is documented that ExecStop= commands are called when systemd detects that processes have stopped (I haven't read *all* the documentation though, there's quite a lot of it); I feel generally while the documentation does explain what ExecStop does, it doesn't say enough about if and when ExecStop is triggered.

If the documentation is wrong, incomplete or unclear, I don't see how we're supposed to write correct unit files that work in all cases including edge cases. We shouldn't have to read the code to find out.

Systemd 254 released

Posted Aug 3, 2023 10:07 UTC (Thu) by Wol (subscriber, #4433) [Link]

I believe the systemd documentation itself warns of the consequences of "double daemonisation" or whatever it is in SysV scripts. There are various behaviours common (indeed, almost mandatory) under other init systems that are pathological to systemd. It would not surprise me if this binary assumes SysV (or indeed no init system at all) and behaves in a manner systemd neither likes nor expects.

What then triggers the mass killing I don't know. All I know is (1) it only happens if the systemd unit file contains an ExecStop. And (2) iirc the systemd logs actually point the finger straight at this binary!

At some point I need to fix it, but it's a load of reverse engineering I don't have time for :-(

Cheers,
Wol

Systemd 254 released

Posted Aug 3, 2023 10:35 UTC (Thu) by bluca (subscriber, #118303) [Link] (9 responses)

Writing documentation is hard - what is obvious to me as developer, can be entirely opaque to a given user, and it's difficult to tell when what is what. In this case, to me it's perfectly obvious that ExecStop is ran regardless of _how_ a unit went away, because we don't track commands being sent by admins/programs, we track cgroups. So, to me, "Note that the commands specified in ExecStop= are only executed when the service started successfully first." is clear. But to a user, this might be totally confusing and unexpected.

So, long story short, that manpage is here: https://github.com/systemd/systemd/blob/main/man/systemd.... please send a PR to reword so that it becomes clear to you as a user, and I'll happily review and merge it

Systemd 254 released

Posted Aug 3, 2023 11:11 UTC (Thu) by rschroev (subscriber, #4164) [Link] (8 responses)

I can't reword it because I don't have a good enough grasp on how it works. Every new piece of information seems to contradicts the previous one. And when the documentation doesn't match the code, I can't know which one of them (if any) is correct.

> to me it's perfectly obvious that ExecStop is ran regardless of _how_ a unit went away

But *when*? Is it triggered e.g. at the time you do 'systemctl stop', regardless of what happened to the service in the meantime? Or is triggered at the time systemd notices that the service went away? That's a big difference.

> To me, "Note that the commands specified in ExecStop= are only executed when the service started successfully first." is clear.

It seems clear to me too, but my interpretation is contradicted by the list in zdzichu's comment (https://lwn.net/Articles/940224/), which is correct as far as I can see. According to that, the commands in ExecStop= *are* executed even if the service did *not* start successfully, at the moment systemd detects that.

Systemd 254 released

Posted Aug 3, 2023 12:28 UTC (Thu) by Wol (subscriber, #4433) [Link] (3 responses)

I'm guessing that at least one pathological behaviour here is

(1) systemd fires off a process
(2) this process fires off the daemon and exits
(3) systemd sees the process has terminated, and runs ExecStop

That certainly is the sort of behaviour I assumed was behind the double-daemonisation, and why this fork option was added to the unit file - to prevent exactly this mis-understanding by systemd. I must admit that wasn't obvious from said documentation but it was all in there ...

And that's what's probably behind ExecStop being executed in my case (still doesn't explain the killing spree ...)

Cheers,
Wol

Systemd 254 released

Posted Aug 3, 2023 13:05 UTC (Thu) by gioele (subscriber, #61675) [Link] (1 responses)

> And that's what's probably behind ExecStop being executed in my case (still doesn't explain the killing spree ...)

Maybe the service was also launching other services or calling other init scripts?

In that case these newly spawn processes will live inside the cgroup of the service and are going to be killed by systemd once the main service is stopped.

Systemd 254 released

Posted Aug 3, 2023 15:37 UTC (Thu) by Wol (subscriber, #4433) [Link]

> In that case these newly spawn processes will live inside the cgroup of the service and are going to be killed by systemd once the main service is stopped.

Oh the joys of people not reading the thread. The killing spree is OF OTHER SERVICES which have nothing whatsoever to do with the service causing the problem ...

Ie something is seriously wrong somewhere. I just need to debug it.

Cjhers,
Wol

Systemd 254 released

Posted Aug 3, 2023 21:14 UTC (Thu) by malmedal (subscriber, #56172) [Link]

> And that's what's probably behind ExecStop being executed in my case (still doesn't explain the killing spree ...)

Wild guess. Some init-scripts kill process-groups instead of pids, so if it hit the wrong one...

Systemd 254 released

Posted Aug 3, 2023 16:55 UTC (Thu) by jem (subscriber, #24231) [Link] (3 responses)

The linked man page contains the following text for ExecStop: "Commands to execute to stop the service started via ExecStart". This hints that the purpose of ExecStop is to provide the commands to explicitly stop the service, triggered by some external event like systemctl stop.

But *when*? Is it triggered e.g. at the time you do 'systemctl stop', regardless of what happened to the service in the meantime? Or is triggered at the time systemd notices that the service went away? That's a big difference.

Looking at the code, it is called as a direct result of systemctl stop, which calls service_stop. If the service state is SERVICE_RUNNING, the service_stop function unconditionally calls service_enter_stop, which in turn executes the command specified in ExecStop (if any).

I don't see why it would be "totally confusing and unexpected" to a user that the commands in ExecStop are not run if the service fails to start. If the service failed to start, what's the point in trying to stop it? You don't try to close a file that you failed to open, either.

Systemd 254 released

Posted Aug 3, 2023 18:09 UTC (Thu) by rschroev (subscriber, #4164) [Link] (2 responses)

> I don't see why it would be "totally confusing and unexpected" to a user that the commands in ExecStop are not run if the service fails to start. If the service failed to start, what's the point in trying to stop it? You don't try to close a file that you failed to open, either.

But according to the source code, the ExecStop commands *are* run even if the service fails to start. Referring to zdzichu's comment somewhere in this thread (see https://lwn.net/Articles/940224/), line 2264 in service.c (in service_enter_running()) calls service_enter_stop() when a service fails to start. service_enter_stop() in turn executes the ExecStop commands.

I agree with you: I don't expect ExecStop to be triggered if a service fails to start. The documentation agrees, if I interpret it correctly. But unless both zdzichu and I are misreading the code, the code does trigger it in that case.

Systemd 254 released

Posted Aug 3, 2023 18:56 UTC (Thu) by bluca (subscriber, #118303) [Link] (1 responses)

They are not:

$ sudo systemd-run --quiet -t -p ExecStop="echo hello" false
$ sudo systemd-run --quiet -t -p ExecStop="echo hello" true
hello

Systemd 254 released

Posted Aug 4, 2023 7:47 UTC (Fri) by rschroev (subscriber, #4164) [Link]

And neither are the ExecStop= commands executed when ExecStartPost failed:

$ sudo systemd-run --quiet -t -p ExecStop="echo hello" -p ExecStartPost="false" true
-> gives no output

So it seems we both did misread the code. Good, that solves my worries.

Systemd 254 released

Posted Aug 2, 2023 17:18 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

It came from paulj in https://lwn.net/Articles/939956/ - he's suggesting that you write a systemd unit that just wraps the existing sysv script. You appear to have misinterpreted that as a suggestion that your program was a script.

Systemd 254 released

Posted Aug 2, 2023 9:15 UTC (Wed) by anselm (subscriber, #2796) [Link] (2 responses)

Except as soon as I put an execstop in there, it triggers a mad killing spree at boot that kills loads of unrelated services.

The approach where in your systemd unit file you use ExecStart= and ExecStop= to call your existing init script is generally pretty safe. In effect it's what systemd's SysV init compatibility layer does, too.

But of course whatever the init script does is outside systemd's control, and some init scripts can be pretty wild. What I'm wondering is why the behaviour you're seeing would in any way, shape, or form be systemd's fault. At its heart systemd is a fairly straightforward piece of software, certainly as far as launching services is concerned.

Systemd 254 released

Posted Aug 2, 2023 10:43 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

I'm not blaming systemd at all. I am merely observing that THAT IS WHAT HAPPENS. Why people can't tell the difference between an objective description of reality and a subjective allocation of blame I really don't understand! Sadly the latter seems to be the norm.

Which can make fixing problems EXTREMELY difficult - one only has to look at society to see the trouble this causes :-(

Cheers,
Wol

Systemd 254 released

Posted Aug 2, 2023 11:46 UTC (Wed) by anselm (subscriber, #2796) [Link]

I am merely observing that THAT IS WHAT HAPPENS.

To be precise, this is what happens to you, or at any rate what seems to have happened to you in one particular instance. It is certainly not the norm.

As I said, the usual way for systemd to support services which only have SysV init scripts is to construct basic systemd service units on the fly that essentially use ExecStart= and ExecStop= to invoke the init script, and that seems to work without a hitch in the vast majority of cases. Taking such an init script as a first approximation to/starting point for a free-standing service unit file would not be the dumbest of ideas (even though systemd prefers services that don't double-fork).

Systemd 254 released

Posted Aug 1, 2023 17:50 UTC (Tue) by zwenna (guest, #64777) [Link] (3 responses)

> This is the list of build failures caused by GCC 13, 345 build failures,…

New build failures do not break the software already installed on the system. Removing support for init scripts does, however.

> As already mentioned, init scripts support is fraught with issues that cannot be solved, so removing it and replacing it with native support will improve the situation overall.

Replacing init scripts with native service files surely improves the situation, but by removing support for init scripts before fixing the packages shipping only those you are effectively putting the burden of writing the service files on the local sysadmin (who might just be an end user).

Systemd 254 released

Posted Aug 1, 2023 18:05 UTC (Tue) by bluca (subscriber, #118303) [Link] (2 responses)

> New build failures do not break the software already installed on the system. Removing support for init scripts does, however.

Existing installations will not see anything removed, this is not a retroactive change. When your distro upgrades you'll get a new gcc that will require you to change your local software to compile again.

> Replacing init scripts with native service files surely improves the situation, but by removing support for init scripts before fixing the packages shipping only those you are effectively putting the burden of writing the service files on the local sysadmin (who might just be an end user).

Those packages will either be fixed or removed before shipping.

Systemd 254 released

Posted Aug 1, 2023 19:06 UTC (Tue) by zwenna (guest, #64777) [Link] (1 responses)

>> New build failures do not break the software already installed on the system. Removing support for init scripts does, however.

> Existing installations will not see anything removed, this is not a retroactive change. When your distro upgrades you'll get a new gcc that will require you to change your local software to compile again.

To compile again, but a new gcc does not stop the software I have already installed from running. Unlike systemd, where my init scripts will suddenly no longer be executed.

Do you see the difference?

Systemd 254 released

Posted Aug 1, 2023 19:19 UTC (Tue) by pizza (subscriber, #46) [Link]

> To compile again, but a new gcc does not stop the software I have already installed from running. Unlike systemd, where my init scripts will suddenly no longer be executed.

> Do you see the difference?

Not really. Things won't just "suddenly no longer be executed."

In both those scenarios, you chose to update your system to something newer/different. That means there's a long laundry list of things that have changed that could affect existing software. It's up to you (as the responsible party) to check the relevant release notes, test the stuff you care about, and make any corrections necessary to ensure what matters to you still works.

(As I've already demonstrated earlier, creating a systemd unit file that blindly wraps an existing init script is trivial. It's preferable to create a "fully native" replacement instead, which enables many additional benefits, but that can take more time. Most of which will be spent wrapping your head around what the init script is trying to do..)

Systemd 254 released

Posted Aug 4, 2023 14:32 UTC (Fri) by jwarnica (subscriber, #27492) [Link]

At this point, even if you don't know why the *n* versions of the basic c library are better, you just do it.

At some point the lazyness of simply writing a 5 line ini has to overwhelm any ideological attachments to 1000 line shell scripts.

Just do it.

Systemd 254 released

Posted Aug 4, 2023 16:49 UTC (Fri) by anselm (subscriber, #2796) [Link] (4 responses)

I still have fairly new software (less than 3 years old!) that only has SysV scripts. Yeah, I can easily writer a wrapper script, I know. However, having a tool to do it is nice.

You have that tool now. It's called systemd (or systemd-sysv-generator if you want to be picky; it even comes with its own man page). There's nothing wrong with copying its output against a rainy day.

So yep, removing it is a dick move.

I'd consider it a friendly suggestion to some people to get off their lazy fat behinds.

Systemd has been around as the de-facto standard for mainstream Linux distributions for more than a decade now. If in 2023 there are people who have the chutzpah to distribute commercial software that comes only with a SysV init script, they deserve a stern talking-to. (And if the software in question is FLOSS, here's your chance to do something nice for the community.)

Systemd 254 released

Posted Aug 6, 2023 3:34 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> Systemd has been around as the de-facto standard for mainstream Linux distributions for more than a decade now.

Yup. Just like Linux should drop anything that is older than a decade. Those developers having chutzpah not to move all their API use to io_uring in 2023!

Yeah, I understand that it can be at least a couple of orders of magnitude more complicated task. But still, the thing that users like is not breaking their stuff. And this particular change will absolutely break some users' workflows.

Also consider this, supporting systemd-sysv-generator requires almost no maintenance. Yet now many distros will probably have to scramble and keep patches on top of systemd to support this. And it will absolutely require an order of magnitude more aggregate man-hours to do that.

That's why it's a dick move.

Systemd 254 released

Posted Aug 6, 2023 11:12 UTC (Sun) by bluca (subscriber, #118303) [Link]

In case you never noticed, Linux (as in the kernel) breaks compatibility all the time. Every new release something breaks and need changes somewhere, whether it's a netlink message, or a uevent, or an LSM, etc etc. The answer is always 'deal with it'.

Systemd 254 released

Posted Aug 6, 2023 12:21 UTC (Sun) by anselm (subscriber, #2796) [Link]

That's why it's a dick move.

I disagree. At some point the training wheels need to come off the bicycle.

Properly-written systemd unit files make it possible for system services to avail themselves of all sorts of convenient systemd features which improve stability, security, and general service handling. Most of this remains unused by services which just keep using SysV init files with autogenerated service unit definitions. Programmers who, in 2023, insist on providing only SysV init files do their users an obvious disservice, and there is no reason anymore for systemd to be complicit in this.

Note that there is nothing at all preventing programmers from providing both a systemd service unit and a SysV init file for their system services. Nobody talks about forcing anyone to give up SysV init support completely. It's just that nowadays most people can do a lot better with proper systemd support rather than legacy SysV init files – and even if software authors are too lazy and irresponsible to acknowledge this, they can still provide a minimal 10-line generator-style service unit that just calls the SysV init script, big deal.

Systemd 254 released

Posted Aug 6, 2023 17:21 UTC (Sun) by tao (subscriber, #17563) [Link]

Surely if supporting systemd-sysv-generator requires almost no maintenance, it'd be a great target for newcomers who want a good way to get their feet wet and to get major kudos from the apparently enormous community of people who want to use initscripts instead of systemd units.

Systemd 254 released

Posted Jul 28, 2023 20:18 UTC (Fri) by lindi (subscriber, #53135) [Link]

Interesting and detailed changelog. Looking forward to try the soft-reboot and TPM2 stuff once it reaches Debian. Is there a way to try the confidential computing stuff on my own Intel hardware currently without having to add some patches to Linux?

Systemd 254 released

Posted Jul 28, 2023 21:17 UTC (Fri) by flussence (guest, #85566) [Link] (8 responses)

> […] the ability to send POSIX signals to services, […]

Odd to see systemd get a headline feature the daemontools lineage has had for decades.

Systemd 254 released

Posted Jul 28, 2023 21:55 UTC (Fri) by gdamjan (subscriber, #33634) [Link] (6 responses)

The service manager gained support for enqueuing POSIX signals to services that carry an additional integer value, exposing the sigqueue() system call. This is accessible via new D-Bus calls org.freedesktop.systemd1.Manager.QueueSignalUnit() and org.freedesktop.systemd1.Unit.QueueSignal(), as well as in systemctl via the new --kill-value= option.
I don't see that available in daemontools?!

Systemd 254 released

Posted Jul 30, 2023 2:58 UTC (Sun) by mirabilos (subscriber, #84359) [Link] (5 responses)

RTFM. svc -{pchaitk} sends signals to dæmons.

Yeah, this is ridiculous.

Systemd 254 released

Posted Jul 30, 2023 9:16 UTC (Sun) by derobert (subscriber, #89569) [Link] (4 responses)

Sending SIGTERM/QUIT/KILL/etc. like those flags is something that systemd has had forever.

This is something different (though related). It let's you additionally send an integer or pointer along with the signal. See the sigqueue manpage (the syscall the changelog mention): https://man7.org/linux/man-pages/man3/sigqueue.3.html

Systemd 254 released

Posted Jul 30, 2023 12:45 UTC (Sun) by lindi (subscriber, #53135) [Link] (3 responses)

Interesting, didn't know something like that existed. Any idea how it is typically used?

Systemd 254 released

Posted Jul 30, 2023 13:13 UTC (Sun) by bluca (subscriber, #118303) [Link]

systemd daemons support that as an alternative to IPC calls, currently it can be used to change log level or log target, trim memory, or dump malloc_info to journal

Systemd 254 released

Posted Jul 30, 2023 19:43 UTC (Sun) by mirabilos (subscriber, #84359) [Link] (1 responses)

Mostly 「svc -t /service/$foo」 to restart it.

Systemd 254 released

Posted Jul 30, 2023 22:43 UTC (Sun) by intelfx (subscriber, #130118) [Link]

That's not what the GP asked about, though.

Nobody doubts that svc can send signals, what's being discussed is the ability to send an accompanying item of data _together_ with the signal number.

Systemd 254 released

Posted Aug 1, 2023 15:35 UTC (Tue) by MarcB (guest, #101804) [Link]

If something seems totally odd, it is often a good idea to read on.

Sending signals is something that systemd always could do (systemctl kill).

But this is an interface to https://man7.org/linux/man-pages/man2/sigqueue.2.html, not to https://man7.org/linux/man-pages/man2/kill.2.html.

Systemd 254 released, exponential growing restart for intervals for Restart=

Posted Apr 16, 2024 13:36 UTC (Tue) by jdyrhovden (guest, #170935) [Link] (1 responses)

Based on the recent update, I'm curious about the methodology behind calculating the exponential increase in restart intervals. How is the growth factor determined? Additionally, I would appreciate an illustrative example demonstrating the calculation process for each step.

* The service activation logic gained new settings RestartSteps= and
RestartMaxDelaySec= which allow exponentially-growing restart
intervals for Restart=.

Systemd 254 released, exponential growing restart for intervals for Restart=

Posted Apr 16, 2024 14:32 UTC (Tue) by zdzichu (guest, #17118) [Link]

I written about this feature some time ago, here's the link to my blog:

https://enotty.pipebreaker.pl/posts/2024/01/how-systemd-e...

Two examples and a link to the formula in the source code.


Copyright © 2023, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds