I accidentally  hit enter when submit button was active

Description of problem: spice-vdagent does not work after restarting spice-vdagentd service



Actual results:

all features provided by spice-vdagent stopped to work after restarting service

Expected result:

all features provided by spice-vdagent should work after restarting service

Restart of guest does fix this.

Restarting the guest doesn't work if you wanna use mouse in gdm It's not able to use mouse since vdagentd is not running. 

One related consequence is If anyone restarts guest machine and he/she wanna use mouse in gdm which is not possible. So he/she has to use keyboard to active login dialog.

(In reply to comment #3)
> Restarting the guest doesn't work if you wanna use mouse in gdm It's not able
> to use mouse since vdagentd is not running. 
> 

1) Try disabling selinux, there are some known issues between selinux and vdagent
under gdm. Please let me know if this helps.

> One related consequence is If anyone restarts guest machine and he/she wanna
> use mouse in gdm which is not possible. So he/she has to use keyboard to active
> login dialog.

2) Hmm, the mouse should still work in gdm, the user just needs to click on the spicec window 1 time first for it to grep the mouse, as the mouse is in server mode because there is no vdagentd running.

(In reply to comment #4)
> 1) Try disabling selinux, there are some known issues between selinux and
> vdagent
> under gdm. Please let me know if this helps.
Yes, disabling selinux does help and It's possible to use mouse in gdm after reboot.

> 2) Hmm, the mouse should still work in gdm, the user just needs to click on the
> spicec window 1 time first for it to grep the mouse, as the mouse is in server
> mode because there is no vdagentd running.

It works when not using vdagent and now It works when disabling selinux with vdagent. Earlier It didn't work with using vdagent and enabled selinux. Mouse was "avoiding" the spicec window - "moving behind the window".

Hi Guys,

Me again :) First of all thanks for all the testing, and bug reports!

It seems that this bug now is discussing 2 separate issues. lkocman's original report
talks about the spice-vdagent process in the user session not automatically restarting
when the system spice-vdagentd daemon gets restarted. I've marked the user session
helper as auto-restart in the desktop file, /etc/xdg/autostart/spice-vdagent.desktop:
[Desktop Entry]
Name=Spice vdagent
Comment=Agent for Spice guests
Exec=/usr/bin/spice-vdagent
Terminal=false
Type=Application
Categories=
X-GNOME-Autostart-Phase=Initialization
X-GNOME-AutoRestart=true
X-Desktop-File-Install-Version=0.18

So this seems like an issue with gnome-session -> changing component.

Where as mkrcmarik, later pointed out that the agent is not working in gdm (which can be worked around by disabling selinux). I already had a bug against selinux-policy open for this open in Fedora, which I've now cloned for RHEL-6, see bug 682416. I think it may be best for you guys to QA this, as this is spice specific, so maybe you can set the QA contact to yourself and qa-ack it?

Regards,

Hans

Does the vdagent register with the session manager?  It can do this by using the dbus api, the xsmp, or by merely daemonizing (fork()/_exit()).  If it doesn't, the gnome-session won't autorestart it i think.

Note if you using the Initialization phase of session start up, you have to register with the session manager. It's not optional.

(In reply to comment #8)
> Does the vdagent register with the session manager?  It can do this by using
> the dbus api, the xsmp, or by merely daemonizing (fork()/_exit()).  If it
> doesn't, the gnome-session won't autorestart it i think.

Aha, that then probably explains, as it is not doing any of the above. So you say
that simply standard daemonizing is enough ? That then likely is the best, as the vdagent is pure libX11 based and I would like to keep it desktop agnostic.

> Note if you using the Initialization phase of session start up, you have to
> register with the session manager. It's not optional.

Ok.

yea daemonizing is enough.

Ok changing component back to spice-vdagent then.

(In reply to comment #10)
> yea daemonizing is enough.

Hi,

Unfortunately it seems that daemonizing is not enough. It is a good idea, since it does avoid gnome-session waiting in the Initialization phase for spice-vdagent to signal it it has started, only to timeout causing a noticeable delay before the gdm greeter comes up / during login. But it does not seem to help to actually make gnome-session auto-restart spice-vdagent when it dies.

Here is the desktop file:

[Desktop Entry]
Name=Spice vdagent
Comment=Agent for Spice guests
Exec=/usr/bin/spice-vdagent
Terminal=false
Type=Application
Categories=
X-GNOME-Autostart-Phase=Initialization
X-GNOME-AutoRestart=true

And here is the daemonize code used:

void daemonize(void)
{
    int x, retval = 0;

    /* detach from terminal */
    switch (fork()) {
    case 0:
        close(0); close(1); close(2);
        setsid();
        x = open("/dev/null", O_RDWR); dup(x); dup(x);
        break;
    case -1:  
        fprintf(logfile, "fork: %s\n", strerror(errno));
        retval = 1;
    default:
        udscs_destroy_connection(&client);
        if (logfile != stderr)
            fclose(logfile);  
        exit(retval);
    }
}

So any other ideas sort of signalling gnome-session about successful startup through dbus (and drop the daemonize then I guess), also wrt the dbus stuff,
are there any docs on the dbus interface somewhere?

Hans, I don't see how gnome-session restarting the session daemon would help. It would then connect to a non-existing or non-listening socket, and get refused. Should the session agent try to connect every second or so? (it is possible I ignore an option to wait until the socket is listening/accepting again)

Another solution is to rely on another daemon, such as systemd, to have the unix socket always listening, even if the system daemon crashed, and to reconnect once the system agent is restarted. But that would be only a solution for systemd-Linuxes, or we would have to implement such logic in our own daemon...

So perhaps, we should just do both, ugly timer based and systemd socket / passing?

(In reply to comment #13)
> Hans, I don't see how gnome-session restarting the session daemon would help.
> It would then connect to a non-existing or non-listening socket, and get
> refused. Should the session agent try to connect every second or so? (it is
> possible I ignore an option to wait until the socket is listening/accepting
> again)
> 
> Another solution is to rely on another daemon, such as systemd, to have the
> unix socket always listening, even if the system daemon crashed, and to
> reconnect once the system agent is restarted. But that would be only a solution
> for systemd-Linuxes, or we would have to implement such logic in our own
> daemon...
> 
> So perhaps, we should just do both, ugly timer based and systemd socket /
> passing?

Hi,

Thanks for the input. My idea behind this was that gnome-session would try restarting it a number of times, and then if it fails X consecutive times wait a minute and try again, much like how init deals with processes which it must restart. Note that simply re-connecting when we loose connection does not work, because the system daemon <-> session daemon protocol may have changed. The idea how this should work is:
-package manager replaces both daemon
-post script restarts system daemon, resulting in the new proto daemon running
-all (old) connected session daemon-s exit
-session daemons get restarted so now the new proto versions are running

What we could do is, in the session daemon if the system daemon closes the pipe, sleep a few seconds and then re-exec ourselves. This would solve the
system daemon restarted problem.

Regards,

Hans

Ok, the new plan is to handle this completely in the vdagent, instead of depending on the session manager to restart us.

The plan is the following:
1) Add an vdagentd (the system daemon) <-> vdagent (the session daemon)
   protocol version message
2) Make the vdagent check there is a /dev/virtio-ports/com.redhat.spice.0
   and if there is not exit cleanly (like the vdagentd already does)
3) Rather then exiting with an error on failure to connect to the vdagentd
   sleep and retry
4) When the connection with the vdagentd closes the vdagent will move back to 3.
5) Upon receiving a vdagent protocol version message indicating a different
   protocol, re-exec ourselves. This covers the vdagentd restarted and the
   protocol version has changed case (which can happen with a package upgrade).

Hans, please find the last 4 patches that should implement your plan in this branch:

https://gitorious.org/~elmarco/spice/elmarcos-vd_agent/commits/reconnect

Looking at the patches again, I think we should not reexec-ourself after a number of unsuccessful attempts, perhaps even one failure should bail out already.

(In reply to comment #18)
> Looking at the patches again, I think we should not reexec-ourself after a
> number of unsuccessful attempts, perhaps even one failure should bail out
> already.

I've thought about that too, but I don't think it will be necessary, we have the sleep 1 in there to avoid becoming a fork bom and a situation where there is a version mismatch between the system vdagentd and the user session agent process should never exist.

This is fixed in the just build spice-vdagent-0.8.1-1.el6, moving to modified.

I have tested this few times. If we don't  about restart of service after update without switching inits then it's fine. Otherwise immediate restart does not work.

(In reply to comment #22)
> I have tested this few times. If we don't  about restart of service after
> update without switching inits then it's fine. Otherwise immediate restart does
> not work.

Erm, not sure what you exactly are trying to say here, can you elaborate a bit more / explain in some more detail what you are seeing?

Sure Hans:

in the most simple words restart of vdagent does not work right after updating older release to spice-vdagent-0.8.1-1.el6. At least not untill you'll switch to init 3 and back to init 5 (or restart). 

Once you updated and did restart or so ... then restart of service works always (without any init/restart hooks involved).

So the question is Do we really care that customer can't do `service spice-vdagentd restart` right after update (no reboot or switching inits is involved)?

Hi,

(In reply to comment #24)
> Sure Hans:
> 
> in the most simple words restart of vdagent does not work right after updating
> older release to spice-vdagent-0.8.1-1.el6. At least not untill you'll switch
> to init 3 and back to init 5 (or restart). 

Right, that is expected, actually the restart should work fine. What happens
(I think) is that the agent process in the user session dies as soon as you
upgrade to spice-vdagent-0.8.1-1.el6. Since it is dead then, naturally it does not restart itself when you then do another "server spice-vdagentd restart". If you manually restart the session agent after the upgrade by running spice-vdagent from a terminal, it should from then on autorestart fine. Note it will daemonize itself when started without cmdline arguments, so you will immediately get your prompt back in your terminal, without any feedback.

> 
> Once you updated and did restart or so ... then restart of service works always
> (without any init/restart hooks involved).
> 
> So the question is Do we really care that customer can't do `service
> spice-vdagentd restart` right after update (no reboot or switching inits is
> involved)?

Actually I already knew that when going from 0.8.0 to 0.8.1, the user session agent needs to be restarted manually. I documented this in the errata text as the user needs to logout and login again. This got changed by the doc team to the default the system needs to be rebooted boilerplate (which is not true, but certainly will do the trick too).

So marking as verified on spice-vdagent-0.8.1-1.el6

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1577.html