When remote desktop access is disabled, vino-session will still run

[Martijn vdS]

Binary package hint: vino

I have disabled remote desktop access in vino-preferences, but still something called "vino-session" (which doesn't have a manual page, btw) is started, and keeps on running in the background, every time I login.

As far as I can see, it doesn't do anything but consume memory and an occasional CPU cycle, and I think it shouldn't be started/running at all unless remote desktop access is enabled.

[Jonh Wendell (wendell)]

This happens because vino on Ubuntu (which was merged from debian) is compiled with --enable-session. Without that flag, the process responsible for start/stop the deamon is gnome-session.

I don't know if Ubuntu developers would consider this as a bug. So, Sebastien, it's up to you to fix or to invalidate this bug.

[Sebastien Bacher (seb128)]

Jonh, what difference does it make? How vino starts if that's not by gnome-session? Shouldn't it exit when it's disabled whatever way is used to run it?

[Jonh Wendell (wendell)]

The server executable is /usr/lib/vino/vino-server.
It only must run when the gconf key /desktop/gnome/remote_access/enabled is true.

So, there are two ways:
1) patch gnome-session to watch that key and run vino-server when the key is true.
2) deploy its own 'watcher', called vino-session, by passing --enable-session to configure.

[Sebastien Bacher (seb128)]

Why not just making the binary return directly when the key is set?

[Martijn vdS (martijn)]

Just setting/unsetting a key in gconf won't start a daemon. That's what the session bit does -- it watches the gconf key, and starts a daemon if it's changed to true (I guess). So you'd have to log out and back in again for the daemon to start if you changed the key manually. So gnome-session should be taught to run daemons when certain gconf keys change.

Or you could make the preferences applet start the daemon (but that depends on the applet running on the same $DISPLAY)... or something.

[Jonh Wendell (wendell)]

Em Ter, 2007-09-25 às 16:42 +0000, Martijn van de Streek escreveu:
> Just setting/unsetting a key in gconf won't start a daemon. That's what
> the session bit does -- it watches the gconf key, and starts a daemon if
> it's changed to true (I guess). So you'd have to log out and back in
> again for the daemon to start if you changed the key manually.

You are right.

> So gnome-
> session should be taught to run daemons when certain gconf keys change.

This work was started some time ago:
http://svn.gnome.org/viewcvs/gnome-session-manager/trunk/

The idea was to replace gnome-session with that one, which implements
that functionality.

--
Jonh Wendell
<email address hidden> (MSN / Google Talk)

Linux User #114432
https://launchpad.net/~wendell

[Sebastien Bacher (seb128)]

why do you want to patch gnome-session to special case vino-server? It should not be registered in the session if it should not be started or the binary should just return when the gconf key is set so the session start it, the server look at the key and return and there is nothing running when not required

[Jonh Wendell (wendell)]

Em Ter, 2007-09-25 às 19:38 +0000, Sebastien Bacher escreveu:
> why do you want to patch gnome-session to special case vino-server? It
> should not be registered in the session if it should not be started or
> the binary should just return when the gconf key is set so the session
> start it, the server look at the key and return and there is nothing
> running when not required

What happens if i set the gconf key to true when session is already
started?

--
Jonh Wendell
<email address hidden> (MSN / Google Talk)

Linux User #114432
https://launchpad.net/~wendell

[Sebastien Bacher (seb128)]

the preference dialog that you use to set the key to true starts the service?

[Loïc Minier (lool)]

I agree that the cleanest way is to watch the GConf key and start a process based on its changes: it's how other GConf settings work, for example all gnome-settings-daemon settings.

Perhaps it would be clearer to simply name the watcher "vino-watcher" or "vino-launcher" so that users could easily guess what the process is about? This could also be made a more generic service such as "gconf-launcher" as other apps might need the feature.

Alternatively, dbus could start such a program, so replacing GConf via DBus would save us a "gconf-launcher" process.

[Jonh Wendell (wendell)]

The GNOME hackers are working on a new gnome-session[1], which will fix this bug. So, i'd close this one or reassing it to other component rather than vino.

[1] - http://svn.gnome.org/viewcvs/gnome-session/branches/new-gnome-session/

[Loïc Minier (lool)]

There doesn't seem to be any easy change that we can do at this stage without breaking GConf functionality (if we start vino-session from the capplet, we lose the possibility of sharing the desktop by tweaking GConf values from a SSH session for example). It's probably going to fit closer to a GNOME component in the next cycle, so I'm unmilestoning for gutsy-rc.

[Giorgio Vazzana (mywing)]

I think vino-session should be disabled, here's why:

1)
> This happens because vino on Ubuntu (which was merged from debian)
> is compiled with --enable-session. Without that flag, the process
> responsible for start/stop the deamon is gnome-session.

> So, there are two ways:
> 1) patch gnome-session to watch that key and run vino-server when the key is true.
> 2) deploy its own 'watcher', called vino-session, by passing --enable-session to configure.

Please read here:

http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/2007-July/036018.html

I think we don't need vino-session because gnome-session is _already_ patched to watch the GConf key. To see that do the following:
a) disable vino-session (see below)
b) start gconf-editor and set /desktop/gnome/remote_access/enabled as true
c) result: you'll see that vino-server has been started (ps -e w | grep vino)
d) now set /desktop/gnome/remote_access/enabled as false
e) wait some seconds
f) result: you'll see that vino-server has been killed
g) another proof: if you kill vino-server (killall vino-server) you'll see that in the file .xsession-errors appears the following line: "Session manager: gsm-remote-desktop.c:107: remote desktop server died, restarting", and the file gsm-remote-desktop.c belongs to the gnome-session package.

2)
In the file /usr/share/gnome/default.session vino-session has Priority=50, but for some reason gnome-session-properties reports a priority of 05, and I haven't been able to change this priority, so I think this is a bug.

3)
If I use vino-session and remote desktop is enabled, when I log out from gnome and then I log in again, gnome hangs and I can only see the brown background, but no panels or icons. File .xsession-errors reports:
1198440598.912730 Session manager: gsm-remote-desktop.c:107: remote desktop server died, restarting
1198440598.916107 Session manager: gsm-remote-desktop.c:107: remote desktop server died, restarting
1198440608.837906 Session manager: gsm-remote-desktop.c:130: activation of OAFIID:GNOME_RemoteDesktopServer failed: System exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0

How to disable vino-session: open /usr/share/gnome/default.session then 1) change the value of num_clients from 6 to 5 2) comment the three lines starting with 5. Your default.session should look like mine (see attachment). Now log out and log back in again.
John, Sebastien, please let me know what you think. Thanks.

[Giorgio Vazzana (mywing)]

Ok, now I am sure :) I just downloaded the sources for the gnome-session package (apt-get source gnome-session). In the file gnome-session-2.20.1/gnome-session/ChangeLog you can read:

==================== 2.7.91 ====================

2004-08-16 Mark McLoughlin <email address hidden>

 * Makefile.am: add gsm-remote-desktop.[ch].

 * gsm-remote-desktop.[ch]: add support for activating
 and re-spawning the remote desktop server based on the
 /desktop/gnome/remote_access/enabled key.

 * main.c: (main): use it.

[Jonh Wendell (wendell)]

Vino in Hardy is not built with --enable-session-support flag.

[Giorgio Vazzana (mywing)]

Ok, wonderful. But what about Gutsy? Shouldn't we do the same for Gutsy too?

[Sebastien Bacher (seb128)]

There is no duplicate and the subscriber counts is low, that doesn't qualify the bug for a stable upload, those require extra work and usually limited to security bugs and really annoying issues

[syedz (syedz)]

As a new user of Ubuntu 7.10 I found that the system monitor panel was showing extreme fluctuations of cpu usage, from 20% to over 98%. Somewhere I read about vino-session and thought about removing it to ease the load on the cpu. But it wouldn't let me change the priority to 19. Everytime I do it, it resets itself to zero. It would not allow me to end the process. Nothing happens when I click upon end/kill process. Since my understanding of linux is very basic I am wondering what to do about it?

[Jayotis Diggory (jayotis-d)]

This is what i'm looking for... please remove remote access from the OS. If I want RA, I'll install it. It seems people are little feature happy here (i.e. Hardy har har har)... that's what MS does. Although I have to admit, upgrading my IDE drive to SCSI with just software was amazing! Nice to meet ya Hardy, hate to be ya.