Hi, I'm a long time Windows user but new to Linux. I have set up a Suse
Linux Enterprise 9 server and enabled the VNC remote access and this works
fine getting tot he logon prompt with a VNC client. On my desktop PC
however running Suse Linux Pro 9.2 after going through the similar setup I
only get a graphic shell with a grey background and a cross for a cursor.
There is no problem with the VNC connection, just the login screen does not
appear. I haven't been able to find much in the manual on how do debug this
problem, only how to go through and set it up. Please help.

"John Howell" <jehowell@ihug.co.nz> wrote in message
news:dh1pdh$gdq$1@lust.ihug.co.nz...
> Hi, I'm a long time Windows user but new to Linux. I have set up a Suse
> Linux Enterprise 9 server and enabled the VNC remote access and this works
> fine getting tot he logon prompt with a VNC client. On my desktop PC
> however running Suse Linux Pro 9.2 after going through the similar setup I
> only get a graphic shell with a grey background and a cross for a cursor.
> There is no problem with the VNC connection, just the login screen does
> not
> appear. I haven't been able to find much in the manual on how do debug
> this
> problem, only how to go through and set it up. Please help.

Take a look at your VNC startup scripts, which are probably not running a
display manager. It's usually in $HOME/.vnc/xstartup.

On Fri, 23 Sep 2005 22:43:37 +0200, John Howell <jehowell@ihug.co.nz>
wrote:

> Hi, I'm a long time Windows user but new to Linux. I have set up aSuse
> Linux Enterprise 9 server and enabled the VNC remote access
> and this works fine getting to the logon prompt with a VNC client. On
> my desktop PC however, running Suse Linux Pro 9.2 after goingthrough the
> similar setup I only get a graphic shell with a greybackground and a
> cross for a cursor.
> There is no problem with the VNC connection, just the login screendoes
> not appear. I haven't been able to find much in the manual onhow do
> debug this problem, only how to go through and set it up.Please help.

I have no knowledge of VNC, and would like to ask a few questions.

Googling, I find that VNC enables the server to share its screen's
contents with the client(s). This would mean that if you are seeing
just the grey root window and the big X cursor (the initial state
of most X servers), then the same thing should appear on the server's
real screen.

If that is the case, this is not a VNC problem but a general linux
setup problem, for which this must be a very appropriate newsgroup.
But then I don't see why the OP presents it as a problem of what
appears in the VNC client.

In this case, the OP, being new to Linux, needs some advice on
how to debug the final steps of the bootup procedures, from the
line in /etc/inittab that starts a display manager (if this is
done from /etc/inittab on SuSE, I am a Fedora guy), through the
scripts that the display manager uses to set up its environment.
The OP might also need a hint about how to use tools like
ps (process status), select processes by sid (session id), etc.
A word about what processes to expect could also be usefull to
him.

There are two possibilities that strike me: The OP does not have
a physical screen connected to the server, and relies on VNC
to access it, or my source of knowledge about VNC fails to mention
the (quite obvious) next step: VNC could provide additional virtual
screens to its remote clients. This would offer a graphical
alternative to the standard "telnet style" terminal connection.

Does VNC offer this?

In this case, of course, the vnc server configuration is the logical
place to start debugging.

Either way, the OP could also find usefull a hint about the system
logging facilities, starting with the common log file
/var/log/messages, provided that VNC does use syslog. For what I
know VNC could write to it's own log file.

I believe most people believe it is important to be brief and to
the point when addressing somebody for help. Newsgroups like
this do not work quite that way. It is better to provide
information about your computer, and especially to provide some
observations. Give the readers something to go on. Being too
breif is a sure way of getting few answers.

-Enrique

Enrique Perez-Terron wrote:

> On Fri,sessionnp 2005 22:43:37 +0200, John Howell <jehowell@ihug.co.nz>
> wrote:

> I have no knowledge of VNC, and would like to ask a few questions.
>
> Googling, I find that VNC enables the server to share its screen's
> contents with the client(s). This would mean that if you are seeing
> just the grey root window and the big X cursor (the initial state
> of most X servers), then the same thing should appear on the server's
> real screen.

Yup, that is what I see. On the real physical console for the server though,
I can get the graphical login and have no problems.
>
> If that is the case, this is not a VNC problem but a general linux
> setup problem, for which this must be a very appropriate newsgroup.
> But then I don't see why the OP presents it as a problem of what
> appears in the VNC client.

Just a setup question from the point of view that I will be using VNC quite
often for my desktop PC as my laptop only runs Windows, and so when I want
any of my Linux apps when I am working away from home or in another room in
the house I jsut want a graphical terminal to my server and my desktop.

>
> In this case, the OP, being new to Linux, needs some advice on
> how to debug the final steps of the bootup procedures, from the
> line in /etc/inittab that starts a display manager (if this is
> done from /etc/inittab on SuSE, I am a Fedora guy), through the
> scripts that the display manager uses to set up its environment.
> The OP might also need a hint about how to use tools like
> ps (process status), select processes by sid (session id), etc.
> A word about what processes to expect could also be usefull to
> him.

That would be cool. I can see the VNC session starting on the server when I
connect to it, and I can get in with either my RealVNC client or a Java
based browser VNC client, but I get the same result in both cases, no login
prompt.

> There are two possibilities that strike me: The OP does not have
> a physical screen connected to the server, and relies on VNC
> to access it, or my source of knowledge about VNC fails to mention
> the (quite obvious) next step: VNC could provide additional virtual
> screens to its remote clients. This would offer a graphical
> alternative to the standard "telnet style" terminal connection.
>
> Does VNC offer this?

Yup, full graphical shell. I have no problems with a SSH connection, this
goes fine, but hard to use KMail with no Xwindow 8)

>
> In this case, of course, the vnc server configuration is the logical
> place to start debugging.
>
> Either way, the OP could also find usefull a hint about the system
> logging facilities, starting with the common log file
> /var/log/messages, provided that VNC does use syslog. For what I
> know VNC could write to it's own log file.
>
> I believe most people believe it is important to be brief and to
> the point when addressing somebody for help. Newsgroups like
> this do not work quite that way. It is better to provide
> information about your computer, and especially to provide some
> observations. Give the readers something to go on. Being too
> breif is a sure way of getting few answers.
>
> -Enrique

The VNC server with the problem is an AMD 3200+ with 1GB RAM running SUSE
Linux Pro 9.2. Video card is NVidia 0x0322, NIC is unknown, it is
integrated on the motherboard, but the linux generic driver seems to be
working fine.

I also have the server running SAMBA, NFS, Apache2 and Tomcat along with the
VNC service.

Nico Kadel-Garcia wrote:

>
> "John Howell" <jehowell@ihug.co.nz> wrote in message
> news:dh1pdh$gdq$1@lust.ihug.co.nz...
>> Hi, I'm a long time Windows user but new to Linux. I have set up a Suse
>> Linux Enterprise 9 server and enabled the VNC remote access and this
>> works fine getting tot he logon prompt with a VNC client. On my desktop
>> PC however running Suse Linux Pro 9.2 after going through the similar
>> setup I only get a graphic shell with a grey background and a cross for a
>> cursor. There is no problem with the VNC connection, just the login
>> screen does not
>> appear. I haven't been able to find much in the manual on how do debug
>> this
>> problem, only how to go through and set it up. Please help.
>
> Take a look at your VNC startup scripts, which are probably not running a
> display manager. It's usually in $HOME/.vnc/xstartup.

Cheers. Found xstartup. Does anyone have an example of a working file or
where I would be looking for where to specift the display manager?

John Howell wrote:

> Cheers. Found xstartup. Does anyone have an example of a working file
> or where I would be looking for where to specift the display manager?

This is an FC online guide that should get you working;

http://fedoranews.org/tchung/vnc/


--
Contained within the Microsoft EULA;
This Limited Warranty is void if failure of the Product has resulted
from accident, abuse, misapplication, abnormal use or a virus.

On Sat, 24 Sep 2005 23:15:00 +0200, John Howell <jehowell@ihug.co.nz>
wrote:

> Enrique Perez-Terron wrote:
>
>> On Fri,sessionnp 2005 22:43:37 +0200, John Howell <jehowell@ihug.co.nz>
>> wrote:
>
>> I have no knowledge of VNC, and would like to ask a few questions.
>>
>> Googling, I find that VNC enables the server to share its screen's
>> contents with the client(s). This would mean that if you are seeing
>> just the grey root window and the big X cursor (the initial state
>> of most X servers), then the same thing should appear on the server's
>> real screen.
>
> Yup, that is what I see.

... Eh? (what is "that", which you are seeing? Are you seeing
*the same thing* on the real screen?)

> On the real physical console for the server though, I can get the
> graphical login and have no problems.

... Ah. Now I hope I know what your are talking about.

>> If that is the case,

I now understand that "that" is not the case. You are not seeing the same
thing on the physical screen.

>> this is not a VNC problem but a general linux
>> setup problem, for which this must be a very appropriate newsgroup.
>> But then I don't see why the OP presents it as a problem of what
>> appears in the VNC client.
>
> Just a setup question from the point of view that I will be using VNC
> quite often for my desktop PC as my laptop only runs Windows, and sowhen
> I want any of my Linux apps when I am working away from home orin
> another room in the house I jsut want a graphical terminal to myserver
> and my desktop.

Cool! Perhaps I shall do the same...

But my point above was that since you are seeing the regular login
window on the real screen, you don't need to debug the general
bootup procedures. The section below does not apply:

>> In this case, the OP, being new to Linux, needs some advice on
>> how to debug the final steps of the bootup procedures, from the
>> line in /etc/inittab that starts a display manager (if this is
>> done from /etc/inittab on SuSE, I am a Fedora guy), through the
>> scripts that the display manager uses to set up its environment.
>> The OP might also need a hint about how to use tools like
>> ps (process status), select processes by sid (session id), etc.
>> A word about what processes to expect could also be usefull to
>> him.
>
> That would be cool.

Of course I can give you some hints for the sake of general education.

When the Linux kernel boots, it starts a single process "init", as process
number one (Process ID, PID for short = 1).

This process is responsible for starting all other processes, directly
or indirectly.

Well, that is not 100% true anymore, because the kernel nowadays starts
a couple of processes that show up with names in square brackets in the
process list. But those processes are not the ones you need to configure
or think much about.

The program "init" reads a file "/etc/inittab" and takes instructions from
it. First it looks for all lines containing the word "sysinit", and runs
all the commands associated with them. Then it looks for a line with
the word "initdefault" in it. From this line, init gets a number. (Go look
at the file you have got on your computer! it's not very long.)

This number is the "default runlevel". It is possible to tell the kernel
that
you want a different runlevel when you boot, but you are hardly going to
do that very soon. It is also possible to tell init at any point later to
change runlevel.

Once "init" has decided on a runlevel, it looks through the lines in
/etc/inittab, to find those lines that mention that runlevel, and it
runs all the commands on those lines.

When I say "mentions that runlevel", you must actually read it this way.
Each line (except the blank lines and the comment lines) have some
colons (':') in them. Consider these colons as field separators.
The inittab is really a table, and the fields should better have been
placed in columns, that would have been clearer. Then some of the lines
have the number '5' somewhere in the second field, like this

l5:5:wait:/etc/rc.d/rc 5
^
|

(The arrow will not point to the right place if you are reading this
on a mail or news reader that uses a proportional font. On my screen,
the arrow points to the fourth character on that line.)

When going to runlevel 5, "init" runs the commands in the lines having
the digit 5 somewhere in the second field.

Init can run the commands all at once, or orderly, one after the other.
The word "wait" tells init to not start any other commands until this one
has completed. If you investigate what the program "/etc/rc.d/rc" does
you will find that it starts all those programs that are supposed to run
in the background on your computer, probably the VNC server is one of
them. If you had any reason to believe the server was not starting,
you would start with this program (which is a shell script, you can read
it yourself if you understand the shell scripting language).

You will also see some lines like this:

5:2345:respawn:/sbin/mingetty tty5
^
|
I have tried to place an arrow below the '5' in the second field.
This line does not tell "init" to wait for its completion. Rather,
it says "respawn", meaning that whenever that command terminates, it
must be restarted automatically. The command "/sbin/mingetty" opens
a "virtual console" and allows you to log in on it. You will resort
to those consoles when you have such problems with the X server
that you have no other means of logging into your machine. You can
check if this is working on your computer. Go and get the real keyboard
of that computer, and press Ctrl-Alt-F5. You should get a black
screen with a login prompt in white letters. To get back to the
graphical interface, press Ctrl-Alt-F7. On most computers, the
graphical interface is on the virtual console number 7. You can
switch back and forth between virtual consoles and continue whatever
you were doing in each.

Then, toward the end of the /etc/inittab there is a line

x:5nce:/etc/X11/prefdm -nodaemon

At least, this is how it is on my computer. This is the line
that tells "init" to start the graphical interface. Had you not
seen the login window on the real terminal, this would have been
the starting point of the debugging session. You would have had
to read and understand the script /etc/X11/prefdm. It is not very
hard, and it is quite short. You can almost understand it even if
you only have general programming knowledge in other languages.
However, beware of those lines having a dot by itself as the command,
like this one:

[ -f /etc/profile.d/lang.sh ] && . /etc/profile.d/lang.sh

This line says that the file /etc/profile.d/lang.sh, if it
exists, should be considered part of the present script. That
means, that its variable settings are executed in the same process,
not in a child process, and that again means that any variables set
in the named file will affect the execution of the rest of the
script. You will also need a crash course in the test conditions
like [ -f ... ] above. Run the command "man test" to learn more.




> I can see the VNC session starting on the server when I connect to it,
> and I can get in with either my RealVNC clientor a Java based browser
> VNC client, but I get the same result inboth cases, no login prompt.

>> There are two possibilities that strike me: The OP does not have
>> a physical screen connected to the server, and relies on VNC
>> to access it, or my source of knowledge about VNC fails to mention
>> the (quite obvious) next step: VNC could provide additional virtual
>> screens to its remote clients. This would offer a graphical
>> alternative to the standard "telnet style" terminal connection.
>>
>> Does VNC offer this?
>
> Yup, full graphical shell. I have no problems with a SSH connection, this
> goes fine, but hard to use KMail with no Xwindow 8)


Cool!

>> In this case, of course, the vnc server configuration is the logical
>> place to start debugging.
>>
>> Either way, the OP could also find usefull a hint about the system
>> logging facilities, starting with the common log file
>> /var/log/messages, provided that VNC does use syslog. For what I
>> know VNC could write to it's own log file.
>>
>> I believe most people believe it is important to be brief and to
>> the point when addressing somebody for help. Newsgroups like
>> this do not work quite that way. It is better to provide
>> information about your computer, and especially to provide some
>> observations. Give the readers something to go on. Being too
>> breif is a sure way of getting few answers.
>>
>> -Enrique
>
> The VNC server with the problem is an AMD 3200+ with 1GB RAM running SUSE
> Linux Pro 9.2. Video card is NVidia 0x0322, NIC is unknown, it is
> integrated on the motherboard, but the linux generic driver seems to be
> working fine.
>
> I also have the server running SAMBA, NFS, Apache2 and Tomcat along with
> the VNC service.

I have seen in the other posts that you have asked for working xstartup.
Perhaps you can find something usable if you pursue what the regular
X server instance, that one started by "init", does. However, there is
a difficulty: First, there are two different desktop environments in
use under Linux today (and a couple of old style non-desktop environments)
Gnome and KDE. I only have knowledge of Gnome. If you prefer KDE, you
will have to investigate and find the equivalents.

Second, the Gnome display manager (/usr/bin/gdm) starts X, it is not
started after X has started. It is therefore possible that what you
want is *not* to add things to xstartup, but to change how VNC starts
X. Perhaps you want VNC to start gdm rather than have VNC start X.
Then gdm would start X for you. If so, you would probably have to
make sure that gdm starts X the way VNC wants, or even starts
the right X version. Isn't there a binary called vncX or something?

It slowly dawns on me that in the bad old days, computers used to start
X, and when they somehow got a message that X was ready, ran a session
script as a completely ordinary shell script, only with an environment
variable preset, DISPLAY=:0 or whatever was appropriate. Perhaps you
don't want run a second login screen after you have gone through
whatever authentication protects the VNC server. Perhpas it *is* OK to
skip gdm (or the kde equivalent), and just find out what gdm/kde do
*after* the login is complete.

It seems, I am not 100% sure, that gdm/gdmlogin just runs
/usr/bin/gnome-session. Gnome-sesson then appears to run all other
programs that are needed in a session, such as a panel, a window
manager, the gconf settings-daemon, etc.

Perhaps, unless you get a response to that question, you could just try
to put the following line in xstartup:

/usr/bin/gnome-session &

or perhaps it is better to do

/usr/bin/gnome-session >> ~/.xsession-errors.vnc$DISPLAY 2>&1 &

in order to have the standard output of the session saved somewhere.
That is quite usefull if you need to look for error messages from
a program that misbehaves.

It is also concievable that the VNC server will kill the X server when
the xstartup script finishes, thinking that the session has terminated.
In that case, remove the final "&" from the line.

-Enrique

"Enrique Perez-Terron" <enrio@online.no> wrote in message
newsp.sxmb78lfnxtvbs@apeiron.home.lan...
> On Fri, 23 Sep 2005 22:43:37 +0200, John Howell <jehowell@ihug.co.nz>
> wrote:
>
>> Hi, I'm a long time Windows user but new to Linux. I have set up aSuse
>> Linux Enterprise 9 server and enabled the VNC remote access
>> and this works fine getting to the logon prompt with a VNC client. On
>> my desktop PC however, running Suse Linux Pro 9.2 after goingthrough the
>> similar setup I only get a graphic shell with a greybackground and a
>> cross for a cursor.
>> There is no problem with the VNC connection, just the login screendoes
>> not appear. I haven't been able to find much in the manual onhow do
>> debug this problem, only how to go through and set it up.Please help.
>
> I have no knowledge of VNC, and would like to ask a few questions.
>
> Googling, I find that VNC enables the server to share its screen's
> contents with the client(s). This would mean that if you are seeing
> just the grey root window and the big X cursor (the initial state
> of most X servers), then the same thing should appear on the server's
> real screen.

Google has confused you, I think. VNC is built on top of X, formerly X11 and
XFree86, now the latest Xorg version. Keep this in mind.

A Windows or Mac machine running the VNC server has its console, it's main
display screen, mace available to a remote login. (This is an incredibly
useful tool.) It tries to optimize the X connection, and can even make it
accessible over Java to a typical modern web browser. This is *AMAZINGLY*
useful. The session is usually the "0" session on the machine, and you
connect to it running on your desktop as "desktop:0".

On UNIX or Linux, it actually runs an X session. These platforms can easily
run dozens of remote X sessions. VNC is merely one of them, with its own
startup configuration.

> If that is the case, this is not a VNC problem but a general linux
> setup problem, for which this must be a very appropriate newsgroup.
> But then I don't see why the OP presents it as a problem of what
> appears in the VNC client.

You made a reasonable assumption, but weren't aware of the difference
between Mac and Windows VNC servers and the UNIX/Linux behavior.

> There are two possibilities that strike me: The OP does not have
> a physical screen connected to the server, and relies on VNC
> to access it, or my source of knowledge about VNC fails to mention
> the (quite obvious) next step: VNC could provide additional virtual
> screens to its remote clients. This would offer a graphical
> alternative to the standard "telnet style" terminal connection.
>
> Does VNC offer this?

ABSOLUTELY. This is one of the killer features of VNC! Plus you can let
those clients hve control of the keyboard/mouse, or not, as you desire in
your VNC settings.

But the OP should be looking in his $HOME/.vnc directory on his server for
his VNC settings, and for the logs of the VNC sessions and their state.

> In this case, of course, the vnc server configuration is the logical
> place to start debugging.
>
> Either way, the OP could also find usefull a hint about the system
> logging facilities, starting with the common log file
> /var/log/messages, provided that VNC does use syslog. For what I
> know VNC could write to it's own log file.

Good guess, and for an ordinary system tool you'd often be correct. VNC is
written as a userland program, not a systems tool, and puts its logs in
$HOME/.vnc/.

Even standard X startups put a lot of the useful data in /tmp/X[*].log. I
think that's partly because X is a user program, and partly so that a user
can see the logs without needing the privileges that may be required to read
/var/log/messages.

> I believe most people believe it is important to be brief and to
> the point when addressing somebody for help. Newsgroups like
> this do not work quite that way. It is better to provide
> information about your computer, and especially to provide some
> observations. Give the readers something to go on. Being too
> breif is a sure way of getting few answers.

And *THAT*, sir, is a very wise and appropriate approach to the problem.

Nico Kadel-Garcia wrote:


>>
>> Either way, the OP could also find usefull a hint about the system
>> logging facilities, starting with the common log file
>> /var/log/messages, provided that VNC does use syslog. For what I
>> know VNC could write to it's own log file.

extract from my xinetd.log file:
mars:/var/log # tail -f xinetd.log
05/9/26@23:17:03: START: vnc1 from=192.168.0.49
05/9/26@23:17:03: EXIT: vnc1 status=0 duration=0(sec)
05/9/26@23:17:14: START: vnc1 from=192.168.0.49
05/9/26@23:17:14: EXIT: vnc1 status=0 duration=0(sec)
05/9/26@23:17:58: START: vnc1 from=192.168.0.49
05/9/26@23:20:04: EXIT: vnc1 status=0 duration=126(sec)
05/9/26@23:23:47: START: vnc1 from=192.168.0.49
05/9/26@23:25:34: EXIT: vnc1 status=0 duration=107(sec)
05/9/26@23:29:36: START: vnc1 from=192.168.0.49
05/9/26@23:31:42: EXIT: vnc1 status=0 duration=126(sec)

/etc/xinetd.d/vnc file
# default: off
# description: This serves out a VNC connection which starts at a KDM login
\
# prompt. This VNC connection has a resolution of 1024x768, 16bit depth.
service vnc1
{
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/X11R6/bin/Xvnc
server_args = :42 -inetd -once -query localhost -geometry 1024x768
-depth 16
type = UNLISTED
port = 5901
}
# default: off
# description: This serves out a VNC connection which starts at a KDM login
\
# prompt. This VNC connection has a resolution of 1280x1024, 16bit depth.
service vnc2
{
type = UNLISTED
port = 5902
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/X11R6/bin/Xvnc
server_args = :42 -inetd -once -query localhost -geometry 1280x1024 -depth
16
disable = yes
}
# default: off
# description: This serves out a VNC connection which starts at a KDM login
\
# prompt. This VNC connection has a resolution of 1600x1200, 16bit depth.
service vnc3
{
type = UNLISTED
port = 5903
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/X11R6/bin/Xvnc
server_args = :42 -inetd -once -query localhost -geometry 1600x1200 -depth
16
disable = yes
}
# default: off
# description: This serves out the vncviewer Java applet for the VNC \
# server running on port 5901, (vnc port 1).
service vnchttpd1
{
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/X11R6/bin/vnc_inetd_httpd
server_args = 1024 768 5901
type = UNLISTED
port = 5801
}
# default: off
# description: This serves out the vncviewer Java applet for the VNC \
# server running on port 5902, (vnc port 2).
service vnchttpd2
{
type = UNLISTED
port = 5802
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/X11R6/bin/vnc_inetd_httpd
server_args = 1280 1024 5902
disable = yes
}
# default: off
# description: This serves out the vncviewer Java applet for the VNC \
# server running on port 5902, (vnc port 3).
service vnchttpd3
{
type = UNLISTED
port = 5803
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/X11R6/bin/vnc_inetd_httpd
server_args = 1600 1200 5903
disable = yes
}

The messages log does not get added to when the VNC session starts.


>
> Good guess, and for an ordinary system tool you'd often be correct. VNC is
> written as a userland program, not a systems tool, and puts its logs in
> $HOME/.vnc/.
>
> Even standard X startups put a lot of the useful data in /tmp/X[*].log. I
> think that's partly because X is a user program, and partly so that a user
> can see the logs without needing the privileges that may be required to
> read /var/log/messages.
>
>> I believe most people believe it is important to be brief and to
>> the point when addressing somebody for help. Newsgroups like
>> this do not work quite that way. It is better to provide
>> information about your computer, and especially to provide some
>> observations. Give the readers something to go on. Being too
>> breif is a sure way of getting few answers.

On Mon, 26 Sep 2005 13:56:54 +0200, John Howell <jehowell@ihug.co.nz> wrote:

> Nico Kadel-Garcia wrote:
>
>
>>>
>>> Either way, the OP could also find usefull a hint about the system
>>> logging facilities, starting with the common log file
>>> /var/log/messages, provided that VNC does use syslog. For what I
>>> know VNC could write to it's own log file.
>
> extract from my xinetd.log file:
> mars:/var/log # tail -f xinetd.log
> 05/9/26@23:17:03: START: vnc1 from=192.168.0.49
> 05/9/26@23:17:03: EXIT: vnc1 status=0 duration=0(sec)
> 05/9/26@23:17:14: START: vnc1 from=192.168.0.49
> 05/9/26@23:17:14: EXIT: vnc1 status=0 duration=0(sec)
> 05/9/26@23:17:58: START: vnc1 from=192.168.0.49
> 05/9/26@23:20:04: EXIT: vnc1 status=0 duration=126(sec)
> 05/9/26@23:23:47: START: vnc1 from=192.168.0.49
> 05/9/26@23:25:34: EXIT: vnc1 status=0 duration=107(sec)
> 05/9/26@23:29:36: START: vnc1 from=192.168.0.49
> 05/9/26@23:31:42: EXIT: vnc1 status=0 duration=126(sec)
>
> /etc/xinetd.d/vnc file
> # default: off
> # description: This serves out a VNC connection which starts at a KDM login
> \
> # prompt. This VNC connection has a resolution of 1024x768, 16bit depth.
> service vnc1
> {
> socket_type = stream
> protocol = tcp
> wait = no
> user = nobody
> server = /usr/X11R6/bin/Xvnc
> server_args = :42 -inetd -once -query localhost -geometry 1024x768
> -depth 16
> type = UNLISTED
> port = 5901
> }
> # default: off
> # description: This serves out a VNC connection which starts at a KDM login
> \
> # prompt. This VNC connection has a resolution of 1280x1024, 16bit depth.
> service vnc2
> {
> type = UNLISTED
> port = 5902
> socket_type = stream
> protocol = tcp
> wait = no
> user = nobody
> server = /usr/X11R6/bin/Xvnc
> server_args = :42 -inetd -once -query localhost -geometry 1280x1024 -depth
> 16
> disable = yes
> }
> # default: off
> # description: This serves out a VNC connection which starts at a KDM login
> \
> # prompt. This VNC connection has a resolution of 1600x1200, 16bit depth.
> service vnc3
> {
> type = UNLISTED
> port = 5903
> socket_type = stream
> protocol = tcp
> wait = no
> user = nobody
> server = /usr/X11R6/bin/Xvnc
> server_args = :42 -inetd -once -query localhost -geometry 1600x1200 -depth
> 16
> disable = yes
> }
> # default: off
> # description: This serves out the vncviewer Java applet for the VNC \
> # server running on port 5901, (vnc port 1).
> service vnchttpd1
> {
> socket_type = stream
> protocol = tcp
> wait = no
> user = nobody
> server = /usr/X11R6/bin/vnc_inetd_httpd
> server_args = 1024 768 5901
> type = UNLISTED
> port = 5801
> }
> # default: off
> # description: This serves out the vncviewer Java applet for the VNC \
> # server running on port 5902, (vnc port 2).
> service vnchttpd2
> {
> type = UNLISTED
> port = 5802
> socket_type = stream
> protocol = tcp
> wait = no
> user = nobody
> server = /usr/X11R6/bin/vnc_inetd_httpd
> server_args = 1280 1024 5902
> disable = yes
> }
> # default: off
> # description: This serves out the vncviewer Java applet for the VNC \
> # server running on port 5902, (vnc port 3).
> service vnchttpd3
> {
> type = UNLISTED
> port = 5803
> socket_type = stream
> protocol = tcp
> wait = no
> user = nobody
> server = /usr/X11R6/bin/vnc_inetd_httpd
> server_args = 1600 1200 5903
> disable = yes
> }

This is interesting, and tells me quite a bit about how vnc is started.

I am confused at to the exact role of the vncviewer java appelet.
I observe the server name /usr/X11R6/bin/vnc_inetd_httpd. Is this
something that enables you to use a regular web browser as the
viewer client?

> The messages log does not get added to when the VNC session starts.

Ok.

Have you checked up any of the places that Nico says there could be logs?
In this section:

>> Good guess, and for an ordinary system tool you'd often be correct. VNC is
>> written as a userland program, not a systems tool, and puts its logs in
>> $HOME/.vnc/.

he suggests a place where there could be some log files, and here:

>> Even standard X startups put a lot of the useful data in /tmp/X[*].log. I

he suggests another. Use "ls -lrt" and check the last lines of output.

But, as I now understand the situation, you vnc is basicly working, it
is starting an X server, and relaying the screen to your viewer. There is
not to be expected any error messages from a system that basicly works.

What does not work, is starting some applications to run in with that
X display. All the KDM stuff are quite regular applications that
once they have started, open up connections to the X display and
asks it to draw the windows and tell back what the user is doing at
his keyboard and mouse.

This raises two questions. On one hand, what is the difference
between this installation where kdm does not start, and the former
where kdm starts? The other question is, can you start some
applications through the xstartup file?

Have you tried to just write "kdm" in xstartup?

If not, can you do

ls -lu /path-to-xstartup/xstartup

and check if the date (-u gives the access date, not the modification
date) is set to the time when you last started a vnc session? You have
those times in the xinetd log file, as you posted.

That would indicate that the vnc system at least is reading the file.

Next you could put this command in xstartup:

#! /bin/sh
echo "This is xstartup running on $DISPLAY at $(date)" >>/tmp/vnc-xstartup.log
echo "We are process $$ and our stdout and stderr are connected thus:" >>/tmp/vnc-xstartup.log
ls -l /proc/$$/fd >>/tmp/vnc-xstartup.log
/usr/bin/kdm

but make sure that the path to kdm is the right one for your system.

If you get some dates in the file /tmp/vnc-xstartup.log, but no login
window, try the far more basic

#! /bin/sh
echo "This is xstartup running on $DISPLAY at $(date)" >>/tmp/vnc-xstartup.log
export PATH=/usr/X11R6/bin:/usr/local/bin:/usr/bin:/bin
xterm &

You can add more to this setup once it shows some signs of life.

-Enrique