Bug 2210058
Summary: | libvirt rpm scripts reset systemd units | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 9 | Reporter: | lejeczek <peljasz> |
Component: | libvirt | Assignee: | Andrea Bolognani <abologna> |
libvirt sub component: | General | QA Contact: | yafu <yafu> |
Status: | CLOSED ERRATA | Docs Contact: | |
Severity: | high | ||
Priority: | unspecified | CC: | abologna, bstinson, jdenemar, jsuchane, jwboyer, lizhu, lmen, mkletzan, shdunne, virt-maint, yafu, ymankad |
Version: | CentOS Stream | Keywords: | AutomationTriaged, Reopened, Triaged |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-9.5.0-6.el9 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2023-11-07 08:31:41 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | 9.6.0 |
Embargoed: |
Description
lejeczek
2023-05-25 15:22:07 UTC
Could you please elaborate? Which unit got disabled? What was the version you upgraded from? I presume 'libvirt-daemon-driver-qemu-9.3.0-2.el9.x86_64' is the one you upgraded to. Did you have any specific manual setup? virtproxyd-tls.socket I found disabled after the upgrade. I can not reproduce this bug due to multiple reasons. There's still too much info missing even after it was requested. I still tried reproducing it the best I could, upgrading from 9.2.0-1.el9.x86_64.rpm: [root@localhost ~]# systemctl enable --now virtproxyd-tls.socket Created symlink /etc/systemd/system/sockets.target.wants/virtproxyd-tls.socket -> /usr/lib/systemd/system/virtproxyd-tls.socket. [root@localhost ~]# systemctl status virtproxyd-tls.socket * virtproxyd-tls.socket - Libvirt proxy TLS IP socket Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket; enabled; preset: disabled) Active: active (listening) since Thu 2023-06-01 09:50:11 EDT; 1min 43s ago Until: Thu 2023-06-01 09:50:11 EDT; 1min 43s ago Triggers: * virtproxyd.service Listen: [::]:16514 (Stream) Tasks: 0 (limit: 48952) Memory: 8.0K CPU: 1ms CGroup: /system.slice/virtproxyd-tls.socket Jun 01 09:50:11 localhost.localdomain systemd[1]: Listening on Libvirt proxy TLS IP socket. [root@localhost ~]# ps -ef | grep dnf root 4949 4663 20 09:51 pts/0 00:00:42 /usr/bin/python3 /usr/bin/dnf --enablerepo=* update -y --allowerasing root 35474 4960 0 09:54 pts/1 00:00:00 grep --color=auto dnf [root@localhost ~]# while killall -0 dnf; do sleep 1; done; systemctl status virtproxyd-tls.socket dnf: no process found * virtproxyd-tls.socket - Libvirt proxy TLS IP socket Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket; enabled; preset: disabled) Active: active (listening) since Thu 2023-06-01 09:50:11 EDT; 6min ago Until: Thu 2023-06-01 09:50:11 EDT; 6min ago Triggers: * virtproxyd.service Listen: [::]:16514 (Stream) Tasks: 0 (limit: 48952) Memory: 8.0K CPU: 1ms CGroup: /system.slice/virtproxyd-tls.socket Jun 01 09:50:11 localhost.localdomain systemd[1]: Listening on Libvirt proxy TLS IP socket. [root@localhost ~]# rpm -q libvirt libvirt-9.3.0-2.el9.x86_64 And it did not get disabled. Not in units, nothing custom. Version(s) I did mentioned. Please ask specifically what you want me to provide - I'll try my best to help. Take a look at this, here is a snippet from '--scripts': specifically for: ... postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then # Initial installation /usr/lib/systemd/systemd-update-helper install-system-units virtproxyd.socket virtproxyd-ro.socket virtproxyd-admin.socket virtproxyd-tls.socket virtproxyd-tcp.socket virtproxyd.service || : fi ... Now, trying to reproduce that, manually: -> $ /usr/lib/systemd/systemd-update-helper remove-system-units virtproxyd.service virtproxyd-ro.socket virtproxyd-admin.socket virtproxyd-tls.socket virtproxyd-tcp.socket virtproxyd.socket Removed "/etc/systemd/system/sockets.target.wants/virtproxyd.socket". Removed "/etc/systemd/system/sockets.target.wants/virtproxyd-tls.socket". -> $ systemctl status -l virtproxyd-tls.socket ○ virtproxyd-tls.socket - Libvirt proxy TLS IP socket Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket; enabled; preset: disabled) now: -> $ systemctl daemon-reload # which happens when os reboots, which was how I found it all. -> $ systemctl status -l virtproxyd-tls.socket ○ virtproxyd-tls.socket - Libvirt proxy TLS IP socket Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket; disabled; preset: disabled) (In reply to Peter Krempa from comment #1) > Could you please elaborate? > > Which unit got disabled? this we know, that's virtproxyd-tls.socket > What was the version you upgraded from? I presume 'libvirt-daemon-driver-qemu-9.3.0-2.el9.x86_64' is the one you upgraded to. Still missing the version you updated from. > Did you have any specific manual setup? Even properly filling in the bug template would answer this. (In reply to lejeczek from comment #5) > Take a look at this, here is a snippet from '--scripts': > specifically for: > ... > postinstall scriptlet (using /bin/sh): > > if [ $1 -eq 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then > # Initial installation This is only when installing previously not installed package. > /usr/lib/systemd/systemd-update-helper install-system-units > virtproxyd.socket virtproxyd-ro.socket virtproxyd-admin.socket > virtproxyd-tls.socket virtproxyd-tcp.socket virtproxyd.service || : > fi > ... > > Now, trying to reproduce that, manually: > > -> $ /usr/lib/systemd/systemd-update-helper remove-system-units > virtproxyd.service virtproxyd-ro.socket virtproxyd-admin.socket > virtproxyd-tls.socket virtproxyd-tcp.socket virtproxyd.socket > Removed "/etc/systemd/system/sockets.target.wants/virtproxyd.socket". > Removed "/etc/systemd/system/sockets.target.wants/virtproxyd-tls.socket". > You remove the units, effectively disabling them, > -> $ systemctl status -l virtproxyd-tls.socket > ○ virtproxyd-tls.socket - Libvirt proxy TLS IP socket > Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket; enabled; > preset: disabled) > > now: > -> $ systemctl daemon-reload # which happens when os reboots, which was how > I found it all. > then you reload the daemon, > -> $ systemctl status -l virtproxyd-tls.socket > ○ virtproxyd-tls.socket - Libvirt proxy TLS IP socket > Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket; > disabled; preset: disabled) and then the unit is disabled. I don't see what you want to show here, sorry. What I showed were obvious snippets & I was saying that that what upgrade did/does. Part(s) scriptlets probably happened, took place - I most likely was using penultimate release to this latest one - as I think I see 'libvirt-daemon-proxy' being a "brand-new" introduction package in the 9.3.0-2.el9 It reproduces in my lab - when I downgrade, repos supply me with 9.0.0-7.el9 version. I have: libvirt-libs-9.0.0-7.el9.x86_64 libvirt-client-9.0.0-7.el9.x86_64 libvirt-daemon-9.0.0-7.el9.x86_64 libvirt-daemon-driver-storage-core-9.0.0-7.el9.x86_64 libvirt-daemon-driver-network-9.0.0-7.el9.x86_64 libvirt-daemon-driver-nwfilter-9.0.0-7.el9.x86_64 libvirt-daemon-config-nwfilter-9.0.0-7.el9.x86_64 libvirt-daemon-config-network-9.0.0-7.el9.x86_64 libvirt-daemon-driver-storage-disk-9.0.0-7.el9.x86_64 libvirt-daemon-driver-storage-iscsi-9.0.0-7.el9.x86_64 libvirt-daemon-driver-storage-logical-9.0.0-7.el9.x86_64 libvirt-daemon-driver-storage-mpath-9.0.0-7.el9.x86_64 libvirt-daemon-driver-storage-rbd-9.0.0-7.el9.x86_64 libvirt-daemon-driver-storage-scsi-9.0.0-7.el9.x86_64 libvirt-daemon-driver-storage-9.0.0-7.el9.x86_64 libvirt-daemon-driver-interface-9.0.0-7.el9.x86_64 libvirt-daemon-driver-nodedev-9.0.0-7.el9.x86_64 libvirt-daemon-driver-qemu-9.0.0-7.el9.x86_64 libvirt-daemon-driver-secret-9.0.0-7.el9.x86_64 libvirt-9.0.0-7.el9.x86_64 I upgrade, having that "older" version up & running, both 'virtproxyd.socket' & 'virtproxyd-tls.socket' enabled & up and immediately - after successful update - I find: virtproxyd-tls.socket - DISABLED. OK, now we're getting somewhere, thank you. So virtproxyd was split from libvirt-daemon into libvirt-daemon-proxy since v9.1.0. When updating libvirt from older version the new package libvirt-daemon-proxy gets installed. And since from that package's point of view (or more precisely from the scriptlet) it is not visible that this is an update rather than an install. So the scriptlet runs systemd_post which bubbles down to: systemd preset --no-reload preset virtproxyd.socket virtproxyd-ro.socket virtproxyd-admin.socet virtproxyd-tls.socket virtproxyd-tcp.socket virtproxyd.service which would not happen on further updates. However the system preset is to disable everything not explicitly listed as enabled (see /usr/lib/systemd/system-preset/99-default-disable.preset) and hence the enabled service gets disabled. Since this is deciphered we can talk about the possibilities. One thing would be to not use %systemd_post for this unit and maybe all other -tls.socket units. That would violate the untold premise of using presets for systemd units. Another could be to not include the "disable *" in the distro package. I'm not sure what the reason is behind that and I'm not the right one to say. The last one would be to "just let it go", but since RHEL 9.2 does not have the new package yet and we have some time until RHEL 9.3 is released, so I think one of the first two is the right way to go. I'll try to propose the change upstream and will see where does the discussion take us. Patches posted upstream. https://listman.redhat.com/archives/libvir-list/2023-July/240723.html Patches pushed upstream. commit a7bc8d16062c786eae298b3db3ee2f0d06b12151 Author: Andrea Bolognani <abologna> Date: Wed Jul 5 18:48:32 2023 +0200 rpm: Switch to new macros for handling of systemd units In most cases the replacement is straightforward, with the biggest difference being that we now schedule restarts during %pre instead of %post. This also means that we can get rid of %post for most packages, reducing the number of scriptlets that need to run during install/upgrade. Notable exceptions are libvirt-guests.service, where we stop using the standard systemd macros to adopt our custom ones, as well as the virtlogd and virtlockd services, where the reload operation is moved from %postun to %posttrans. https://bugzilla.redhat.com/show_bug.cgi?id=2210058 Signed-off-by: Andrea Bolognani <abologna> Reviewed-by: Martin Kletzander <mkletzan> commit 3bfc76a953c24793c2193768cca68d428490c01a Author: Andrea Bolognani <abologna> Date: Wed Jul 5 18:07:34 2023 +0200 rpm: Introduce new macros for handling of systemd units systemd provides a number of standard RPM macros but they don't quite satisfy our requirements, as evidenced by the fact that we have already built some custom tooling around them. Scenarios that the standard macros don't cover and that we're already addressing with our custom ones: * for some services (libvirtd, virtnetworkd, virtnwfilterd) there are multiple conditions that might lead to a restart, and we want to make sure that they're not needlessly restarted several times per transaction; * some services (virtlogd, virtlockd) must not be restarted during upgrade, so we have to reload them instead. Issues that neither the standard macros nor our custom ones address: * presets for units should be applied when the unit is first installed, not when the package that contains it is. The package split that happened in 9.1.0 highlighted why this last point is so important: when virtproxyd and its sockets were moved from libvirt-daemon to the new libvirt-daemon-proxy package, upgrades from 9.0.0 caused presets for them to be applied. On a platform such as Fedora, where modular daemons are the default, this has resulted in breaking existing deployments in at least two scenarios. The first one is machines that were configured to use the monolithic daemon, either because the local admin had manually changed the configuration or because the installation dated back to before modular daemons had become the default. In this case, virtproxyd.socket being enabled resulted in a silent conflict with libvirtd.socket, which by design shares the same path, and thus a completely broken setup. The second one is machines where virtproxy-tls.socket, which is disabled by default, had manually been enabled: in this case, applying the presets resulted in it being disabled and thus a loss of remote availability. Note that these are just two concrete scenarios, but the problem is more generic. For example, if we were to add more units to an existing package, per the current approach they wouldn't have their presets applied. The new macros are designed to avoid all of the pitfalls mentioned above. As a bonus, they're also simpler to use: where the current approach requires restarts and other operations to be handled separately, the new one integrates the two so that, for each scriptlet, a single macro call is needed. https://bugzilla.redhat.com/show_bug.cgi?id=2210058 Signed-off-by: Andrea Bolognani <abologna> Reviewed-by: Martin Kletzander <mkletzan> v9.6.0-rc1-8-ga7bc8d1606 CentOS Stream 9 backport prepared. https://gitlab.com/redhat/centos-stream/src/libvirt/-/merge_requests/8 This was reviewed by the RHEL voting members and approved. Reproduced with libvirt-daemon-9.5.0-5.el9.x86_64. Steps: 1.Install libvirt 9.0.0-10.3.el9_2.x86_64 pkgs 2.Check the default enabled status of virtproxyd{,-tcp, -tls}.socket: # for drv in virtproxyd{,-tcp,-tls}; do systemctl is-enabled ${drv}.socket ; done enabled disabled disabled 2.Disable virtproxyd.socket, enable virtproxyd-tcpsocket,virtproxyd-tls.socket: #systemctl disable virtproxyd.socket #systemctl enable virtproxyd-tcp.socket #systemctl enable virtproxyd-tls.socket 3.Check the enabled status of virtproxyd*.socket again: # for drv in virtproxyd{,-tcp,-tls}; do systemctl is-enabled ${drv}.socket ; done enabled disabled disabled 4.Upgrade to libvirt 9.5.0-5: # yum -y upgrade libvirt*9.5.0-5* ... Running scriptlet: libvirt-daemon-proxy-9.5.0-5.el9.x86_64 7/95 Removed "/etc/systemd/system/sockets.target.wants/virtproxyd-tcp.socket". Removed "/etc/systemd/system/sockets.target.wants/virtproxyd-tls.socket". Created symlink /etc/systemd/system/sockets.target.wants/virtproxyd.socket → /usr/lib/systemd/system/virtproxyd.socket. ... 5.Check the enabled status of virtproxyd*.socket, all the service were preset after step 4: # for drv in virtproxyd{,-tcp,-tls}; do systemctl is-enabled ${drv}.socket ; done enabled disabled disabled Pre-verified with libvirt-9.5.0-6.el9.x86_64. Test steps are the same as comment #22, and the virtproxyd*.socket service are not preset after upgrading to libvirt-9.5.0-6.el9.x86_64. (In reply to yafu from comment #22) > 2.Disable virtproxyd.socket, enable virtproxyd-tcpsocket,virtproxyd-tls.socket: > #systemctl disable virtproxyd.socket > #systemctl enable virtproxyd-tcp.socket > #systemctl enable virtproxyd-tls.socket > > 3.Check the enabled status of virtproxyd*.socket again: > # for drv in virtproxyd{,-tcp,-tls}; do systemctl is-enabled ${drv}.socket ; done > enabled > disabled > disabled This was a copy-paste error, right? Based on the command you executed immediately before this one, the output should have been disabled enabled enabled instead. (In reply to Andrea Bolognani from comment #24) > (In reply to yafu from comment #22) > > 2.Disable virtproxyd.socket, enable virtproxyd-tcpsocket,virtproxyd-tls.socket: > > #systemctl disable virtproxyd.socket > > #systemctl enable virtproxyd-tcp.socket > > #systemctl enable virtproxyd-tls.socket > > > > 3.Check the enabled status of virtproxyd*.socket again: > > # for drv in virtproxyd{,-tcp,-tls}; do systemctl is-enabled ${drv}.socket ; done > > enabled > > disabled > > disabled > > This was a copy-paste error, right? Based on the command you executed > immediately before this one, the output should have been > > disabled > enabled > enabled > > instead. Yes, it should be the following output after step3: disabled enabled enabled Thanks for pointing it. Hi Andrea, I found the default enabled status of virtqemud.socket is 'disabled' with libvirt-9.5.0-6.el9.x86_64 while the default enabled status of virtqemud.socke is 'enabled' with libvirt-9.0.0-10.el9_2.x86_64. Could you help to check it please. Thanks. (In reply to yafu from comment #26) > Hi Andrea, > > I found the default enabled status of virtqemud.socket is 'disabled' with > libvirt-9.5.0-6.el9.x86_64 > while the default enabled status of virtqemud.socke is 'enabled' with > libvirt-9.0.0-10.el9_2.x86_64. > Could you help to check it please. Thanks. Is this from a new installation, or an upgrade? If the latter, what was the status of the socket before performing the upgrade? I have just tried installing libvirt 9.7.0 on Fedora 38 (the systemd unit handling code is exactly the same) and it behaves the way I expect: Running scriptlet: libvirt-daemon-driver-qemu-9.7.0-1.fc38.x86_64 Created symlink /etc/systemd/system/multi-user.target.wants/virtqemud.service → /usr/lib/systemd/system/virtqemud.service. Created symlink /etc/systemd/system/sockets.target.wants/virtlogd.socket → /usr/lib/systemd/system/virtlogd.socket. Created symlink /etc/systemd/system/sockets.target.wants/virtlockd.socket → /usr/lib/systemd/system/virtlockd.socket. Created symlink /etc/systemd/system/sockets.target.wants/virtqemud.socket → /usr/lib/systemd/system/virtqemud.socket. Created symlink /etc/systemd/system/sockets.target.wants/virtqemud-ro.socket → /usr/lib/systemd/system/virtqemud-ro.socket. Created symlink /etc/systemd/system/sockets.target.wants/virtqemud-admin.socket → /usr/lib/systemd/system/virtqemud-admin.socket. After installation, the status for virtqemud and its sockets is the expected one too: $ systemctl list-unit-files | grep virtqemud virtqemud.service enabled enabled virtqemud-admin.socket enabled disabled virtqemud-ro.socket enabled disabled virtqemud.socket enabled disabled (In reply to Andrea Bolognani from comment #27) > (In reply to yafu from comment #26) > > Hi Andrea, > > > > I found the default enabled status of virtqemud.socket is 'disabled' with > > libvirt-9.5.0-6.el9.x86_64 > > while the default enabled status of virtqemud.socke is 'enabled' with > > libvirt-9.0.0-10.el9_2.x86_64. > > Could you help to check it please. Thanks. > > Is this from a new installation, or an upgrade? If the latter, what > was the status of the socket before performing the upgrade? > > I have just tried installing libvirt 9.7.0 on Fedora 38 (the systemd > unit handling code is exactly the same) and it behaves the way I > expect: > > Running scriptlet: libvirt-daemon-driver-qemu-9.7.0-1.fc38.x86_64 > Created symlink > /etc/systemd/system/multi-user.target.wants/virtqemud.service → > /usr/lib/systemd/system/virtqemud.service. > Created symlink /etc/systemd/system/sockets.target.wants/virtlogd.socket → > /usr/lib/systemd/system/virtlogd.socket. > Created symlink /etc/systemd/system/sockets.target.wants/virtlockd.socket > → /usr/lib/systemd/system/virtlockd.socket. > Created symlink /etc/systemd/system/sockets.target.wants/virtqemud.socket > → /usr/lib/systemd/system/virtqemud.socket. > Created symlink > /etc/systemd/system/sockets.target.wants/virtqemud-ro.socket → > /usr/lib/systemd/system/virtqemud-ro.socket. > Created symlink > /etc/systemd/system/sockets.target.wants/virtqemud-admin.socket → > /usr/lib/systemd/system/virtqemud-admin.socket. > > After installation, the status for virtqemud and its sockets is the > expected one too: > > $ systemctl list-unit-files | grep virtqemud > virtqemud.service enabled enabled > virtqemud-admin.socket enabled disabled > virtqemud-ro.socket enabled disabled > virtqemud.socket enabled disabled I checked it again on a new installed env. And the status for virtqemud* services are the same as you pasted above. So I checked the history, I found I executed 'virsh preset virtqemud.socket' manually and then I found the default status of virtqemud.socket became to 'disabled' after upgrading libvirt pkgs. # systemctl preset virtqemud.socket Removed "/etc/systemd/system/sockets.target.wants/virtqemud.socket". So it's the expected result, right? (In reply to yafu from comment #28) > (In reply to Andrea Bolognani from comment #27) > > $ systemctl list-unit-files | grep virtqemud > > virtqemud.service enabled enabled > > virtqemud-admin.socket enabled disabled > > virtqemud-ro.socket enabled disabled > > virtqemud.socket enabled disabled > > I checked it again on a new installed env. And the status for virtqemud* > services are the same as you pasted above. Okay, that's good :) > So I checked the history, I found I executed 'virsh preset > virtqemud.socket' manually and then I found the default status of > virtqemud.socket became to 'disabled' after upgrading libvirt pkgs. > > # systemctl preset virtqemud.socket > Removed "/etc/systemd/system/sockets.target.wants/virtqemud.socket". Yeah, the preset for most sockets is to be disabled, which is confusing but ultimately not a problem. In the case of virtqemud, for example, we have $ cat /usr/lib/systemd/system/virtqemud.service ... [Install] Also=virtlogd.socket Also=virtlockd.socket Also=virtqemud.socket Also=virtqemud-ro.socket Also=virtqemud-admin.socket All the sockets listed as Also= are automatically enabled when virtqemud.service is, so it all works fine in the end. > So it's the expected result, right? In your case, you applied the preset for virtqemud.socket, which disabled it. Then ran the upgrade, which didn't touch any of the settings for existing units. In this scenario, it's expected that after the upgrade virtqemud.socket would be disabled. (In reply to Andrea Bolognani from comment #29) > Yeah, the preset for most sockets is to be disabled, which is > confusing but ultimately not a problem. > > In the case of virtqemud, for example, we have > > $ cat /usr/lib/systemd/system/virtqemud.service > ... > [Install] > Also=virtlogd.socket > Also=virtlockd.socket > Also=virtqemud.socket > Also=virtqemud-ro.socket > Also=virtqemud-admin.socket > > All the sockets listed as Also= are automatically enabled when > virtqemud.service is, so it all works fine in the end. I have now created a pull request against the Fedora package that ships the systemd presets to try and make things less confusing. https://src.fedoraproject.org/rpms/fedora-release/pull-request/281 (In reply to Andrea Bolognani from comment #30) > (In reply to Andrea Bolognani from comment #29) > > Yeah, the preset for most sockets is to be disabled, which is > > confusing but ultimately not a problem. > > > > In the case of virtqemud, for example, we have > > > > $ cat /usr/lib/systemd/system/virtqemud.service > > ... > > [Install] > > Also=virtlogd.socket > > Also=virtlockd.socket > > Also=virtqemud.socket > > Also=virtqemud-ro.socket > > Also=virtqemud-admin.socket > > > > All the sockets listed as Also= are automatically enabled when > > virtqemud.service is, so it all works fine in the end. > > I have now created a pull request against the Fedora package that > ships the systemd presets to try and make things less confusing. > > https://src.fedoraproject.org/rpms/fedora-release/pull-request/281 Thanks for your quick reply. Do we need to cover this pr in the bug? (In reply to yafu from comment #31) > (In reply to Andrea Bolognani from comment #30) > > I have now created a pull request against the Fedora package that > > ships the systemd presets to try and make things less confusing. > > > > https://src.fedoraproject.org/rpms/fedora-release/pull-request/281 > > Thanks for your quick reply. Do we need to cover this pr in the bug? No, that won't be necessary. I will make things nicer for libvirt users who want to change their machine's configuration from the default, but the RPM macros introduced in the patches fixing this bug are carefully written so that the correct behavior will occur even with the current systemd presets. (In reply to Andrea Bolognani from comment #32) > (In reply to yafu from comment #31) > > (In reply to Andrea Bolognani from comment #30) > > > I have now created a pull request against the Fedora package that > > > ships the systemd presets to try and make things less confusing. > > > > > > https://src.fedoraproject.org/rpms/fedora-release/pull-request/281 > > > > Thanks for your quick reply. Do we need to cover this pr in the bug? > > No, that won't be necessary. I will make things nicer for libvirt > users who want to change their machine's configuration from the > default, but the RPM macros introduced in the patches fixing this bug > are carefully written so that the correct behavior will occur even > with the current systemd presets. Got it. Thanks. (In reply to Andrea Bolognani from comment #30) > (In reply to Andrea Bolognani from comment #29) > > Yeah, the preset for most sockets is to be disabled, which is > > confusing but ultimately not a problem. > > > > In the case of virtqemud, for example, we have > > > > $ cat /usr/lib/systemd/system/virtqemud.service > > ... > > [Install] > > Also=virtlogd.socket > > Also=virtlockd.socket > > Also=virtqemud.socket > > Also=virtqemud-ro.socket > > Also=virtqemud-admin.socket > > > > All the sockets listed as Also= are automatically enabled when > > virtqemud.service is, so it all works fine in the end. > > I have now created a pull request against the Fedora package that > ships the systemd presets to try and make things less confusing. > > https://src.fedoraproject.org/rpms/fedora-release/pull-request/281 Filed a bug in JIRA to track this issue: https://issues.redhat.com/browse/RHEL-3231 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: libvirt security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:6409 |