World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
Oldes 28-Sep-2010 [9049x2] | 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 | |
Dockimbel 28-Sep-2010 [9051x2] | 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. | |
Oldes 28-Sep-2010 [9053] | The problem with the PID file is, that I was not able to read it because of permisions. But I may check it again. |
Dockimbel 28-Sep-2010 [9054x4] | 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. | |
Gregg 28-Sep-2010 [9058x2] | 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. | |
Dockimbel 28-Sep-2010 [9060x2] | 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. | |
Gregg 28-Sep-2010 [9062] | 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? |
Dockimbel 28-Sep-2010 [9063] | >> p: open http://domain.com >> p/locals/headers/server |
Gregg 28-Sep-2010 [9064] | Cheyenne/0.9.19 |
Oldes 28-Sep-2010 [9065x2] | 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 | |
Dockimbel 28-Sep-2010 [9067] | Looks much better, thanks for your contribution, I'll copy/paste it on Cheyenne's wiki. |
Oldes 28-Sep-2010 [9068x3] | 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:) | |
Graham 28-Sep-2010 [9071] | and the final init.d script is ? :) |
Oldes 28-Sep-2010 [9072] | replaced $STARTSCRIPT with: cd /web/ ./cheyenne & where the folder may be different so it's probably good to use it as variable |
Kaj 28-Sep-2010 [9073x4] | 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 | |
MaxV 7-Oct-2010 [9077] | 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] |
Dockimbel 7-Oct-2010 [9078x2] | 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. | |
Kaj 7-Oct-2010 [9080] | Nice |
Dockimbel 7-Oct-2010 [9081] | 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). |
GrahamC 7-Oct-2010 [9082] | I take it we will still be able to run as root if we want to ? |
Dockimbel 8-Oct-2010 [9083] | Graham: sure |
Carl 8-Oct-2010 [9084] | Thanks Doc, this is a really good feature for people who need greater security... Chey.93 now running as user "www" rather than root on our new cloud server. |
Dockimbel 8-Oct-2010 [9085] | Great! :) |
Carl 8-Oct-2010 [9086] | So, finally... it's time that I learn how to use the RSP API. |
GrahamC 8-Oct-2010 [9087] | You've been running cgi ? |
Carl 8-Oct-2010 [9088] | On apache, yes. On cheyenne, no. |
Kaj 8-Oct-2010 [9089] | CGI is nicer on Cheyenne because it acts like FastCGI for R2. But if you want to write your scripts in R3, you'll still need slow CGI instead of RSP |
GrahamC 8-Oct-2010 [9090] | slow CGI ? |
Kaj 8-Oct-2010 [9091x2] | And switching away from root still doesn't work with Core |
Traditional CGI, where you start a new process for each request | |
GrahamC 8-Oct-2010 [9093] | Cheyenne has to invoke the r3 interpreter ..? |
Kaj 8-Oct-2010 [9094] | If you want R3 scripts, how else? |
GrahamC 8-Oct-2010 [9095] | send them to try rebol? |
Kaj 8-Oct-2010 [9096] | Then you'll be starting about three layers of shell processes - for security |
GrahamC 8-Oct-2010 [9097] | Actually I wasn't aware that Cheyenne had a mechanism for external cgi .. but I guess it must |
Kaj 8-Oct-2010 [9098] | The only alternative would be implementing a continuous-running R3 application server, instead of using the UniServe taskmaster server. But you'd still have the communication overhead between the processes |
older newer | first last |