program fails when run from bootup script

[dsollen]

okay I've got a Linux box that needs to run the software we have been developing. I've set it up and the software runs perfect when I manually run a script file as root. I moved the same script file over to ect/init.d and linked it to the etc/rc5.d/ folder to try to get it to run at boot up.

The program runs as wanted, but it doesn’t work properly. Specifically the program should create 5 VNC servers and monitor them (amongst other things) but the VNC servers all return an error code when the program attempts to boot them. My program continues to try restarting the VNC servers and fails long after boot up has finished.

I know the program is running as root from boot up and it is successfully outputting to serial out as it should too. I tried putting a 1 minute sleep in my bootup script prior to starting the program to make sure everything had booted first but that doesn’t work either. I've also tried moving the command from rc5.d to the rc.local which didn't do anything.

as I said if i manually run the script after bootup (as root) it works fine. Any idea what the difference would be between manual and automatically running it?

[Rubberman]

Have you tried running your script from rc.local? That is run after all the other startup scripts have executed.

[HROAdmin26]

Any idea what the difference would be between manual and automatically running it?

Yes, lots. Mainly the user environment. Is it starting as the necessary user - are all of the needed shell parameters being initialized (path variable, etc.)?

You stated that an error is thrown. Troubleshoot the error - otherwise you are just guessing.

[Rubberman]

BTW, have you tried configuring the Xvnc server to run when connected with inetd/xinetd? That way, you won't need to start the servers in advance. That's what I do, so it starts the desktop session as soon as the client connects to my Linux server system. From the Xvnc man page:

USAGE WITH INETD
       By  configuring  the  inetd(1) service appropriately, Xvnc can be launched on
       demand when a connection comes in, rather than having to be started manually.
       When  given  the -inetd option, instead of listening for TCP connections on a
       given port it uses its standard input and standard  output.   There  are  two
       modes controlled by the wait/nowait entry in the inetd.conf file.

       In  the  nowait mode, Xvnc uses its standard input and output directly as the
       connection to a viewer.  It never has a listening socket,  so  cannot  accept
       further  connections  from  viewers  (it can however connect out to listening
       viewers by use of the vncconfig program).  Further viewer connections to  the
       same  TCP port result in inetd spawning off a new Xvnc to deal with each con-
       nection.  When the connection to the viewer dies, the Xvnc and any associated
       X  clients  die.   This behaviour is most useful when combined with the XDMCP
       options -query and -once.  An typical example in inetd.conf might be (all  on
       one line):

       5950    stream    tcp  nowait  nobody  /usr/local/bin/Xvnc Xvnc -inetd -query
       localhost -once securitytypes=none

       In this example a viewer connection to :50 will result in a new Xvnc for that
       connection  which  should  display  the  standard  XDM  login  screen on that
       machine.  Because the user needs to login via XDM, it is usually OK to accept
       connections without a VNC password in this case.

       In the wait mode, when the first connection comes in, inetd gives the listen-
       ing socket to Xvnc.  This means that for a given TCP port, there is only ever
       one Xvnc at a time.  Further viewer connections to the same port are accepted
       by the same Xvnc in the normal way.  Even when  the  original  connection  is
       broken,  the  Xvnc  will  continue  to  run.   If this is used with the XDMCP
       options -query and -once, the Xvnc and associated X clients will die when the
       user  logs  out of the X session in the normal way.  It is important to use a
       VNC password in this case.  A typical entry in inetd.conf might be:

       5951   stream   tcp wait   james     /usr/local/bin/Xvnc Xvnc  -inetd  -query
       localhost -once passwordFile=/home/james/.vnc/passwd

       In  fact typically, you would have one entry for each user who uses VNC regu-
       larly, each of whom has their own dedicated TCP port which they use.  In this
       example,  when user "james" connects to :51, he enters his VNC password, then
       gets the XDM login screen where he logs  in  in  the  normal  way.   However,
       unlike  the  previous example, if he disconnects, the session remains persis-
       tent, and when he reconnects he will get the same session back  again.   When
       he logs out of the X session, the Xvnc will die, but of course a new one will
       be created automatically the next time he connects.

[dsollen]

heh. thanks for all the replies. now my responces in the order they were received

yes I have tried rc.local as well, i get the same thing.

The 'error message' i get is just a return code of 1 which VNC seems to return for every error. VNC does have log files but apparntly it dosn't bother to output anything to them unless it has succesfully started so I don't know anything about why it failed

The only system variable I can think of that is used is the DISPLAY variable, but that is used by the programs running on the VNC servers that won't start, and the VNC should be explicitly setting that anyways. I do however make a number of system calls in the monitoring program, most obviously the call which starts VNC. Plus VNC may use shell variables I don't know about.

It's interesting to know VNC can be configured to start on demand, but we explicitly want the servers running in advance. There are time constrants on the program and it was decided it was best to have all the programs started and configured prior to a user logging in to allow quicker responce times.

I had thought that I could try moving the startup script to run at logon instead of bootup. If I did that I think I would then have to use gdmsetup to arrange to automatically log in. Does that sound like it would work? (can't get to the box to try it untill Monday, but thought I would ask now to get feedback so I don't waste my time if you guys don't think it would help).

[HROAdmin26]

If you have delayed starting your program until a few minutes after system boot, then that should rule out some subsystem "not being ready yet" - which is a common issue for boot-time startups.

Yes, you could set an auto login that then starts your program, but I think that would only confirm what you already know. It is worth trying to confirm the expected results.

You may want to look at using strace on your program and/or VNC. Compare an strace of a successful start to an strace of a failed start and you may find your call failure.

Linux strace

[dsollen]

okay it now seems to be working when I run it at login instead of boot up (still don't know why unfortunatly). Untill now i've been lazy and had only root user on the box, now I'm going to have to make a user to auto-login and run my program.

I don't know how to do this securly though. The program itself has to run as root which I figured ment giving limited sudo access to whatver use i created. The problem is the program is a java program. If I give sudo permision to the java command all it takes is a hastly written java file with a few system calls and you have root access. Is there a way to give sudo privliages to run java as root only for my java program? or mabye just a better way to handle permissions?

I'm not use to this whole 'security' thing. my own computer even had telnet port open for months because I didn't care enough to secure it