Re: VNC Configuration in Suse Linux 9.2 - No logon prompt

From: Enrique Perez-Terron (
Date: 09/25/05

Date: Sun, 25 Sep 2005 03:23:23 +0200

On Sat, 24 Sep 2005 23:15:00 +0200, John Howell <>

> Enrique Perez-Terron wrote:
>> On Fri,sessionnp 2005 22:43:37 +0200, John Howell <>
>> 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
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:5:once:/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/ ] && . /etc/profile.d/

This line says that the file /etc/profile.d/, 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)


>> 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.