On 4/9/19 2:24 PM, Lennart Poettering wrote: > On Di, 09.04.19 14:16, Cole Robinson (crobinso@xxxxxxxxxx) 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 logs >>>> 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 up >>>> 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 >>>> configuration...). >>> >>> This was supposed to be fixed https://bugzilla.redhat.com/show_bug.cgi?id=1631772. >>> 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 >>> https://bugzilla.redhat.com/show_bug.cgi?id=1290357. >>> >> >> 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 Thanks, Cole _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx