Bug#1056137: systemd: downgrading systemd packages kills off the desktop environment

[Michael Biebl]

Control: severity -1 wishlist
Control: tags -1 + help

Hi Christoph

On Fri, 17 Nov 2023 14:40:05 +0100 Christoph Anton Mitterer 
<calestyo at scientia.org> wrote:
> Package: systemd
> Version: 255~rc2-1
> Severity: important
> 
> Hey.
> 
> Because of #1056135 I was downgradin systemd/udev packages to 254.5-1.
> While apt was still running, this causes the whole desktop environment
> (I use cinnamon) to be killed (and all processes in it ;-) ).
> 
> Tried it twice, happened twice.

I acknowledge that not being able to downgrade is a nuisance.
systemd is not special in that regard though. Quite a few packages that 
I now need to convert their on-disk-files on upgrades to a new format 
which is not easily reversible.
None of those packages have explicit maintainer scripts code though, 
which would prevent a downgrade.
So we do not plan to add maintainer scripts code in systemd either.

My guess is, that the failures you encountered are due to the following 
change in v255:

"""
         Service Manager:

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

This is just a guess though.
There is only so much we can do as Debian systemd team. If that issue is 
important to you, please consider investigating this further and 
providing patches, ideally via a MR on salsa.

Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20240228/956a9c6c/attachment.sig>