Re: [vdagent-linux v2 1/2] vdagent: Silently ignore missing spicevmc device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Wed, Jan 30, 2019 at 01:46:21PM +0100, Jakub Janku wrote:
> > On Wed, Jan 30, 2019 at 1:23 PM Christophe Fergeau <cfergeau@xxxxxxxxxx>
> > wrote:
> > >
> > > On most distros, spice-vdagent will be autostarted as part of the
> > > startup of the desktop environment session. This is done by
> > > spice-vdagent.desktop, which has no way of checking if we are in a virt
> > > environment with the needed devices present.
> > >
> > > Currently, if /dev/virtio-ports/com.redhat.spice.0 is missing, we log an
> > > error in syslog, and exit with an error exit code. This is too noisy
> > > when autostarting it on a bare metal machine which have no use for
> > > spice-vdagent. This reverts 0159111b to get rid of these warnings in the
> > > session's logs
> > >
> > > https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/12
> > >
> > > Signed-off-by: Christophe Fergeau <cfergeau@xxxxxxxxxx>
> > > ---
> > > Changes since v1:
> > > - switched to g_debug as g_print would show in journalctl
> > 
> > Why is this wanted? What if the vdagent is running in a virtualized
> > system and the device is missing? In that case, I would expect to see
> > at least some info in the system journal.
> > So why not just lowering the log level to something like LOG_INFO?
> 
> I don't know what the expectations are with respect to the amount of
> logging in the bare metal case. To be honest, we should not even be
> trying to load spice-vdagent in that situation. So logging anything is
> just going to be noise.
> 
> Rather than silencing the warning, I tried to find other solutions, but
> I could not think of anything. We could say we don't want to try to run
> spice-vdagent if spice-vdagentd is not running, however these days
> spice-vdagentd is socket activated, and it's spice-vdagent which
> triggers the actual start of spice-vdagentd.
> 
> Then I tried to make use of systemd user session support to start
> spice-vdagent rather than relying on /etc/xdg/autostart, however there
> were 2 issues that I'm not sure are going to be easy to solve:
> - the agent needs an X display, so we need to express in a systemd user
>   unit that xorg needs to be running
> - I tried a unit file which tries to start spice-vdagent only if the
>   needed device is present, but then spice-vdagentd fails to get the session
>   info
>   from systemd because spice-vdagent was not run in a 'user session'
>   context I guess. We need to know if the spice-vdagent which is running
>   is run by the user in the 'active seat', and I have no idea if this
>   is compatible with systemd user units...
> 
> At this point, I'd just go with this patch
> 
> Christophe
> 

Maybe adding a warning if cpuinfo contains "hypervisor" ?
(https://unix.stackexchange.com/questions/3685/find-out-if-the-os-is-running-in-a-virtual-environment)
Other methods seem to use dmidecode which requires root permissions.
But I would prefer to do the check once, not for every login.

> > 
> > Cheers,
> > Jakub
> > 
> > > - reworded the message
> > >
> > >  src/vdagent/vdagent.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/src/vdagent/vdagent.c b/src/vdagent/vdagent.c
> > > index 90247f9..ff3328c 100644
> > > --- a/src/vdagent/vdagent.c
> > > +++ b/src/vdagent/vdagent.c
> > > @@ -451,8 +451,8 @@ int main(int argc, char *argv[])
> > >              LOG_USER);
> > >
> > >      if (file_test(portdev) != 0) {
> > > -        syslog(LOG_ERR, "Cannot access vdagent virtio channel %s",
> > > portdev);
> > > -        return 1;
> > > +        g_debug("vdagent virtio channel %s does not exist, exiting",
> > > portdev);
> > > +        return 0;
> > >      }
> > >
> > >      if (do_daemonize)

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux Virtualization]     [Linux Virtualization]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]