World: r3wp

old .. yeah, but since I haven't had any issues, I don't change the 
server apps

That's usually a good rule.

So, I guess no point trying to produce this error since I am using 
an old server build

Right, there's more than 90 SVN revisions since july-2009...

Is anyone using Cheyenne in an environment where they also use Ladislav's 
INCLUDE? The RSP handler has its own global INCLUDE func, which I 
think will conflict.

I am not, but last time I "felt" an Include conflict, it was very 
easy to resolve, in fact

I'm sure it can be resolved. And if someone else has done it in such 
a way that you and Doc approve, I'll gladly borrow from them. :-)

Gregg: 'include is not used internally by RSP engine, so you can 
freely redefine it, like that for example (not tested but should 
work) :

in %app-init.r :

on-application-start: does [

 set 'rsp-include :include 	;-- use 'rsp-include now for RSP script 
 inclusion

 unprotect 'include	;-- 'include is mark as protected by the RSP engine
	do %include.r 	              ;-- Ladislav's include script
]

So, this is a local 'do and not the '*do ?

Depends if you want to keep that local to your webapp or share it 
for all your webapps (using do/global or *do in that case).

So, yes, it's a local 'do in my example above.

Thanks Doc.

Thanks again Doc, that lets me run things using INCLUDE. Now I'm 
on to the next issue, which is that it doesn't work (i.e. INCLUDE 
gets messed up) after running any kind of RSP. I'll dig in when I 
get a chance and tell you what I find.

did you try *do ?

Gregg: I'll give it a try today to see what's going wrong.

Graham, no I didn't. 

Doc, not critical by any means, but thanks.

Does anybody has init.d script for cheyenne?

ok.. I'm not sure if this is the best way, but it seems to be working 
for me:
#! /bin/sh
# /etc/init.d/cheyenne
#

# Some things that run always
#touch /var/lock/blah

STARTSCRIPT=/web/start-ch.sh

# Carry out specific functions when asked to by the system
case "$1" in
  start)
    echo "Starting Cheyenne "
    $STARTSCRIPT
    RETVAL=$?
    ;;
  stop)
    echo "Stopping Cheyenne"

    ps aux | awk '/cheyenne/ && !/worker/ && !/bin/ {print "kill -9 "$2}' 
    | sh
    RETVAL=$?
    ;;
  reload)
    echo "Reloading Cheyenne"

    ps aux | awk '/cheyenne/ && !/worker/ && !/bin/ {print "kill -HUP 
    "$2}' | sh
    RETVAL=$?
    ;;
  reset)
    echo "Reseting Cheyenne"

    ps aux | awk '/cheyenne/ && !/worker/ && !/bin/ {print "kill -USR1 
    "$2}' | sh
    RETVAL=$?
    ;;
  restart)
    echo "Stopping Cheyenne"

    ps aux | awk '/cheyenne/ && !/worker/ && !/bin/  {print "kill -9 
    "$2}' | sh
    echo "Starting Cheyenne"
    $STARTSCRIPT
    RETVAL=$?
    ;;
  *)

    echo "Usage: /etc/init.d/cheyenne {start|stop|reload|reset|restart}"
    exit 1
    ;;
esac

exit 0

Gregg: my solution was missing a 'unset call too (tested with Cheyenne 
sample webapp, works ok) : 

on-application-start: does [
	set 'rsp-include :include
	unprotect 'include

 unset 'include				;-- this one is required to allow %include.r to 
 load properly
	do/global %include.r
	set 'include-path [%//dev/Cheyenne/www/testapp/]
]

Oldes: we have one here somewhere, but I can't find it right now. 
Anyway: 
 

1) "kill -9" is not a good way to stop Cheyenne, a simple "kill" 
is the right way (this signal is caught by Cheyenne to clean up things 
and exit properly).


2) "ps aux | awk ..." is not required, Cheyenne stores its main PID 
in /var/run/cheyenne.pid (or /tmp/cheyenne.pid in revisions < r90). 
Just read this PID and send all signals to that process only. Watch 
out if you run it on port <> 80, you'll find the port-id inserted 
in the PID file name.

The problem with the PID file is, that I was not able to read it 
because of permisions. But I may check it again.

The PID file should have the same rights as the Cheyenne process, 
let me see if this works as it should.

The PID file is still own by root in that case. It's readable by 
other users but not writable (Cheyenne can't delete it on exiting). 
I need to fix that.

It seems that the PID file location recent change was a bad move, 
/var/run is by default only writable by root...To workaround that, 
user should create a sub-folder as root and then chown it to the 
application user to allow it to write PID files there : http://serverfault.com/questions/159334/what-permission-to-write-pid-file-in-var-run

Kaj: so, this means that an install script would be required for 
Cheyenne to be able to run on UNIX, this is not something that I 
want for Cheyenne unless really necessary. Do you see any simple 
solution to that issue? If not, I'll revert it to write in /tmp by 
default and add a config option to let users choose alternative location 
when desired.

I'll have to do some more digging Doc, and maybe see what do* does 
since I haven't tried that. I'll actually read some source if need 
be. ;-) 


What I saw with your new change is something I also saw once with 
the previous approach. Plain CGI worked fine until an RSP was run, 
then the CGI failed, *then* both the test RSP and test RSP web app 
started returning with garbage at the top of the page. More garbage 
each time, like a buffer was being added to. Then the plain CGI worked 
again. Doing a reset on the workers solves the garbage problem.


My Cheyenne EXE is from 2009 so I'll check for a new one before doing 
anything else.

Also, the version I have still says "> Catched Error <" which might 
read better as "> Caught Error <". That may be in recent versions.

From 2009 -> more than 90 revisions since then, these issues have 
been solved a long time ago :-)

Are you using the official binary v0.9.19?

It looks like I really need to make a new official release with new 
binaries.

The EXE doesn't list the Cheyenne version, and I dont think the server-software 
result gives that either, so what's the best way to check?

>> p: open http://domain.com
>> p/locals/headers/server

Cheyenne/0.9.19

So here is my new init.d file:
#! /bin/sh
# /etc/init.d/cheyenne
#

# Some things that run always
#touch /var/lock/blah

STARTSCRIPT=/web/start-ch.sh
PID=$(tail /tmp/cheyenne-8000.pid)

# Carry out specific functions when asked to by the system
case "$1" in
  start)
    echo "Starting Cheyenne "
    $STARTSCRIPT
    RETVAL=$?
    ;;
  stop)
    echo "Stopping Cheyenne"
    kill $PID
    RETVAL=$?
    ;;
  reload)
    echo "Reloading Cheyenne"
    kill -HUP $PID
    RETVAL=$?
    ;;
  reset)
    echo "Reseting Cheyenne"
    kill -USR1 $PID
    RETVAL=$?
    ;;
  restart)
    echo "Stopping Cheyenne"
    kill $PID
    echo "Starting Cheyenne"
    $STARTSCRIPT
    RETVAL=$?
    ;;
  *)

    echo "Usage: /etc/init.d/cheyenne {start|stop|reload|reset|restart}"
    exit 1
    ;;
esac

exit 0


(maybe it should be put on the wiki or into the repository to help 
other linux newbies)

(the last line should be:
exit $RETVAL
instead of:
 exit 0

Looks much better, thanks for your contribution, I'll copy/paste 
it on Cheyenne's wiki.

btw.. the /web/start-ch.sh looks like:
#!/bin/bash
cd /web/
./cheyenne &

I must use it because running cheyenne using full path like:
/web/cheyenne &

does not work as expected - it looks it does not gets the httpd.cfg 
file (probably)

hm.. maybe I could just skip to the directory in the init.d script.

yes.. it works:)

and the final init.d script is ?  :)

replaced $STARTSCRIPT with:
cd /web/
./cheyenne &

where the folder may be different so it's probably good to use it 
as variable

Kaj: so, this means that an install script would be required for 
Cheyenne to be able to run on UNIX, this is not something that I 
want for Cheyenne unless really necessary. Do you see any simple 
solution to that issue? If not, I'll revert it to write in /tmp by 
default and add a config option to let users choose alternative location 
when desired.

Hm, avoiding installers is good, so I guess a config option is readable

Packages for Linux package managers do indeed come with stuff to 
install into /var/

readable -> reasonable

If you want it, I can make the binary packages for deb, RPM and TGZ. 
 I already done it for Rebol, so it's easy for me. My email is [maxint-:-tiscali-:-it]

MaxV: thanks for the offer, but it's not required for now  as there's 
only one file to distribute (when encapped).

SVN revision 93:

o FEAT: new config keyword 'pid-dir for setting user-defined folder 
for Cheyenne's PID file.

o FEAT: Cheyenne's SVN global revision number now appended to Server 
response header.

o FIX: default location for %cheyenne.pid is reverted back to /tmp.

o FIX: PID file now takes the correct process uid:gid when Cheyenne 
is not run as root.

Nice

I'm able now to run Cheyenne as not-root, works ok so far, the only 
remaining issue is the first REBOL side process that stays as root 
(it's not a serious security threat anyway). I'll write a How-To 
for that in  the next days and will post it in the wiki (with Kaj's 
scripts also).

I take it we will still be able to run as root if we want to ?