On Wed, Nov 29, 2023 at 12:30:19PM -0600, Andrea Bolognani wrote:
On Wed, Nov 29, 2023 at 10:49:23AM +0000, Richard W.M. Jones wrote:On Wed, Nov 29, 2023 at 05:44:59AM -0500, Andrea Bolognani wrote: > On Wed, Nov 29, 2023 at 10:09:36AM +0000, Richard W.M. Jones wrote: > > Why is it exactly that the socket doesn't work after installation, but > > does work after reboot? On my laptop, the socket unit is set to > > "disabled", yet libvirt works fine (since the laptop has been rebooted > > since libvirt was installed, I guess). Shouldn't the command be > > "systemctl enable virtqemud.socket --now"? > > It's a distro policy. > > I assume you're running Fedora/RHEL on your laptop, and the policy > there is that services (or sockets) should not be started right after > a package is installed. Debian has the opposite policy. I think this is a very weird choice (for Fedora). Why would installing the package not start the service, but then the service would be started without further intervention after reboot? It's the opposite of predictable behaviour.I believe that the rationale is that a newly-installed service might need to be configured before it can work correctly/securely. Not starting it right away provides a temporal window that can be used to perform the initial configuration, and which is entirely under the local admin's control.
One could argue that the maintainer should be able to decide that based on whether the service is configured with safe defaults from the get go. Not to mention that your rationale is void once someone reboots. On the other hand when you start only the sockets you can still configure the service before connecting to it. I feel like "enable but don't start" is a middle ground between seamless user experience and safe defaults. It does none of that. I think either default would be better than the current state, but that's swaying from what we're trying to fix here.
-- Andrea Bolognani / Red Hat / Virtualization
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
