Trouble getting script to run, non-writable folder?


Bbjimmy wrote a script (“launchvnc”) for us that worked great for years, but we’ve recently updated the Haiku version. On our old system, the launchvnc script restarted the vncserver every 2 hours. We were having an issue where vncserver would quit working, even though it was still running. The script fixed that problem and worked well. On that old system, the script ran from /boot/home/config/bin, but this later version of Haiku won’t allow write-permissions to that folder. I tried a workaround by putting the script and the vncserver binary in a writable folder (/boot/home/vnc), but it won’t re-start after the 2-hour timeout. Any tips on how to get this to work? Here’s the script I have on the system now. It does start vncserver when running running the script, but won’t re-start vncserver. Thanks for any help.


echo $PID > /boot/home/config/settings/
sleep 2h
for line in $(cat /boot/home/config/settings/
kill $line

launchvnc &


Is the file marked as executable? BTW, I’d put the script in /boot/home/config/non-packaged/bin to make it available to the command line.


Oh, the script could be simpler:

sleep 2h
kill $PID
launchvnc &

Or another way, if you install vncserver to /boot/home/config/non-packaged/bin, or use the pre-packaged install .hpkg file (which puts it in /boot/system/bin also aliased as /bin):

while true
  vncserver Log=*:stdout:100 BlacklistTimeout=720 BlacklistThreshold=3 PortNumber=5900 &
  sleep 2h
  kill vncserver
  sleep 1s


To make it even safer, you can replace the sleep 1s with waitfor -e vncserver.
That’ll always wait until the old vncserver thread has disappeared.


I don’t see anything obvious. Does the script still kill vncserver after 2 hours? Could be that the last line fails because launchvnc isn’t in PATH.

I like that agmsmith’s 2nd version just loops and doesn’t recursively call itself, which coincidentally avoids that problem.

You’ll be able to see for yourself what’s actually going wrong, if you create a log file where you can look at errors encountered during execution. The script itself can do that, if you like, with the “exec” shell command - “exec > /tmp/logfile 2>&1” The exec command normally executes a file in the same process, terminating the shell, but with no file mentioned it just operates on the current redirections. The above redirects standard output unit 1 to /tmp/logfile, and makes error output unit 2 a duplicate of that unit.

The file is kind of wasted on some unnecessary shell folderol here, but would give the script the ability to deal with an existing vncserver. Something like


# function to output first "ps" column on line(s) where 3rd-from-last column
# matches the function parameter.
pidexe () { ps | awk -vPID=$1 '$(NF-3) == PID { print $1 }' ; }

# function to kill $PROGRAM when it's running under the specified PID
killvnc () {
   case $(pidexe $1) in
       echo VNC server already running, PID $1 >&2
       kill $1

if pid=$(cat $PIDFILE) && kill -0 $pid
then killvnc $pid

echo $pid > $PIDFILE

This is a more complicated/fun way to do what “kill vncserver”, “waitfor vncserver”, etc. are doing, which is cheating because you can’t do that on UNIX.


Thanks guys! It’s working now. I put the script in /boot/home/config/non-packaged/bin and that fixed the problem.


Did you report the bug to vncserver as well?


I already know about that occasional lockup bug; it’s something to do with the BeOS network stack. The commercial version (TTAnywhere) has a GUI in a separate program and periodically probes the server to see if it is still alive, if not, it gets killed and restarted. Sort of like that script, except it uses BMessages to test aliveness rather than waiting 2 hours.


Does this still occur on Haiku? If so, a bug should be filed. (Our network stack is completely different than Be’s, though.)


Is it useful to test with the Beta1 Haiku? Later versions have that VirtualBox network interference bug.


I didn’t realize it was a bug; thought it had something to do with our local IP or router. We’re using hrev-51795, x86-gcc2, Feb. 11, 2018 kernel. Our SSH connection is doing the same thing. Shows it’s running, but can no longer connect at random time intervals, so I kill the sshd process and re-start it manually.


After a couple of days testing with R1Beta1+117 it seems to still be working; vncserver still responds to network input.