• Re: Bug#1109119: upgrade-reports: systemctl occasionally fails loading

    From Richard Lewis@21:1/5 to Helmut Grohne on Sat Jul 12 00:10:01 2025
    Helmut Grohne <helmut@subdivi.de> writes:

    while working on a bookworm -> trixie upgrade failure, I noticed a strange line
    showing up.

    | Preparing to unpack .../openssh-server_1%3a10.0p1-5_amd64.deb ...
    | systemctl: error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

    deb-systemd-invoke is part of init-system-helpers and therefore
    essential. It calls out to systemctl, which is not essential but for all practical matters we really should be treating it as if it was and
    maintainer scripts expect it to work at all times.

    In practice, this means that systemctl cannot be expected to work in maintainer scripts.

    forgive the stupid question: does this mean there is a wider risk that
    this might affect other packages? "systemctl is de-facto essential but
    not marked as such" sounds quite dangerous


    We typically reboot after a dist upgrade (at least that's what release
    notes strongly recommend)

    (surprisingly, the release-notes actually dont remind anyone to reboot explicitly - there is only an implicit statement in https://www.debian.org/releases/trixie/release-notes/issues.en.html#things-to-do-before-rebooting

    probably that should be improved regardless of this)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Hofstaedtler@21:1/5 to All on Sat Jul 12 00:40:01 2025
    * Richard Lewis <richard.lewis.debian@googlemail.com> [250712 00:04]:
    Helmut Grohne <helmut@subdivi.de> writes:

    while working on a bookworm -> trixie upgrade failure, I noticed a strange line
    showing up.

    | Preparing to unpack .../openssh-server_1%3a10.0p1-5_amd64.deb ...
    | systemctl: error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

    deb-systemd-invoke is part of init-system-helpers and therefore
    essential. It calls out to systemctl, which is not essential but for all
    practical matters we really should be treating it as if it was and
    maintainer scripts expect it to work at all times.

    In practice, this means that systemctl cannot be expected to work in
    maintainer scripts.

    forgive the stupid question: does this mean there is a wider risk that
    this might affect other packages?

    Yes.

    "systemctl is de-facto essential but not marked as such" sounds quite dangerous

    Not really. You can consider it pseudo-essential on a lot of
    systems, but certainly not all.

    It would certainly suck if the common case was broken. The package
    containing systemctl not being marked Essential: yes is however,
    correct.

    I was somewhat hoping this is caused by the existing upgrade issue
    which Helmut is working on AFAIU. Was it proven that this is not the
    same problem?

    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)