[systemd-devel] Hints for upgrading systemd on a running system

[Paul Menzel]

Dear Lennart and others,


Thank you for your prompt replies.


Am 20.02.2018 um 23:12 schrieb Lennart Poettering:
> On Di, 20.02.18 20:00, Paul Menzel (pmenzel+systemd-devel at molgen.mpg.de) wrote:

>> We finally are going to upgrade from a very old systemd version 27 from 2011
>> to the current systemd v237. (Historical reasons.)
>>
>> Anyway, I already was told about `systemctl daemon-reexec`, and we got it
>> working.
> 
> While we try to ensure that live upgrades of PID 1 like that work
> quite well, this is generally tested only for small steps. Jumping 6
> years ahead in one go is not something people typically test.

Indeed, but it seems to work. During the upgrade you have to make sure, 
that both versions are installed in parallel when doing `systemctl 
daemon-reexec`, so the old systemd still finds it dependencies/libraries 
and can terminate properly. Then the old version can be removed.

>> After that, looking at the output of `systemctl`, there are many units from
>> the old version, which were removed in the meantime.
>>
>> ```
>> $ systemctl --state=not-found
>>    UNIT                                 LOAD      ACTIVE   SUB DESCRIPTION
>> ● dev-hugepages.automount              not-found active   waiting
>> dev-hugepages.automount
>> ● dev-mqueue.automount                 not-found active   waiting
>> dev-mqueue.automount
>> ● sys-kernel-debug.automount           not-found active   waiting
>> sys-kernel-debug.automount
>> ● sys-kernel-security.automount        not-found active   waiting
>> sys-kernel-security.automount
>> ● auditd.service                       not-found inactive dead
>> auditd.service
>> ● console-kit-log-system-start.service not-found active   exited
>> console-kit-log-system-start.service
>> ● display-manager.service              not-found inactive dead
>> display-manager.service
>> ● hwclock-load.service                 not-found active   exited
>> hwclock-load.service
>> ● plymouth-quit-wait.service           not-found inactive dead
>> plymouth-quit-wait.service
>> ● plymouth-start.service               not-found inactive dead
>> plymouth-start.service
>> ● remount-rootfs.service               not-found active   exited
>> remount-rootfs.service
>> ● syslog.service                       not-found inactive dead
>> syslog.service
>> ● systemd-kmsg-syslogd.service         not-found active   running
>> systemd-kmsg-syslogd.service
>> ● systemd-remount-api-vfs.service      not-found active   exited
>> systemd-remount-api-vfs.service
>> ● systemd-sysusers.service             not-found inactive dead
>> systemd-sysusers.service
>> ● udev-retry.service                   not-found active   exited
>> udev-retry.service
>> ● udev-settle.service                  not-found active   exited
>> udev-settle.service
>> ● systemd-logger.socket                not-found active   listening
>> systemd-logger.socket
>> ● systemd-shutdownd.socket             not-found active   listening
>> systemd-shutdownd.socket
>> ● cryptsetup.target                    not-found active   active
>> cryptsetup.target
>> ● syslog.target                        not-found active   active
>> syslog.target
> 
> My recommendation: simply reboot. That should clean up everything
> properly.
> 
> Note that PID 1 itself is probably pretty Ok with such a massive
> update in one step, but the unit files have been rearranged quite a
> bit since then. Downstream distributions generally expect you to
> reboot even between single-step distro updates, but this becomes much
> more of a necessity if you jump even further.

But if reboot wouldn’t be an option, is there a way to get rid of 
not-found services?

> Note that systemd upstream currently requires kernel 3.13 at least
> which was released in 2014. Hence, if you update from a 2011 system
> you have to reboot anyway, already to update the kernel...

We already run later Linux Kernels, so that is not a problem. But thank 
you for mentioning it.

>> Do I need to stop those manually beforehand, or is there another way to
>> clean up?
>>
>> Is the recommended update procedure documented somewhere?
> 
> Usually distributions document that invididually as systemd is just
> one component of many that make up the distribution.

Understood.


Kind regards,

Paul