- Import commit ec72db9ee0f8ce061f83624d7148ff38a5993b11

3b1aa2f79f manager: reexecute on SIGRTMIN+25, user instances only
  fd46c81922 test: make sure to include all haveged unit files
- systemd.spec: reexec user manager instances on package updates

OBS-URL: https://build.opensuse.org/package/show/Base:System/systemd?expand=0&rev=1183

systemd-mini.changes

@@ -1,3 +1,13 @@
+-------------------------------------------------------------------
+Wed Sep  8 13:21:34 UTC 2021 - Franck Bui <fbui@suse.com>
+
+- Import commit ec72db9ee0f8ce061f83624d7148ff38a5993b11
+
+  3b1aa2f79f manager: reexecute on SIGRTMIN+25, user instances only
+  fd46c81922 test: make sure to include all haveged unit files
+
+- systemd.spec: reexec user manager instances on package updates
+
 -------------------------------------------------------------------
 Fri Sep  3 09:38:23 UTC 2021 - Franck Bui <fbui@suse.com>
 

systemd-mini.spec

@@ -26,7 +26,7 @@
 ##### WARNING: please do not edit this auto generated spec file. Use the systemd.spec! #####
 %define mini -mini
 %define min_kernel_version 4.5
-%define suse_version +suse.32.g40bda18e34
+%define suse_version +suse.35.gec72db9ee0
 %define _testsuitedir /usr/lib/systemd/tests
 
 %bcond_with     gnuefi
@@ -943,6 +943,15 @@ pam-config --add --systemd || :
 
 systemctl daemon-reexec || :
 
+# Reexecute user manager instances (if any). It is asynchronous but it
+# shouldn't be a problem in practice: a problem would arise only if
+# the new version of a user service has a brand new option that is
+# only understood by the latest version of the user manager and the
+# user service is started before the user manager get reexecuted. But
+# this case is very unlikely especially since we don't restart any
+# user service for now on.
+systemctl kill --kill-who=main --signal=SIGRTMIN+25 "user@*.service" || :
+
 %journal_catalog_update
 %tmpfiles_create
 

systemd-v249.4+suse.32.g40bda18e34.tar.xz

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:fddc0b0846c692af8bae3673728a0d95bfdcc448846c218e850b6b93e5493c2a
-size 7265384

systemd-v249.4+suse.35.gec72db9ee0.tar.xz

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:d581f2ec411b41826c395147fe9a040b0e916de7fdeeaae0681f43be8b92bb82
+size 7266280

systemd.changes

@@ -1,3 +1,13 @@
+-------------------------------------------------------------------
+Wed Sep  8 13:21:34 UTC 2021 - Franck Bui <fbui@suse.com>
+
+- Import commit ec72db9ee0f8ce061f83624d7148ff38a5993b11
+
+  3b1aa2f79f manager: reexecute on SIGRTMIN+25, user instances only
+  fd46c81922 test: make sure to include all haveged unit files
+
+- systemd.spec: reexec user manager instances on package updates
+
 -------------------------------------------------------------------
 Fri Sep  3 09:38:23 UTC 2021 - Franck Bui <fbui@suse.com>
 

systemd.spec

@@ -24,7 +24,7 @@
 %define bootstrap 0
 %define mini %nil
 %define min_kernel_version 4.5
-%define suse_version +suse.32.g40bda18e34
+%define suse_version +suse.35.gec72db9ee0
 %define _testsuitedir /usr/lib/systemd/tests
 
 %bcond_with     gnuefi
@@ -941,6 +941,15 @@ pam-config --add --systemd || :
 
 systemctl daemon-reexec || :
 
+# Reexecute user manager instances (if any). It is asynchronous but it
+# shouldn't be a problem in practice: a problem would arise only if
+# the new version of a user service has a brand new option that is
+# only understood by the latest version of the user manager and the
+# user service is started before the user manager get reexecuted. But
+# this case is very unlikely especially since we don't restart any
+# user service for now on.
+systemctl kill --kill-who=main --signal=SIGRTMIN+25 "user@*.service" || :
+
 %journal_catalog_update
 %tmpfiles_create