init.d script experience?

[Tim Caswell]

I was wondering if anyone on the list had any init.d script experience.
I'm deploying some sample node apps on my production server to see how
well it scales. I'm using nginx to serve up the static files and then
pass the rest through via a reverse proxy to the running node app.

I plan to have several node apps running on different ports, and would
like to automate this. Currently I just have a screen session for each
running in the background.

I'm willing to work on the script myself, but I'm just wondering if
anyone would like to help and/or give suggestions.

Here is my desired feature list.

* the start command reads through a config file and/or config directory
that contains site configs
* Each config will have the script to run and the port to run it on
* config will have a path to log the output of the script
* also I would like to have a flag to enable auto restart, possibly
using run.js or via simple bash scripting. This isn't as important
though, just handy
* stop would terminate all the node instances
* restart would simply stop and start everything

Basically I want a way to define all my apps in static configs and then
have the services autostart on reboot.

Also, I seem to remember reading somewhere in the docs that we currently
don't support unix named sockets. I would much prefer this since my
apps won't be directly accessible to the public, but only to the nginx
reverse proxy. Nginx supports named sockets, and I would like the added
performance and security for my node apps.

I'm running Ubuntu 9.04 BTW, I know other distros have slightly
different init.d script setups.

--Tim Caswell

[Joshaven Potter]

I would start by modifying my "thin" init script... here is what I have ( cat /etc/init.d/thin ):

#!/bin/sh
### BEGIN INIT INFO
# Provides:          thin
# Required-Start:    $local_fs $remote_fs
# Required-Stop:     $local_fs $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      S 0 1 6
# Short-Description: thin initscript
# Description:       thin
### END INIT INFO

# Original author: Forrest Robertson

# Do NOT "set -e"

DAEMON=/usr/bin/thin
SCRIPT_NAME=/etc/init.d/thin
CONFIG_PATH=/etc/thin

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

case "$1" in
  start)
        $DAEMON start --all $CONFIG_PATH
        ;;
  stop)
        $DAEMON stop --all $CONFIG_PATH
        ;;
  restart)
        $DAEMON restart --all $CONFIG_PATH
        ;;
  *)
        echo "Usage: $SCRIPT_NAME {start|stop|restart}" >&2
        exit 3
        ;;
esac

:

one of my thin configs from /etc/thin looks like: ( cat /etc/thin/joshaven.com ):
---
user: www-data
group: www-data
pid: /tmp/pids/thin.pid
address: 127.0.0.1
timeout: 30
port: 8001
log: log/thin.log
max_conns: 1024
require: []

environment: production
max_persistent_conns: 512
servers: 2
chdir: /home/joshaven/apps/joshaven.com/



Its clean and logical... if your looking for more then some ideas ask... I have extensive experience with production servers and would be interested in helping you solve this issue because I will soon need to implement the same thing for my use.  I had hoped to have had need to implement this already but alas, I cannot seem to get out from under my current project in a timely manner.

--
Sincerely,
Joshaven Potter

"No man making a profession of faith ought to sin, nor one possessed of love to hate his brother. For He that said, “Thou shalt love the Lord thy God,”  said also, “and thy neighbor as thyself.”  Those that profess themselves to be Christ’s are known not only by what they say, but by what they practice. “For the tree is known by its fruit.”" -- Ignatius

[Joshaven Potter]

By the way, I would highly recommend running haproxy.  You can setup haproxy to do better load balancing then nginx.

an example could be:
joshaven.com is served from nginx to haproxy on port 8000
the app runs on ports 8001-8010 with 9 processes.
haproxy would answer on port 8000 to nginx with the response from the first avilable process.

Nginx, for example, will serve in sequence so a request could be sent to a process that is currently busy (due to a long running request) even when others are free.  haproxy can load balance based upon availability which, to my knowledge it, is not yet a feature of nginx.

[ryan dahl]

On Mon, Jul 27, 2009 at 8:16 PM, Joshaven Potter<your...@gmail.com> wrote:
> By the way, I would highly recommend running haproxy.  You can setup haproxy
> to do better load balancing then nginx.
>
> an example could be:
> joshaven.com is served from nginx to haproxy on port 8000
> the app runs on ports 8001-8010 with 9 processes.
> haproxy would answer on port 8000 to nginx with the response from the first
> avilable process.
>
> Nginx, for example, will serve in sequence so a request could be sent to a
> process that is currently busy (due to a long running request) even when
> others are free.  haproxy can load balance based upon availability which, to
> my knowledge it, is not yet a feature of nginx.

This is totally off topic: I've written an NGINX module for which
implements a haproxy-like load balancing:
http://github.com/ry/nginx-ey-balancer/tree/master

[Tim Caswell]

Good stuff, I think I'll stick with nginx since I'm using it for
passenger on some ruby sites as well. I'll look into ry's module.

I just got a ping from some customers, so it's back to normal work for
the next few hours, but before that happened, I was able to port the
wsgi backend to my SousaBall game to a node server. It's currently at
http://sousaball.creationix.com.

Since github seems to be down at the moment, I put temporary symlinks to
the js files that you can access here:

http://sousaball.creationix.com/app.js
http://sousaball.creationix.com/http_server.js

http_server.js is basically fu.js from the chat server, but with the
static file handling pulled out and a regular expressions and parameters
added to the routing system.

[Chris Wanstrath]

On Mon, Jul 27, 2009 at 11:36 AM, Tim Caswell<creat...@gmail.com> wrote:

> Since github seems to be down at the moment, I put temporary symlinks to
> the js files that you can access here:

Maybe we should move to node.js ;)

--
Chris Wanstrath
http://github.com/defunkt

[Tim Caswell]

I see that thin is doing all the heavy lifting of looping through the
config files and parsing the settings, would it be a good idea to put
the same capabilities into node itself, or should I just code it all up
in bash inline or in a separate helper script?

Joshaven Potter wrote:
> case "$1" in
> start)
> $DAEMON start --all $CONFIG_PATH
> ;;
> stop)
> $DAEMON stop --all $CONFIG_PATH
> ;;
> restart)
> $DAEMON restart --all $CONFIG_PATH
> ;;
> *)
> echo "Usage: $SCRIPT_NAME {start|stop|restart}" >&2
> exit 3
> ;;
> esac
>
> :
>
> one of my thin configs from /etc/thin looks like: ( cat

> /etc/thin/joshaven.com <http://joshaven.com> ):

> ---
> user: www-data
> group: www-data
> pid: /tmp/pids/thin.pid
> address: 127.0.0.1
> timeout: 30
> port: 8001
> log: log/thin.log
> max_conns: 1024
> require: []
>
> environment: production
> max_persistent_conns: 512
> servers: 2

> chdir: /home/joshaven/apps/joshaven.com/ <http://joshaven.com/>
>
>

[Joshaven Potter]

I cannot beat: http://sousaball.creationix.com/tim/large

I have can get it down to one ball... and I don't what the [?] block does.

[Tim Caswell]

It's not the spinning that slows the game, you have to redraw the ball
regardless of it's orientation, the performance issue is scrolling the
page. But as far as the large level goes, it's not beatable currently.
I need to tweak the code to check for goal completion BEFORE creating
new coins from triggers.

[Joshaven Potter]

Oh... so I'm not a total looser!

An interesting element, although large... would be the ability to draw a level and share it with a friend to complete.  Like a 'challenge'.

[Tim Caswell]

Feel free to fork my project or email me directly, but we probably
shouldn't spam the mailing list with discussion of my game. ;)

Thanks for the pointers on the init.d script though.

Joshaven Potter wrote:
> Oh... so I'm not a total looser!
>
> An interesting element, although large... would be the ability to draw
> a level and share it with a friend to complete. Like a 'challenge'.
>
>
> On Mon, Jul 27, 2009 at 3:38 PM, Tim Caswell <creat...@gmail.com
> <mailto:creat...@gmail.com>> wrote:
>
>
> It's not the spinning that slows the game, you have to redraw the ball
> regardless of it's orientation, the performance issue is scrolling the
> page. But as far as the large level goes, it's not beatable
> currently.
> I need to tweak the code to check for goal completion BEFORE creating
> new coins from triggers.
>
> Joshaven Potter wrote:
> > I cannot beat: http://sousaball.creationix.com/tim/large
> >
> > I have can get it down to one ball... and I don't what the [?]
> block does.
> >
> >
> >
> > On Mon, Jul 27, 2009 at 2:59 PM, Tim Caswell
> <creat...@gmail.com <mailto:creat...@gmail.com>

[Brian Hammond]

Beware that haproxy does not support keep-alive.