I have to run this post as two pieces because the BBoard has a bug, and it’s the only way to get this combination of symbols into a post. So here’s part one:
I have a simple script called tightvnc.sh at location /home/john/scripts/tightvnc.sh
It works fine when called manually, starting a TightVNC server.
I want to start it as a service. So I copy the file /etc/init.d/skeleton to /etc/init.d/tightvnc. I make sure the new file is executable. I edit the segment titled “### BEGIN INIT INFO” so it now reads like this:
Then I activae with this root CLI command → chkconfig -a tightvnc which responds like so:
suse110:/home/john # chkconfig -a tightvnc
insserv: script skeleton.compat: service FOO already provided!
tightvnc here it shows runlevels 3 & 5 on – wretched vile bulletin board won’t work properly
I reboot and the service has not started. It exists in Yast → System → Runlevels with the status “Enabled = Yes*”. The asterisk means there’s some problem. I use the button to “Enable” again and get a message that “program is not configured”
I open a shell as root and issue command “/etc/init.d/tightvnc start” and get this message: “/etc/sysconfig/FOO not existing”.
This was done on guesswork, so please help me fix this. Looks like the /etc/sysconfig thing I suppose, but I’m out of guesses.
You need to change all instances of FOO to whatever your service is called, say myservice. That message is caused by the line Provides: FOO. Since the skeleton already provides FOO… In some places if it’s not appropriate to have say an /etc/sysconfig/myservice then you should delete the code. It’s ok to modify the template code to suit your situation.
Thanks guys. I changed it as per malcolmlewis advice. I moved the script to root’s territory and ran all as root. I still got the display in Yast’s runlevels display as “Yes*” with an asterisk and it wouldn’t start at boot time. However if i ran the command “/etc/init.d/tightvnc start” the service started fine.
I tested the form of startproc but couldn’t get an advantage.
I’m beyond my depth now. I feel there’s a clue in that it starts with “/etc/init.d/tightvnc start”, but I don’t know enough to track it down.
Usually if something is configured to start at boot and doesn’t, but
then does start immediately once you are booted, it’s because some
dependency was not met. For example VNC requires the network so was
networking fully functional by the time VNC tried to start? In your
/etc/init.d/tightvnc script at the top are a few lines that are
commented out, but which are understood and handled by ‘chkconfig’ and
therefore Yast.
Required-Start:
This line is the most important and, for most networking apps, includes
a requirement that $network be up and running.
You can test this theory manually by renaming your startup softlink in
/etc/init.d/rc<runlevelNumber>.d/S??tightvnc to
/etc/init.d/rc<runlevelNumber>.d/S99tightvnc, effectively making
tightvnc the last thing to load in this way (or at least nearly tied for
last). Give it a shot and post back.
Good luck.
swerdna wrote:
> Thanks guys. I changed it as per malcolmlewis advice. I moved the script
> to root’s territory and ran all as root. I still got the display in
> Yast’s runlevels display as “Yes*” with an asterisk and it wouldn’t
> start at boot time. However if i ran the command “/etc/init.d/tightvnc
> start” the service started fine.
>
> I tested the form of startproc but couldn’t get an advantage.
>
> I’m beyond my depth now. I feel there’s a clue in that it starts with
> “/etc/init.d/tightvnc start”, but I don’t know enough to track it down.
>
> Any thoughts?
>
> Swerdna
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
If necessary you can insert some debug statements in the init file to let you know what it’s up to. Write the report to a temp file so you don’t have to figure which log file it went to:
echo Starting tightvnc >> /tmp/debug.log
# you can also capture error messages from your program
# I'm guessing the syntax of your tightvnc command, fix it to suit
tightvnc >> /tmp/debug.log 2>&1 &
echo Finished starting tightvnc >> /tmp/debug.log
Malcolm wrote:
> [QUOTE=swerdna]
> Thanks guys. I changed it as per malcolmlewis advice. I moved the script
> to root’s territory and ran all as root. I still got the display in
> Yast’s runlevels display as “Yes*” with an asterisk and it wouldn’t
> start at boot time. However if i ran the command “/etc/init.d/tightvnc
> start” the service started fine.
>
> I tested the form of startproc but couldn’t get an advantage.
>
> I’m beyond my depth now. I feel there’s a clue in that it starts with
> “/etc/init.d/tightvnc start”, but I don’t know enough to track it down.
>
Now that your script works, you need to su to root, change directory to
/etc/init.d/rc5.d, and create a link back to that script in /etc/init.d. The
stuff in the rcX.d directories is run in alphabetical order, thus you need to
start it after all the prerequisites are started. It should be safe to start it
last by issuing the command
ln -s S99tightvnc …/tightvnc
If you want to kill the service when shutting down, then you will need
ln -s K01tightvnc …/tightvnc
The above two commands will take care of run level 5. Do the same two commands
in /etc/init.d/rc3.d to get tightvnc started and stopped at run level 3.
ab@novell.com → I have it set only for runlevel 5 now. I looked in rc5.d and nothing of note was after the link back to /etc/init.d/tightvnc. Nevertheless I renamed the link to S99tightvnc. I also added $network to the list of services that start first in the line “# Required-Start:”
There was no improvement. The service still starts later via the command /etc/init.d/tightvnc start.
@lwfinger → as above covers your link back suggestion I think
@malcolmlewis → I’m reserving the issue of su and startproc to later, preferring to uncomplicate things by running as root first. It’s totally unsatisfactory to serve a root desktop via VNC, so I have to confront the issue, but later when the service is at least starting.
@ken_yap The log file shows a very interesting clue:
Starting tightvnc
Finished starting tightvnc
vncserver: The USER environment variable is not set.
The script invokes the program /usr/bin/vncserver. The program vncserver itself invokes the program /usr/bin/Xvnc. Man vncserver and man Xvnc have no reference to an environment variable. Before I track those further, could the log relate to a problem within the ecript /etc/init.d/tightvnc?
swerdna wrote:
> Here’s what I did:
>
> ab@novell.com → I have it set only for runlevel 5 now. I looked in
> rc5.d and nothing of note was after the link back to
> /etc/init.d/tightvnc. Nevertheless I renamed the link to S99tightvnc. I
> also added $network to the list of services that start first in the line
> “# Required-Start:”
> There was no improvement. The service still starts later via the
> command /etc/init.d/tightvnc start.
>
> @lwfinger → as above covers your link back suggestion I think
>
> @malcolmlewis → I’m reserving the issue of su and startproc to later,
> preferring to uncomplicate things by running as root first. It’s totally
> unsatisfactory to serve a root desktop via VNC, so I have to confront
> the issue, but later when the service is at least starting.
>
> @ken_yap The log file shows a very interesting clue:
>> Starting tightvnc
>> Finished starting tightvnc
>> vncserver: The USER environment variable is not set.
> The script invokes the program /usr/bin/vncserver. The program
> vncserver itself invokes the program /usr/bin/Xvnc. Man vncserver and
> man Xvnc have no reference to an environment variable. Before I track
> those further, could the log relate to a problem within the ecript
> /etc/init.d/tightvnc?
During these startup routines, you cannot assume any environment variables. If
you know what user should be running this procedure (perhaps root), you should
add the following:
USER=root
export USER
If this doesn’t fix it, it could be that the startup process is still occurring
too early despite the S99… You might try adding a sleep statement to the start
portion of tightvnc.
Perhaps it has dependencies on X then… and X isn’t loaded yet. Maybe
throw in a pause… thirty seconds or so… at the top of
/etc/init.d/tightvnc ?
Good luck.
Larry Finger wrote:
> swerdna wrote:
>> Here’s what I did:
>>
>> ab@novell.com → I have it set only for runlevel 5 now. I looked in
>> rc5.d and nothing of note was after the link back to
>> /etc/init.d/tightvnc. Nevertheless I renamed the link to S99tightvnc. I
>> also added $network to the list of services that start first in the line
>> “# Required-Start:”
>> There was no improvement. The service still starts later via the
>> command /etc/init.d/tightvnc start.
>>
>> @lwfinger → as above covers your link back suggestion I think
>>
>> @malcolmlewis → I’m reserving the issue of su and startproc to later,
>> preferring to uncomplicate things by running as root first. It’s totally
>> unsatisfactory to serve a root desktop via VNC, so I have to confront
>> the issue, but later when the service is at least starting.
>>
>> @ken_yap The log file shows a very interesting clue:
>>> Starting tightvnc
>>> Finished starting tightvnc
>>> vncserver: The USER environment variable is not set.
>> The script invokes the program /usr/bin/vncserver. The program
>> vncserver itself invokes the program /usr/bin/Xvnc. Man vncserver and
>> man Xvnc have no reference to an environment variable. Before I track
>> those further, could the log relate to a problem within the ecript
>> /etc/init.d/tightvnc?
>
> During these startup routines, you cannot assume any environment variables. If
> you know what user should be running this procedure (perhaps root), you should
> add the following:
>
> USER=root
> export USER
>
> If this doesn’t fix it, it could be that the startup process is still occurring
> too early despite the S99… You might try adding a sleep statement to the start
> portion of tightvnc.
>
> Larry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
There is some form of dependency. I’ve found lock files in /tmp/.X11-unix of form X0 and X1. X0 is a lock for the standard XWindow and X1 is a lock for TightVNC window on port 5901. They are only generated after the windows start. So X1 shows that the VNC window did start – but despite the X1 evidence that a TightVNC windows did start, it doesn’t exist after the boot process settles.
So I will investigate further, but in interests of sanity I’ll take a few days off first.