On 4/9/19 2:24 PM, Lennart Poettering wrote:
> On Di, 09.04.19 14:16, Cole Robinson (crobinso(a)redhat.com) wrote:
>> On 4/9/19 1:09 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote:
>>>> multipathd [...] And beyond that, this daemon is really ugly too: it
>>>> at high log levels during boot that it found no configuration and
>>>> hence nothing to do. Yes, obviously, but that's a reason to shut
>>>> and proceed quickly, not to complain loudly about that so that it
>>>> even appears on the scren (I mean srsly, this is the first thing I
>>>> saw when i booted from the fedora live media: a log message printed
>>>> all over the screen that multipathd has no working
>>> This was supposed to be fixed
>>> If not, please reopen that bug.
>>>> 5. libvirtd. Why is this running? Can't we make this socket
>>>> activatable + exit-on-idel?
>>> This was supposed to happen. See
>> This bug (briefly) describes why at present libvirt can't use socket
>> activation: https://bugzilla.redhat.com/show_bug.cgi?id=1326136
> Hmm, so that is a valid request I guess. But why can't libvirt do
> exit-on-idle? i.e. after it started up, after it noticed that it has no VMs to
> run, checks that there are no IPC requests pending, can't it just exit
> then and then rely on socket activation to be started again when it is
> needed the next time? That way libvirt would start at boot, but not
> stick around during normal runtime.
I don't know off hand of anything that would prevent it. Libvirt does
process events from running qemu VMs, but if there's no API users
connected to the daemon then I don't think libvirtd needs to be running;
it can handle restart and reconnecting to running VMs. That's
essentially the same behavior the session libvirtd instance uses which
auto shuts down after 30 seconds if there's no clients IIRC. danpb would
know best though, CCd
The reasons systemd libvirtd starts on boot is that it needs to perform
auto-start of various resources its manages. These resources don't have
any associated systemd unit so we can't use systemd for this purpose.
Ideally we would enable libvirtd to create systemd units for the resources
it manages that need autostart, but that's a significant bit of work.
So today we can't use systemd activation.