vnc4server does not start Desktop environment after security update

I've isolated the problem a fair bit... xinitrc is run by ~/.vnc/xstartup, which executes `. /etc/X11/Xsession', which in turn seems to cause any process running it to crash, if it's set to connect to a Xvnc session. Running an xterm on it manually works fine, and the Xsession script works fine on a normal X session. I'll work out what it is that's causing the crash, and get it fixed ASAP.

This problem has only appeared now due to vnc4 not having been built in Edgy until now, and not due to the security update changes to the source. The Dapper version of the security update works fine.

4.1.1+xorg1.0.2-0ubuntu1

I'm not running with the update (and now I'm going to hold off for a while!), but on my fresh Edgy install, xinitrc isn't even executable, so the exec fails for that reason.

<pre>root@lilith:~# ls -l /etc/X11/xinit/
total 12
-rw-r--r-- 1 root root 224 2006-08-07 20:01 xinitrc
drwxr-xr-x 2 root root 4096 2006-10-25 14:38 xinput.d
-rwxr-xr-x 1 root root 53 2006-08-07 20:01 xserverrc</pre>

I think the startup failures may be related to the errors seen in bug 78294. (Though it is unclear if these are duplicates.)

Hi

I think the initial description should say "today 2007-01-06" rather than "today 2006-01-06".

Yes, that's correct. I edited the initial description.
Thanks for pointing that out.

I have experienced this also, on two different machines with recent installs on trying to launch gnome-session or xfce4-session

an older machine that hasn't been updated in a while runs just fine.

I found that switching from vnc4server back to tightvncserver ("fixes" isn't the right word) removes the problem for me.

Hi,

I can also confirm that the updated vnc4server has some problems - I can use the version in edgy just fine, but after trying the update, I can't log into the VNC server from my Windows machine (using UltraVNC). It asks for a password and then just dies. If I downgrade it (sudo apt-get install vnc4server/edgy), then connections work again.

The log has some entries looking like this:

Jan 28 18:55:15 fane-desktop xinetd[5388]: warning: can't get client a
ddress: Transport endpoint is not connected
Jan 28 18:55:32 fane-desktop xinetd[5404]: warning: can't get client a
ddress: Transport endpoint is not connected
Jan 28 18:56:40 fane-desktop xinetd[5476]: warning: can't get client a
ddress: Transport endpoint is not connected

I'm running vnc4server from xinetd, as the message suggests.

Wouldn't reverting the update be reasonable, seeing that it causes problems with most people?

Oh, btw, I'm using Edgy 6.10 32-bit, trying to run KDE remotely (I have kde-core but not full Kubuntu installed). I'm also using it for full desktop mode - I've uncommented the first two lines in ~/.vnc/xstartup and commented out the others.

I agree with Stefan. As it is vnc4server is totally useless.

Ditto. Please fix this bug or revert the "upgrade". Current vnc4server is unusable.

As someone who is also experiencing this fatal bug in vnc4server, a status update would be great since it has been almost a month and not assigned to anyone. Thanks :-).

I've also encountered this problem here. I'm migrating from a Mandriva server where we had nearly 30 pre-launched VNC Server sessions to Ubuntu. I'm eager to see version 4.2.8 deployed in Feistey. Although Tightvncserver is getting us by for now.

I've done (after uncommenting the first two lines of .vnc/xstartup)

$ sudo chmod 755 /etc/X11/xinit/xinitrc

but still grey screen

I restored xterm, then tried:

$ gnome-session
The program 'gnome-session' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 75 error_code 1 request_code 146 minor_code 2)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
$

Still no way to get a desktop with any vnc server in feisty?

Any packages that are not part of the main repositories may have increased delays in security and regular updates. I'd like to know if there's any reason besides problems with proprietary drivers why you wouldn'tbe using vino instead (included in the standard Ubuntu Gnome desktop) ?

I'd like to help with this particular bug, but I need a complete step-by-step procedure to reproduce it, including the initial setup of vnc4server and any configuration files.

In addition to having refresh problems with ATI driver as mentionned in LP 57156 vino provides only a way to control an existing session and not to create a new one remotely.

Here is on current feisty a step by step reproducer:

1) update to latest version of vnc4server
$ sudo apt-get install vnc4server
2) create a password:
$ vncpasswd
(enter any password twice)
3) modify the ~/.vnc/xstartup file so vnc starts in full desktop mode (uncomment the first two lines)
#unset SESSION_MANAGER
#exec /etc/X11/xinit/xinitrc
4) run
$ vncserver
(wait a few seconds, you can tail -f the mentionned log file)
4) with the terminal server client open a VNC connection to localhost:1
(or localhost:X as mentionned in vncserver output)
enter the password provided in 2)
5) you don't have a gnome session but just an xterm (and twm if you apt-get install twm)
we'd like to be able to launch a gnome-session

Note that any other vnc server besides vnc4server would be ok for me if you recommand one.

You could use the vncserver (v.3.3) or tightvnc. However they both are "much" slower than vnc4server, which is the de facto standard.

Changing the font path (-fp) may help.

Like Stefan, my Xvnc started failing with thousands of "Transport endpoint is not connected" errors. Downgrading didn't help. What was happening is that Xvnc kept dying, and Xinetd kept restarting it. Thousands of times. Running Xvnc manually, I found it was failing to find the fonts. I tracked it down to a changed font path in the newer X server

Change: /usr/share/X11/fonts/misc
To: /usr/share/fonts/X11/misc

That solved my problem. Thanks to Chad Bisk for suggesting I run it by hand, and to Scott Carpenter for this post, with the proper font path:
http://www.movingtofreedom.org/2007/02/16/howto-remote-desktop-with-vnc-in-ubuntu-edgy-gnu-linux/

Hi

Can somebody pull 4.1.1+xorg1.0.2-0ubuntu1.6.10.1 out of the repositories so it doesn't repeatability get flagged by the software update tool.

Thanks

I second the last request. I depend on VNC on my Ubuntu Boxes and don't want to risk as mistake where I am left locked out of the boxes.

A non-functional security fix is the same as nothing and should be removed.

Was able to get tightvncserver working with fluxbox on Feisty. When I tried to use gnome I got a desktop allright, but the keys in the keyboard were mixed up.

Would be nice to get gnome to work with the latest and fastest VNC. Vino works but doesn't count because it must be manually started.

I recently tried freeNX as an aternative to vnc. I was very impressed with the performance, so much so I removed vnc4server.

Chuck Forsberg wrote:
> Was able to get tightvncserver working with fluxbox on Feisty. When I
> tried to use gnome I got a desktop allright, but the keys in the
> keyboard were mixed up.
>
> Would be nice to get gnome to work with the latest and fastest VNC.
> Vino works but doesn't count because it must be manually started.
>
>
The file /etc/vnc.conf may have some bearing on the problems we are
seeing.
Here's a thread which might bring further light to this matter:
http://www.ubuntuforums.org/showthread.php?t=2323&highlight=VNC

PLEASE pull this update. It causes no end to grief for users.

Is anyboy (kescook?) doing something about this? I'd hate to see a Feisty release with no good vnc server.

And no, vino doesn't work for me. I am *not* going to leave my server unattended with an active display session, 100% accessible to anybody who walks by and turns the monitor on.

vino is also very, very slow compared to vnc4server, at least in my experience.

Re-verified with vnc4server=4.1.1+xorg1.0.2-0ubuntu4

The core problem seems to be that any gnome apps fail with the error as below:

mostrows@slug:~$ gnome-session
The program 'gnome-session' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 74 error_code 1 request_code 146 minor_code 2)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

I, unfortunately, don't know how to fix the problems. If someone can package a working vnc4, I would be more than happy to sponsor an upload. I've tried rebuilds against a more current Xorg[1], but they still fail. :(

[1] http://people.ubuntu.com/~kees/feisty/vnc4/

i've resorted to tightvnc
from console run tightvncserver
it opens a session on :1
it sort of works...
Christian

On 4/10/07, Kees Cook <email address hidden> wrote:
> I, unfortunately, don't know how to fix the problems. If someone can
> package a working vnc4, I would be more than happy to sponsor an upload.
> I've tried rebuilds against a more current Xorg[1], but they still fail.
> :(
>
> [1] http://people.ubuntu.com/~kees/feisty/vnc4/
>
> --
> vnc4server does not start Desktop environment after security update
> https://bugs.launchpad.net/bugs/78282
> You received this bug notification because you are a direct subscriber
> of the bug.
>
>

Hi,

Kees Cook:
> I've tried rebuilds against a more current Xorg[1], but they still fail. :(
>
Bah.

> [1] http://people.ubuntu.com/~kees/feisty/vnc4/
>
I'll try to take a look, but I haven't exactly got much time at the
moment. Right before the release is the exact wrong time to run across
a problem that's been existing for months. :-/

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
He who laughs last didn't get the joke.

This is most likely a problem with /etc/vnc.conf not having some sane defaults. Maybe the problem is that vncserver and vnc4server can both be installed at the same time.

I'm looking into this further. Maybe we can patch /etc/vnc.conf from vnc4-common package.

I'm trying to figure out where this file gets generated from....

~/.vnc/xstartup

It does not invoke gnome.
The file instructs that for a normal desktop two lines should be commented out.

I tried doing that... still no gnome-session.
I tried adding
  gnome-session
at the end, but no joy.

Hmm... some apps work under this vnc4server....
   firefox
   emacs (as an X application)
   konqueror
   Open Office .org Works...(Font smoothing is not so smooth)

Some apps do not work...
   nautilus
   gnome-session
   gedit
   gcalctool (Offers interesting error message)
      main.c: WARNING: called SUID root, but not in group pulse-rt.
      the program 'gcalctool' received an X Window System error.
      this probably reflects a bug in the program.
      The error was "BadRequest (invalid request code or no such operation)'.
        (Details: serial 225 error_code 1 request_code 146 minor_code 2)
        (Note to programmers: normally, X errors are reported asynchronously:
          that is, you will recieve the error a while after causing it.

I've uncommented many of the lines in /etc/vnc.conf for font paths and config file paths.

The twm window manager works.

To me this seems like Gnome's inability to deal with a non-GLX display.
This is a show stopper especially for Linux thin clients.

Now on this machine I did have some 3d effects software loaded beryl and such. Maybe this is leading to certain gnome options enabled which force the behavior to crash the application.

Otherwise this vnc4server rocks! I'll have to load KDE for the time being.

Cheers!

I'm testing in Feisty at present and we are still having problems getting Gnome applications to startup within RealVNC (vnc4server). I ran glxinfo and it told me that glx was not supported in a series of displays then it coredumped.

I've read that RealVNC can support GLX extensions. I don't know how to check the compile flags in a .deb. Can somebody check to make sure vnc4server was compiled _with_ glx support?

The latest version of RealVNC is 4.1.2
The version Feisty and Edgy are working with is 4.1.1+xorg1.0.2-0ubuntu4 .
Maybe try bumping the version up?

I installed kubuntu-desktop then modified ~/.vnc/xstartup to include the line
exec startkde

And the KDE desktop starts up. Gnome applications fail though. Where should I file this bug report under Gnome?

Still Gnome applications don't work.
-Joe Baker

Hi,

Joe Baker:
> The latest version of RealVNC is 4.1.2
> The version Feisty and Edgy are working with is 4.1.1+xorg1.0.2-0ubuntu4 .
> Maybe try bumping the version up?

I've looked at the diff, it's quite small and doesn't look like it's
going to solve the problem.

I'm running the Dapper vnc4server at the moment. It works (and does not
have GLX), so it's not just a problem with Gnome.

The error says quite plainly that the broken Gnome apps send an X request
which vnc4server no longer understands. That's a regression in my eyes.

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
There is only one thing in the world worse than being talked about, and
that is not being talked about.
  -- Oscar Wilde

Hi,

I have just installed Feisty from CD (after a "/" crash)

I have the same problem with vnc4server in Edgy after the update

I can start vnc4server with twm. But I just cannot launch mozilla-thunderbird

  --\ Versions
i 4.1.1+xorg1.0.2-0ubuntu1
p 4.1.1+xorg1.0.2-0ubuntu4

in Edgy I downgraded the package, so I added the Edgy bin-pkg for vnc4server in Feisty
and now thunderbird & others are BACK :)

I just cannot compile vnc4 from source, there are many errors.

Cheers,

Guillaume

Charles Twardy 's suggestion above was part of the solution for me:

1. In /etc/X11/gdm/gdm.conf
Find the [xdmcp] section in the file, set: Enable=True

2. In /etc/xinetd.d/Xvnc
Change: /usr/share/X11/fonts/misc
To: /usr/share/fonts/X11/misc

3. sudo killall Xvnc

4. sudo /etc/init.d/xinetd restart

and voila, the session comes up fine. I had all the reported errors in this bug: First, vnc4server threw "Transport endpoint is not connected" in syslog - step 1 took care of that. Then Xvnc did not start any longer in desktop environment mode, only the gray screen with the "X" mouse pointer appeared. Step 2 took care of that.

Achim J. Latz wrote:
> Charles Twardy 's suggestion above was part of the solution for me:
>
> 1. In /etc/X11/gdm/gdm.conf
> Find the [xdmcp] section in the file, set: Enable=True
>
I would have thought this would have been set to on because I run an
LTSP server, but I'd forgotten that Ubuntu's LTSP implementation has
been using LDM instead which offers an SSH spawned X-Windows login that
wrapps all the communications inside SSH.
> 2. In /etc/xinetd.d/Xvnc
> Change: /usr/share/X11/fonts/misc
> To: /usr/share/fonts/X11/misc
>
I'm really glad that you've identified this problem with the font path.
The font paths also need to be addressed in /etc/vnc.conf
> 3. sudo killall Xvnc
>
> 4. sudo /etc/init.d/xinetd restart
>
I don't spawn vncservers from xinetd. We launch a unique vncserver for
each user. The user's desktop shortcut contains the host:X where x is
the vncdisplay number, and launcher also contains the unique vncserver
password as specified in the ~/.vnc/passwd file.

> and voila, the session comes up fine. I had all the reported errors in
> this bug: First, vnc4server threw "Transport endpoint is not connected"
> in syslog - step 1 took care of that. Then Xvnc did not start any longer
> in desktop environment mode, only the gray screen with the "X" mouse
> pointer appeared. Step 2 took care of that.
>
This is great news that you've gotten this to work better!

So will the font issue get updated into an updated Ubutnu package?

-Joe Baker

Hi
dpkg -l |fgrep xorg
ii xvnc4viewer 4.1.1+xorg1.0.2-0ubuntu4
  Virtual network computing client software fo
ii xserver-xorg-core 1.2.0-3ubuntu8 X.Org X server -- core server

   It looks like vncserver is compiled against older version of xorg1.0.2. If you compile the xvnc against xorg1.2.0, the problem will go away. One stopgap solution is to use only old X programs. I am using twm as window manager, xpdf, xterm, firefox etc as fallback now. My feeling is that new X -programs are using some extensions available only in 1.2.0 or libraries may be incompatible.

with regards
Antony

What I've found is that Gnome applications cannot run on the newer versions of Xvnc. I get the message described above when starting any Gnome application:

The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 74 error_code 1 request_code 146 minor_code 2)

I assume that this happens as soon as querying gdm with my setup. It works if I modify my xstartup to use afterstep and xterm, but that really limits what I can do.

I got bit by the upgrade in Edgy earlier. I upgraded to Feisty last night assuming that this would be fixed.

"-extension XFIXES" adding this option to my vnc4server command line solved my problems.
I hope this helps.

Cheers,
Roberto

Roberto...is that intended to fix the stated issues with applications starting?

It doesn't have any impact on the "Transport Endpoint errors listed at the beginning of this bug report". Is it possible that these are 2 separate bugs, each applied to this release of VNC4Server?

Heh.. was feeling smug until I discovered -extension XFIXES had already been suggested at the end of this thread!
I've been working around with -extension XFIXES. I came across this bug looking to see if the one I'm about to file regarding a Segfault in VNC is a dup.

I discovered this debugging the vnc server, and have some comments from RealVNC who I originally contacted:

"""
Firstly, VNC Free Edition 4.1.1 has a serious security issue and should not
be used on any un-trusted network - VNC Free Edition 4.1.2 resolves this
issue.

Secondly, VNC Free Edition does not provide the Xfixes extension. From the
patches filename you have included below, it looks like Ubuntu is using a
custom VNC Free Edition 4.1.1-based package, which is build against a
different version of the X server, and so does provide Xfixes.

The two potential solutions I'd propose are:

1. Upgrade to the standard VNC Free Edition 4.1.2 package, which will not
provide Xfixes and so presumably won't confuse GTK.

OR

2. Find the run-time option to the Ubuntu VNC-based Xvnc to disable Xfixes
support in the X server, again to avoid GTK being confused.

The problem could be in the Ubuntu VNC-based X server build, advertising
Xfixes but not properly supporting it, or in GTK in detecting Xfixes and
then making invalid calls to use it, but it's impossible to say which. In
either case, the packages you're using will have been patched by the Debian
guys, so in the first instance it's worth reporting the issue to them - the
package maintainers can then propagate the report if it turns out to be an
issue with the underlying software.
"""

F.Y.I. "-extension XFIXES" is supported by vnc4server_4.1.1+xorg1.0.2-0ubuntu4_i386.deb, previous version like vnc4server_4.1.1+X4.3.0-21_i386.deb does not support XFIXES.

I had all the problems listed above with vnc4server since I installed edgy, searching for the solution I upgraded to feisty with no improvement until I found that the above vnc4server pakage with extension XFIXES resolved my problem and finally I am now able to use remote connection again with KDE, I have not tested Gnome yet.

This is just a work around that works fine for me and I hope it could also give some light that helps to release the final solution a.s.a.p.

Regards,
Roberto.

It seems to me that I may be having the same problem.
This may or may not be helpful to you.
I fixed my problem using "-query <ipaddress>".
<ipaddress> CANNOT be "localhost" nor "127.0.0.1". It MUST be the actual ip address of the server or else a name that resolves to this address.

Finally I got the bloody vnc4server working. What Roberto Faroline said on 2007-04-25 DID WORK. They should at least assign someone to fix it (I was about to install fedora :-o).

Anyway, this is what I did to make it work:

Modify the file /etc/xinetd.d/Xvnc, by adding at the end of the server_args line this:

           -extension XFIXES

The whole Xvnc file under /etc/xinetd.d should look like this:

service Xvnc
{
        type = UNLISTED
        disable = no
        socket_type = stream
        protocol = tcp
        wait = yes
        user = root
        server = /usr/bin/Xvnc
        server_args = -inetd :1 -query localhost -geometry 1280x800 -depth 16 -f
p /usr/share/fonts/X11/misc -DisconnectClients=0 -NeverShared passwordFile=/root
/.vncpasswd -extension XFIXES
        port = 5901
}

Take a look at this excelent link:
http://grumpymole.blogspot.com/2007/04/workaround-for-vnc4server-end-of-stream.html

Cheers

I have two computers using Feisty, identically configured and had the same problem. The Xvnc configuration works perfect with the previous pacakge under Edgy.

Now one works with the XFIXES argument, the other doesn't. What can I do to debug this problem?

Disregard my last message. Got it working.

I confirm the option "-extension XFIXES" resolve the problem on feisty. it works now.

As I am not using xinetd daemon, I have just added in /usr/bin/vncserver (pointing to vnc4server file)

$cmd .= " -extension XFIXES ";

at the end of
$cmd .= " -rfbport $vncPort";
$cmd .= " -pn";
$cmd .= " -extension XFIXES ";

Firefox, thunderbird, etc. are back :)

Thanks for your help !

This may not be exactly the same problem as others are having...but hopefully someone can suggest a solution. I too have found that adding -extension XFIXES with the latest version of the binary fixes the immediate disconnection problem - just the same as backdating to an older version of the binary.

However...when I'm presented with a login prompt...a correct ID and password yield....nothing - an immediate return to the login prompt. The syslog yields the following:

warning: can't get client address: Transport endpoint is not connected

VNC worked perfectly for me under Edgy with the backdated binary, but this started as soon as I did a repository upgrade to Feisty. Now that the server binary is working properly, can anyone suggest what else might cause this error?

Thanks,

To summarize:
There seems to be three general ideas for fixing vnc4server on Ubuntu.

1. -extension XFIXES (an addition to Xvnc execution)

2. Fixing the Font Path

3. Compiling against the newer version of Xorg.

=======================

1. -extension XFIXES (an addition to Xvnc execution)

This seems to have fixed getting as far as a login prompt for most. For others the fix has worked much further but mixed results were reported.

2. Fixing the Font Path

Wasn't there an issue with the font path?

Maybe somebody can check it against the xorg.conf file to see if it is
correct.

I used to enable the font server and dig into the vncserver script to
change it to query a tcp port for fonts. In the LTSP project this used
to be an option to specify a font server for the X Servers to connect to.

The return to the login prompt is because Feisty changed the default to not allow multiple logins for the same user. If you are running Xubuntu, for example, go to Applications -> Settings -> Login Window and there is an option on the General tab to disable multiple logins for a single user. By default this is now checked, which prevents you loggning in on :1 when you are already logged in with the same user on :0.

Regards

Warren
http://grumpymole.blogspot.com

Hubris, the return to login prompt must be, as mentioned by Warren Butler , because of the default to not allow multiple logins. If you are using GNOME you can go to System -> Administration -> Login Windows and then unselect Disable multiple logins for single user in the General Tab. The -extension XFIXES solution by Roberto along with fonts path seems to have fixed my problem. Many thanks.

There are 3 things that have to be fixed in order to make vnc4server work.

The first two are options needed to start vnc4server

1. Fix the font path used with -fp option.
     The -fp option with the right path in Feisty is:

    -fp /usr/share/fonts/X11/misc

2. Add "-extension XFIXES" option

    -extension XFIXES

3. The 3rd one is to allow multiple logins for a single user.

    To do so, open Applications -> Settings -> Login Window

     Then Uncheck the option on the General tab that says:
     "disable multiple logins for a single user".

If you are starting the vnc server from the command line you can just add the -fp and the -extension options with the right values mentioned in steps 1 and 2.

If you are using xinetd to start the vnc server the server_args in the Xvnc file under
 /etc/xinetd.d should be a SINGLE line like this (unfortunately the line was split in my previous post because of the cut and paste):

                server_args = -inetd :1 -query localhost -geometry 1280x800 -depth 16 -fp /usr/share/fonts/X11/misc -DisconnectClients=0 -NeverShared passwordFile=/root/.vncpasswd -extension XFIXES

Many thanks to Warren and others...I assumed it must be something related to multiple logins, but hadn't been able to find where it was set. Fully functional once again!

The posted solution worked for me also. It's time to get this fix applied to the default package.

Now it works with Isaac Salsberg 's comment...
You guys don't know how much time i've wasted on this one ... :(
I think it was the -extension XFIXES that made it work, i'm not using gdm and i already changed the font path.

Thanks Isaac Salsberg and Joe Baker for the fix it make a while that I wait to fix this bug, The Font Path and XFIXES params added the last package works for me on Edgy

I tried XFIXES fix but after client connection I still can only see a blank workspace (background is B&W grid, mouse ptr is X). These are dumps of my .conf files. I have Ubuntu Feisty AMD64 (not x86 on AMD64).

- xinetd.conf -

service Xvnc-myuser
{
        type = UNLISTED
        disable = no
        socket_type = stream
        protocol = tcp
        wait = yes
        user = myuser
        server = /usr/bin/Xvnc4
        server_args = -inetd -broadcast -geometry 800x600 -depth 8 -once -fp /usr/share/fonts/X11/misc -DisconnectClients=0 -NeverShared -PasswordFile=/home/myuser/.vnc/passwd -extension XFIXES -fp /usr/share/fonts/X11/misc
        port = 5951
}

- gdm.conf-custom -

[daemon]
RemoteGreeter=/usr/lib/gdm/gdmlogin
[security]
DisallowTCP=true
[xdmcp]
Enable=true
DisplaysPerHost=2
Port=177

I also found a strange thing: I tried to search udp/177 port of gdm but netstating...

udp6 0 0 :::177 :::* -

Only udp6!!!

XFIXES extension is installed (libxfixes3).
Font paths seems ok.

Please help me.

I managed to get it working following this howto:

First off, the window manager you see (tweed) is the twm window manager.
There is no mouse support, because this window manager isn't fully installed
on your system. Specifically, the menu package is not installed. If you
start aptitude or synaptic and properly install twm, you would have a
working system. But what you really want is GNOME, right?

Well to get that you need to get vncserver operating with the correct config
files. The HOWTO steps don't cover creating a xstartup config file for VNC
to use that will allow you to choose your window manager (you're getting twm
just by pure default). The easiest way to do this is as follows (cut from my
personal TWIKI, so forgive the format hack job):

* Installation with aptitiude

root@heckmedia:~# aptitude install vnc4server xinetd

* First as root, we want to first establish configuration files in the
/root/.vnc directory. This requires creating a VNC password.

root@heckmedia:~# vncpasswd
Password:
Verify:

* Next, invoke the vncserver to cause the rest of the configuration files to
be created. Immediately kill the server, since we won't be using it (instead
xinetd will start the vncserver on demand when we try to VNC in).

root@heckmedia:~# vncserver

New 'heckmedia:1 (root)' desktop is heckmedia:1

Creating default startup script /root/.vnc/xstartup
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/heckmedia:1.log

root@heckmedia:~# vncserver -kill :1
Killing Xvnc process ID 12108

* Now change the session window manager in the /root/.vnc/xstartup file from
'twm' to 'gnome-session'

root@heckmedia:~# cd .vnc/
root@heckmedia:~/.vnc <root@heckmedia:%7E/.vnc># ls
heckmedia:1.log passwd xstartup
root@heckmedia:~/.vnc <root@heckmedia:%7E/.vnc># emacs xstartup
root@heckmedia:~/.vnc <root@heckmedia:%7E/.vnc># diff xstartup xstartup~
12c12
< gnome-session &
---
> twm &

* Next we need some configuration to start Xvnc as a service under xinetd.
Create the file /etc/xinetd.d/Xvnc using cat and input redirection. Close
the input stream with a Control-D.

root@heckmedia:~/.vnc <root@heckmedia:%7E/.vnc># cd /etc/xinetd.d/
root@heckmedia:/etc/xinetd.d# cat > Xvnc
service Xvnc
{
type = UNLISTED
disable = no
socket_type = stream
protocol = tcp
wait = yes
user = root
server = /usr/bin/Xvnc
server_args = -inetd :1 -query localhost -geometry 1280x1024 -depth 24 -once
-DisconnectClients=0 -NeverShared passwordFile=/root/.vnc/passwd -extension
XFIXES
port = 5901
}

* Now stop and restart the xinetd daemon, killing any Xvnc processes in
between.

root@heckmedia:/etc/xinetd.d# /etc/init.d/xinetd stop
Stopping internet superserver: xinetd.
root@heckmedia:/etc/xinetd.d# killall Xvnc
root@heckmedia:/etc/xinetd.d# /etc/init.d/xinetd start
Starting internet superserver: xinetd.

* A reboot seems necessary at this point. I have not been successful using
VNC the first time without it.

* Finally try to login from a remote computer to IP Address:1 using a VNC
client.
* It is also possible to test using vncviewer to localhost:1
* Sessions will not end when you close the VNC client unless you log out!

That should just about do it. You should no...

I LOVE YOU!!!

... Hi, thank you very much... I missed to change xstartup replacing twm
with gnome-session.

Now all is working well.

I'm going to post on launchpad.net...

Thanx again, Alessio

2007/5/29, Chribu <email address hidden>:
>
> I managed to get it working following this howto:
>
> First off, the window manager you see (tweed) is the twm window manager.
> There is no mouse support, because this window manager isn't fully
> installed
> on your system. Specifically, the menu package is not installed. If you
> start aptitude or synaptic and properly install twm, you would have a
> working system. But what you really want is GNOME, right?
>
> Well to get that you need to get vncserver operating with the correct
> config
> files. The HOWTO steps don't cover creating a xstartup config file for VNC
> to use that will allow you to choose your window manager (you're getting
> twm
> just by pure default). The easiest way to do this is as follows (cut from
> my
> personal TWIKI, so forgive the format hack job):
>
> * Installation with aptitiude
>
> root@heckmedia:~# aptitude install vnc4server xinetd
>
> * First as root, we want to first establish configuration files in the
> /root/.vnc directory. This requires creating a VNC password.
>
> root@heckmedia:~# vncpasswd
> Password:
> Verify:
>
> * Next, invoke the vncserver to cause the rest of the configuration files
> to
> be created. Immediately kill the server, since we won't be using it
> (instead
> xinetd will start the vncserver on demand when we try to VNC in).
>
> root@heckmedia:~# vncserver
>
> New 'heckmedia:1 (root)' desktop is heckmedia:1
>
> Creating default startup script /root/.vnc/xstartup
> Starting applications specified in /root/.vnc/xstartup
> Log file is /root/.vnc/heckmedia:1.log
>
> root@heckmedia:~# vncserver -kill :1
> Killing Xvnc process ID 12108
>
> * Now change the session window manager in the /root/.vnc/xstartup file
> from
> 'twm' to 'gnome-session'
>
> root@heckmedia:~# cd .vnc/
> root@heckmedia:~/.vnc <root@heckmedia:%7E/.vnc># ls
> heckmedia:1.log passwd xstartup
> root@heckmedia:~/.vnc <root@heckmedia:%7E/.vnc># emacs xstartup
> root@heckmedia:~/.vnc <root@heckmedia:%7E/.vnc># diff xstartup xstartup~
> 12c12
> < gnome-session &
> ---
> > twm &
>
> * Next we need some configuration to start Xvnc as a service under xinetd.
> Create the file /etc/xinetd.d/Xvnc using cat and input redirection. Close
> the input stream with a Control-D.
>
> root@heckmedia:~/.vnc <root@heckmedia:%7E/.vnc># cd /etc/xinetd.d/
> root@heckmedia:/etc/xinetd.d# cat > Xvnc
> service Xvnc
> {
> type = UNLISTED
> disable = no
> socket_type = stream
> protocol = tcp
> wait = yes
> user = root
> server = /usr/bin/Xvnc
> server_args = -inetd :1 -query localhost -geometry 1280x1024 -depth 24
> -once
> -DisconnectClients=0 -NeverShared passwordFile=/root/.vnc/passwd
> -extension
> XFIXES
> port = 5901
> }
>
> * Now stop and restart the xinetd daemon, killing any Xvnc processes in
> between.
>
> root@heckmedia:/etc/xinetd.d# /etc/init.d/xinetd stop
> Stopping internet superserver: xinetd.
> root@heckmedia:/etc/xinetd.d# killall Xvnc
> root@heckmedia:/etc/xinetd.d# /etc/init.d/xinetd start
> Starting ...

Thanx to Chribu!
I missed to change /home/myuser/.vnc/xstartup replacing twm with gnome-session.

Just another bogus...
Sorry!

Chribu solved initial problem but Xvnc worked only first two times... Very strange. Now, after some seconds, gdm seems to crash (look attachment).

This is the dump of /var/log/syslog:

May 29 23:21:34 HomeDesk gdm[7368]: Handling user message: 'GET_CONFIG greeter/SetPosition 127.0.0.1:1'
May 29 23:21:34 HomeDesk gdmlogin[7406]: Got response: 'OK false'
May 29 23:21:34 HomeDesk gdmlogin[7406]: Sending command: 'CLOSE'
May 29 23:21:34 HomeDesk gdm[7368]: Handling user message: 'CLOSE'
May 29 23:21:35 HomeDesk gdm[7400]: gdm_slave_wait_for_login: In loop
May 29 23:21:36 HomeDesk gdm[7400]: term_quit: Final cleanup
May 29 23:21:36 HomeDesk gdm[7400]: gdm_slave_quick_exit: Will kill everything from the display
May 29 23:21:36 HomeDesk gdm[7400]: Running gdm_verify_cleanup and pamh != NULL
May 29 23:21:36 HomeDesk gdm[7400]: gdm_slave_quick_exit: Killed everything from the display
May 29 23:21:36 HomeDesk gdm[7368]: mainloop_sig_callback: Got signal 17
May 29 23:21:36 HomeDesk gdm[7368]: gdm_cleanup_children: child 7400 returned 65
May 29 23:21:36 HomeDesk gdm[7368]: gdm_child_action: In remanage
May 29 23:21:36 HomeDesk gdm[7368]: gdm_display_unmanage: Stopping 127.0.0.1:1 (slave pid: 0)
May 29 23:21:36 HomeDesk gdm[7368]: gdm_display_dispose: Disposing 127.0.0.1:1
May 29 23:21:36 HomeDesk gdm[7368]: gdm_display_unmanage: Display stopped

Any tip? I tried both with VNCviewer and cotvnc (OSX vnc clients).

I tested upstream (Package: vnc4server (4.1.1+X4.3.0-21) in Debian Stable/Unstable/Testing) and it works properly other than the font path being wrong of course (easily worked around with a single symlink, but easily fixed in the package itself with a simple recompile). I also tested upstream 4.2.0 from realvnc.com and it had more significant path issues but again once it worked correctly once I plugged symlinks into the system to work around those path issues. So this appears to be a problem introduced by the Ubuntu packaging team, not a bug in the upstream.

I have a similar problem according to ticket 68020. I cannot use Azureus under VNC4Server, but the above idea of using the TIghtVNCserver package did the trick for me.

The problem's with VNC4Server that I can see. I've even gone so far as to try it with external Windows X servers. Mocha X works perfectly while X-Deep 32 4.0 fails miserably. Otherwise works fine with Xorg and TightVNC.

Some info about the systems in question:

I'm running Feisty Server i386 on my fileserver and Kubuntu Feisty i386 on my desktop.

I want to run Azureus on the fileserver so I can free up my desktops and since that machine runs headless, I use a VNC server rather than a normal one. Until VNC4Server is fixed, I guss TIghtVNC will do for now.

--Ian.

Workaround installing Debian Edgy packages and patching up font paths enough to work at:

http://badtux.net/2007/06/making-vncserver-work-on-ubuntu.html

I have followed this thread but I remain unable to connect either locally or remotely when using xinetd. Otherwise, launching Xvnc directly on the command line allows me to connect without any problem.

I'm testing using Feisty as both client and server. The server shows these errors when I attempt 'vncviewer <IP>:1':

Jul 5 05:58:28 feisty-D86-2 xinetd[29601]: warning: can't get client address: Transport endpoint is not connected
Jul 5 05:58:28 feisty-D86-2 xinetd[29602]: warning: can't get client address: Transport endpoint is not connected
Jul 5 05:58:28 feisty-D86-2 xinetd[29603]: warning: can't get client address: Transport endpoint is not connected
Jul 5 05:58:28 feisty-D86-2 xinetd[4792]: Deactivating service Xvnc due to excessive incoming connections. Restarting in 10 seconds.
Jul 5 05:58:38 feisty-D86-2 xinetd[4792]: Activating service Xvnc

The server is running:

vnc-common 3.3.7-13ubuntu2
vnc4server 4.1.1+xorg1.0.2-0ubuntu4
xvnc4viewer 4.1.1+xorg1.0.2-0ubuntu4

The client is running:

xvnc4viewer 4.1.1+xorg1.0.2-0ubuntu4

When Xvnc is run manually I can connect both locally and remotely when using 'vncviewer <IP>:2'. Here is what is run:

$ ps ax | grep Xvnc
29206 pts/0 S 0:00 /usr/bin/Xvnc :2 -query localhost -geometry 800x640 -depth 16 -fp /usr/share/fonts/X11/misc -DisconnectClients=0 -NeverShared passwordFile=/root/.vnc/passwd -extension XFIXES

FILES

/root/.vnc/xstartup

#!/bin/sh

# Uncomment the following two lines for normal desktop:
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
gnome-session &

/etc/xinetd.d/Xvnc:

service Xvnc
{
        type = UNLISTED
        disable = no
        socket_type = stream
        protocol = tcp
        wait = yes
        user = root
        server = /usr/bin/Xvnc
        server_args = -inetd :1 -query localhost -geometry 800x640 -depth 16 -fp /usr/share/fonts/X11/misc -DisconnectClients=0 -NeverShared passwordFile /root/.vnc/passwd -extension XFIXES
        port = 5901
}

gdm.conf (commented lines removed):

[daemon]
AutomaticLoginEnable=false
AutomaticLogin=
TimedLoginEnable=false
TimedLogin=
TimedLoginDelay=30
Greeter=/usr/lib/gdm/gdmgreeter
RemoteGreeter=/usr/lib/gdm/gdmlogin
User=gdm
Group=gdm
LogDir=/var/log/gdm
PidFile=/var/run/gdm.pid
PostLoginScriptDir=/etc/gdm/PostLogin/
PreSessionScriptDir=/etc/gdm/PreSession/
PostSessionScriptDir=/etc/gdm/PostSession/
DisplayInitDir=/etc/gdm/Init
XKeepsCrashing=/etc/gdm/XKeepsCrashing
RebootCommand=/sbin/shutdown -r now "Rebooted from gdm menu."
HaltCommand=/sbin/shutdown -h now "Halted from gdm menu."
SuspendCommand=/usr/sbin/pmi action sleep
HibernateCommand=/usr/sbin/pmi action hibernate
ServAuthDir=/var/lib/gdm
BaseXsession=/etc/gdm/Xsession
SessionDesktopDir=/etc/X11/sessions/:/etc/dm/Sessions/:/usr/share/gdm/BuiltInSessions/:/usr/share/xsessions/
DefaultSession=default.desktop
UserAuthDir=
UserAuthFBDir=/tmp
UserAuthFile=.Xauthority
StandardXServer=/usr/X11R6/bin/X
Xnest=/u...

I am getting the same problem here. Everything broke in the upgrade to 7.04,
vnc4server latest is bad, but reverting to edgy (uncomment edgy lines in apt/sources, and downgrade) fixes it.

Warren

All my vnc4server problems went away when I patched the vnc4server script as below (after reading the comments above). It would be nice if someone would make this change in the package itself...

$ diff -uw vnc4server~ vnc4server
--- vnc4server~ 2007-01-07 12:30:09.000000000 -0500
+++ vnc4server 2007-08-03 12:29:12.000000000 -0400
@@ -153,6 +153,7 @@
 $cmd .= " -rfbauth $vncUserDir/passwd";
 $cmd .= " -rfbport $vncPort";
 $cmd .= " -pn";
+$cmd .= " -extension XFIXES";

 # Add font path and color database stuff here, e.g.:
 #

vnc4 (4.1.1+xorg1.0.2-0ubuntu5) gutsy; urgency=low

  * unix/vncserver: add "-extension XFIXES" (LP: #78282).

 -- Kees Cook <email address hidden> Tue, 21 Aug 2007 09:04:53 -0700

Rather than patching scripts which call Xvnc, wouldn't a better fix to be building Xvnc without the extension in the first place (Or determining why it is built in, but doesn't work?)

Its been a while since I last looked at this as I'm no-longer trying to use VNC for a terminal-server, however I recall RealVNC telling me that their version does not compile in support for the XFIXES extensions.

On Fri, Aug 24, 2007 at 12:20:41AM -0000, Peter Clifton wrote:
> Rather than patching scripts which call Xvnc, wouldn't a better fix to
> be building Xvnc without the extension in the first place (Or
> determining why it is built in, but doesn't work?)

I'm quite willing to take a patch to do it this way; it was not obvious
to me how to do it, and no one else has had a chance to spend time on
it.

Hi
  Can you put it in "vncserver" which is the wrapper around Xvnc? It
wouldn't fix the problem but it will alleviate it.
With regards
Antony
On Fri, 2007-08-24 at 00:47 +0000, Kees Cook wrote:
> On Fri, Aug 24, 2007 at 12:20:41AM -0000, Peter Clifton wrote:
> > Rather than patching scripts which call Xvnc, wouldn't a better fix to
> > be building Xvnc without the extension in the first place (Or
> > determining why it is built in, but doesn't work?)
>
> I'm quite willing to take a patch to do it this way; it was not obvious
> to me how to do it, and no one else has had a chance to spend time on
> it.
>

This appears FIXED in Gutsy Gibbons!
It seems the
-extension XFIXES
was added. I tested from a user account without an x session nor a $DISPLAY environment variable.
vncserver :1
Then it requested the password.
Then ...
vncserver -kill :1

In
/home/username/.vnc/xstartup
I commented out the xterm line
#xterm .....
 replaced twm with
gnome-session

Then started it again.
vncserver :1

Now tried vncviewer and got into the Gnome Desktop without problems.

It would be nice if VNC4 was compiled against a newer version of Xorg like someone mentioned earlier in Debian had done.
This is good news.

Fix confirmed; pushing updates for edgy and feisty shortly...

vnc4 (4.1.1+xorg1.0.2-0ubuntu4.1) feisty-security; urgency=low

  * unix/vncserver: add "-extension XFIXES" (LP: #78282).

 -- Kees Cook <email address hidden> Tue, 21 Aug 2007 09:04:53 -0700

Has anyone tried this with the final Gutsy?

I have a fresh Gutsy install configured for remote login with xinetd (not simply starting vncserver with a user) and all I get is a grey window with the mouse cursor.

No matter what I do, I don't get a Gnome login screen, let alone a working desktop.

It looks exactly like the bug described here. My version: 4.1.1+xorg1.0.2-0ubuntu6

@Soltész András
Have you enable XDMCP in gdm or kdm ?
If you use GDM may be look at :
https://bugs.launchpad.net/ubuntu/gutsy/+source/gdm/+bug/150193.

I personally use KDM (under Kubuntu) and it works well.

@pcr
XDMCP is enabled and GDM works well with XMing (windows based X server). I get a working desktop when I login using Xming from a windows machine.
When I try to connect with UltraVNC or TightVNCViewer from the windows machine, I get only the grey screen with the X cursor.

This is why I think the problem may be on the side of vnc4server and not with GDM (although it is possible that GDM fails for some reason when working with vnc4server).