Bugzilla – Bug 1212119
Redis services disabled during upgrade
Last modified: 2024-01-23 20:30:02 UTC
Hi, I just updated some machines running Redis from 15.4 to 15.5. During the upgrade, all instantiated redis@ services were disabled - the zypp log shows: ``` # 2023-06-07 19:23:05 redis7-7.0.8-150500.1.2.x86_64.rpm installed ok # Additional rpm output: # See /usr/share/doc/packages/redis/README.SUSE to continue # Removed /etc/systemd/system/multi-user.target.wants/redis@default.service. # Removed /etc/systemd/system/redis.target.wants/redis@default.service. # 2023-06-07 20:42:55 redis7-7.0.8-150500.1.2.x86_64.rpm installed ok # Additional rpm output: # See /usr/share/doc/packages/redis/README.SUSE to continue # Removed /etc/systemd/system/redis.target.wants/redis@matomo.service. # Removed /etc/systemd/system/multi-user.target.wants/redis@matomo.service. ``` I had to manually re-enable and start them. Cheers, Georg P.S.: Whilst at it, the README.SUSE file referenced in the post script does not exist, the path should be "redis7" instead of "redis". :-) ``` crameleon@matomo:/home/crameleon> rpm -qf /usr/share/doc/packages/redis/README.SUSE error: file /usr/share/doc/packages/redis/README.SUSE: No such file or directory crameleon@matomo:/home/crameleon> rpm -ql redis7 |grep README.SUSE /usr/share/doc/packages/redis7/README.SUSE ```
Hello Georg and thank you for the report. I have updated the referenced file in the %post section and it will fixed in the next release. Regarding the issue with systemd, it's indeed odd. The package currently installed is redis7, was there previously redis?
Hello Danilo, thanks for getting back! That's correct, on Leap 15.4 "redis" was installed, and it got replaced with "redis7" automatically during the distribution upgrade to 15.5.
(In reply to Georg Pfuetzenreuter from comment #2) > Hello Danilo, > > thanks for getting back! That's correct, on Leap 15.4 "redis" was installed, > and it got replaced with "redis7" automatically during the distribution > upgrade to 15.5. This shouldn't happen, let me investigate the reason and try to reproduce it. redis7 is a new package that should be used by users that need/prefer redis7 over redis 6 provided in Leap 15.4 and shouldn't be installed by default.
Confirmed, I was able to reproduce this locally, at least when upgrading from 15.4 to 15.5. I'll see if it happens from 15.5 to 15.6, too.
Ok, I think I understand what's going on with this one. The old package named 'redis' is uninstalled, the new package named 'redis7' is installed. All services names 'redis@<instancename>' are disabled, since redis.service is no longer available, as it was removed when 'redis' is uninstalled. But zypper doesn't remove the 'redis@<instancename>' service files, so they just linger there, disabled. 'redis7' is installed, and the user is now free to manually re-enable the service files. I also learnt that the package is again named 'redis' for SP6, instead of 'redis7' as it had been renamed for SP5. This back-and-forth renaming would trigger this bug again. I'm currently seeing if there's something we can do here, but I'm not sure yet.
Request submitted, marking this as fixed.
Thank you!
SUSE-SU-2024:0200-1: An update that solves one vulnerability and has one security fix can now be installed. Category: security (important) Bug References: 1212119, 1216376 CVE References: CVE-2023-45145 Sources used: openSUSE Leap 15.5 (src): redis7-7.0.8-150500.3.9.1 Server Applications Module 15-SP5 (src): redis7-7.0.8-150500.3.9.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.