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