Forum: NGINX Nginx as a Linux Service

Hi,

I'm setting up a Production-like environment with a Mongrel cluster and
nginx acting as a load balancer for the Mongrel servers.

Following the instructions in the book "Deploying Rails Applications"
(Pragmatic Programmers), my Mongrel cluster starts up as a Linux
service. But I see no mention of nginx being set up as a service also.

My question is : can nginx be set up as a service in Linux (I'm
currently running Red Hat Linux 4.4), so that it restarts at boot time,
just like the Mongrel servers?

Thanks,

Chris.

Yes , Of-course :)

When you install nginx you will get a startup script /etc/init.d/nginx

Anoop Alias wrote:
> Yes , Of-course :)
> 
> When you install nginx you will get a startup script /etc/init.d/nginx

Thank your for your quick reply. So I first created a symbolic link from 
/etc/init.d/nginx to /usr/local/nginx/sbin/nginx then rebooted, but 
nginx didn't start. So I replaced the symbolic link with a copy of the 
nginx executable, again to no avail...

You can tell I'm not a Linux expert, but what am I missing?

Thanks,

Chris.

On 2008-10-30 21:59, Chris Gers32 wrote:
> Anoop Alias wrote:
>> Yes , Of-course :)
>>
>> When you install nginx you will get a startup script /etc/init.d/nginx
> 
> Thank your for your quick reply. So I first created a symbolic link from 
> /etc/init.d/nginx to /usr/local/nginx/sbin/nginx then rebooted, but 
> nginx didn't start. So I replaced the symbolic link with a copy of the 
> nginx executable, again to no avail...
Using RHEL? So, the command `chkconfig' is a good start.
Here is a simple intro, http://oldfield.wattle.id.au/luv/boot.html.
You'd better read about something on linux boot procedure.
Do NOT think in the M$ way while on an linux box.
It is out of character to discuss SA here.

Better put /usr/local/nginx/sbin/nginx on your /etc/rc.local file
then try to reboot your server

Regards,

Glen Lumanau
-
Sent from my BlackBerry®

On 31.10.08 00:59, Chris Gers32 wrote:
> You can tell I'm not a Linux expert, but what am I missing?
You should add nginx's init script to the default runlevel.
Red Hat's utility for managing init scripts called chkconfig.
So you need to execute something like:
# chkconfig --add nginx

Make sure that /etc/init.d/nginx is executable (chmod 755 will do it).

In RHEL:

  chkconfig --add nginx

  chkconfig --level 235 nginx-on


After that you can confirm with:

  chkconfig --list


You should see nginx listed as "on" at those levels. You can run

/path/to/nginx -t

service nginx reload

to confirm.



If your script doesn't work, this is the one that I use:

#! /bin/sh

### BEGIN INIT INFO
# Provides:          nginx
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts the nginx web server
# Description:       starts nginx using start-stop-daemon
### END INIT INFO


PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/local/sbin/nginx
NAME=nginx
DESC=nginx

test -x $DAEMON || exit 0

# Include nginx defaults if available
if [ -f /etc/default/nginx ] ; then
        . /etc/default/nginx
fi

set -e

case "$1" in
  start)
        echo -n "Starting $DESC: "
        start-stop-daemon --start --quiet --pidfile 
/usr/local/nginx/logs/$NAME.pid \
                --exec $DAEMON -- $DAEMON_OPTS
        echo "$NAME."
        ;;
  stop)
        echo -n "Stopping $DESC: "
        start-stop-daemon --stop --quiet --pidfile 
/usr/local/nginx/logs/$NAME.pid \
                --exec $DAEMON
        echo "$NAME."
        ;;
  restart|force-reload)
        echo -n "Restarting $DESC: "
        start-stop-daemon --stop --quiet --pidfile \
                /usr/local/nginx/logs/$NAME.pid --exec $DAEMON
        sleep 1
        start-stop-daemon --start --quiet --pidfile \
                /usr/local/nginx/logs/$NAME.pid --exec $DAEMON -- 
$DAEMON_OPTS
        echo "$NAME."
        ;;
  reload)
      echo -n "Reloading $DESC configuration: "
      start-stop-daemon --stop --signal HUP --quiet --pidfile 
/usr/local/nginx/logs/$NAME.pid \
          --exec $DAEMON
      echo "$NAME."
      ;;
  *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|force-reload}" >&2
        exit 1
        ;;
esac

exit 0




Hope that helps!

Jim

I realize you're on RHEL rather than Ubuntu (and thus will need to use
chkconfig instead of update-rc.d), but this article might at least
point you in the right direction.

http://articles.slicehost.com/2008/5/13/ubuntu-hardy-adding-an-nginx-init-script

Nick

i'm sure that he has installed nginx from source (.tar.gz). He isn't 
install in using rpm

Regards,

Glen Lumanau
-
Sent from my BlackBerry®

I can't believe the response rate on this forum! Thanks to all of you.

Yes, now I remember that I had to use chkconfig for setting up my 
Mongrel cluster as a service...

But before I try this out, I'd like to know what difference there is 
between copying the nginx executable into /etc/init.d and using 
chkconfig, on one hand, and copying the nginx executable into 
/etc/rc.local, on the other hand.

Thanks again to all you enthusiastic nginx users!

> But before I try this out, I'd like to know what difference there is
> between copying the nginx executable into /etc/init.d and using
> chkconfig, on one hand, and copying the nginx executable into
> /etc/rc.local, on the other hand.

/etc/init.d should contain special init scripts. If you don't have such
script for nginx, you could try to make symlink and use it. But copying
executable directly to that directory is not a good behavior.

/etc/rc.local just executes listed commands after the end of all
multi-user boot levels. Services started this way is not managed through
runlevels properly — for example, when system shutdowns or reboots. So,
you should use it only if you can't use init.d, or if you are too lazy
for it.

Init script for nginx on RedHat/CentOS
P.S. Works for me

#!/bin/bash
# chkconfig: - 58 74
#

# Source function library.
. /etc/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

if [ -f /etc/sysconfig/nginx ];then
        . /etc/sysconfig/nginx
fi

RETVAL=0
prog="nginx"

start() {
  # Check that networking is up.
  [ "$NETWORKING" = "no" ] && exit 1

        echo -n $"Starting $prog: "
        daemon /applications/nginx/sbin/nginx $OPTIONS
  RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/nginx
  return $RETVAL
}

stop() {
        echo -n $"Shutting down $prog: "
  killproc /applications/nginx/sbin/nginx
  RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/nginx
  return $RETVAL
}

# See how we were called.
case "$1" in
  start)
  start
        ;;
  stop)
  stop
        ;;
  status)
  status nginx
  RETVAL=$?
  ;;
  restart|reload)
  stop
  start
  RETVAL=$?
  ;;
  condrestart)
  if [ -f /var/lock/subsys/nginx ]; then
      stop
      start
      RETVAL=$?
  fi
  ;;
  *)
        echo $"Usage: $0 {start|stop|restart|condrestart|status}"
        RETVAL=3
esac

exit $RETVAL

> Better put /usr/local/nginx/sbin/nginx on your /etc/rc.local file
> then try to reboot your server

It's not the right way to manage boot services when you have normal init
script.

Jim Ohlstein wrote:
> In RHEL:
> 
>   chkconfig --add nginx
> 
>   chkconfig --level 235 nginx-on
> 

I read here (http://www.linuxjournal.com/article/4445):

[QUOTE]
Unfortunately, all Linux distributions do not follow the same definition 
for runlevels. Under Red Hat, the following defaults are supported:

   0.   System halt
   1.   Single-user mode
   2.   Multiuser, without NFS
   3.   Complete multiuser mode
   4.   User defined
   5.   X11 (XDM login)
   6.   Reboot
[/QUOTE]

Following the book "Deploying Rails Applications", I did this for 
Mongrel:

sudo /sbin/chkconfig --level 345 mongrel_cluster on

Should I have used 235 instead, or must mongrel_cluster and nginx be 
configured differently? I assume the information in the book was not Red 
Hat-specific...

Thanks,

Chris.

Do this:

chkconfig mongrel_cluster on
chkconfig nginx on

It should be pretty ok!

This is getting a bit far afield, but run level 4 is generally not used.

Run level 3 is the default. Run level 2 is the same as 3 except that 
networking is not running. It's probably irrelevant on a remote machine.

As long as it's set "on" at level 3 it's probably OK.

In RHEL you can also use ntsysv to set any service to start at boot up. 
It provides a visual list with check boxes. I believe that it defaults 
to the current run level which is probably 3.

I assume that you are using a remote server. If you have an old machine 
that you aren't using, installing RHEL or CentOS and adding it to your 
LAN might be really helpful. Worst that can happen is you screw up 
everything and re-install the OS wiser from having learned from your 
mistake.


Jim

Well well, here's a new problem:

[chris@localhost ~]$ sudo /sbin/chkconfig nginx on
service nginx does not support chkconfig
[chris@localhost ~]$ nginx -v
nginx version: nginx/0.6.32[chris@localhost ~]$ /sbin/chkconfig -v
chkconfig version 1.3.13.4

Am I not running the right version of either nginx or chkconfig (came by 
default with my RHEL 4.4 virtual appliance)?

Thanks,

Chris.

How did you install it? Using rpm or from source?

Regards,

Glen Lumanau
-
Sent from my BlackBerry®

I installed it from source:
[chris@localhost ~]$ wget http://sysoev.ru/nginx/nginx-0.6.32.tar.gz
...

Then, after getting an error message during ./configure, I had to 
install the PCRE library:
[chris@localhost ~]$ wget 
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-7.8.tar.gz
...

After the installation was done, nginx seemed to start and stop OK.

I appreciate your help,

Chris.

On Mon, Nov 17, 2008 at 04:14:12PM +0100, Chris Gers32 wrote:
> After the installation was done, nginx seemed to start and stop OK.
> 
> I appreciate your help,

If you activate the EPEL[1] repository, nginx is available for RHEL 
based
systems.  Instructions on the nginx english wiki.

  http://wiki.codemongers.com/NginxPlatformFedora

enjoy,

-jeremy

[1] - http://fedoraproject.org/wiki/EPEL

Try using the start-stop-daemon:

# wget 
http://developer.axis.com/download/distribution/apps-sys-utils-start-stop-daemon-IR1_9_18-2.tar.gz

# tar zxvf apps-sys-utils-start-stop-daemon-IR1_9_18-2.tar.gz

# cd apps/sys-utils/start-stop-daemon-IR1_9_18-2/

# gcc start-stop-daemon.c -o start-stop-daemon

# cp start-stop-daemon /usr/sbin/

Then use the init script at 
http://articles.slicehost.com/2007/10/19/ubuntu-feisty-adding-an-nginx-init-script. 
Copy it to /etc/init.d/nginx and chmod to 755. Then you can add nginx to 
chkconfig. That script assumes that you have nginx in /usr/local/sbin/. 
If it's elsewhere adjust the path.

Good luck.

Jim

Greetings,

Can nginx -- running on one server -- deliver 1000 requests
per second without "bogging down" and pushing more and more
requests into a queue?

Here's my reason for asking:

I'm designing a live auction website that needs to respond
to 500-1000 requests per second for about an hour.  Each
request will post only 20 bytes of data so the volume being
posted is low.  Nevertheless the HTTP headers still need to
be parsed and they will have far more volume than the
actual post data -- so it seems I should do everything I
can to reduce the HTTP header overhead.  This will
substantially reduce the load and speed up nginx's response
times, correct?

I'm wondering if nginx has the ability to use "Web Sockets"
technology to eliminate all but the first HTTP header, and
maintain a connection with the browser so data can be
passed back and forth faster?

http://www.w3.org/html/wg/html5/#network

If this is not possible, can you tell me the best way to
reduce the HTTP header overhead so I can make sure that
each of those 1000 requests per second are responded to as
fast as they come in?  Or am I concerned about something
that's a non-issue, perhaps because nginx is so blazing
fast that it can handle this kind of load without breaking
a sweat?

The worst problem I can imagine is that during one of these
live auctions the server will begin to respond slowly and
push requests into a queue.  If this happens, bidders will
not receive timely updates from the server and then the
whole service loses credibility.

If Web Sockets is not an option, perhaps using Javascript in
the visitor's browsers to send requests via XMLHttpRequest
is the next-best option for reducing overhead?

http://axod.blogspot.com/

Thanks for any insights you can provide to help me decide
whether or not nginx might be appropriate for my needs.

Best,
Owkaye

owkaye wrote:
> request will post only 20 bytes of data so the volume being 
> passed back and forth faster?
> 
> http://axod.blogspot.com/
> 
> Thanks for any insights you can provide to help me decide 
> whether or not nginx might be appropriate for my needs. 
> 
> Best,
> Owkaye
> 

My experience is that nginx will not pose limit in this case.
On my desktop (Pentium 4) nginx serves 3000-5000 req/s with static
content (10K). What might pose limits is your application code and
database utilization pattern.

luben

Many thanks to you two. I ended up installing the start-stop-daemon, 
since I already had a functional nginx.

Now I'm a little worried about having to convince my company's customers 
to let me install all these third-party applications and scripts on 
their production servers. Indeed, my company sells Oracle Forms 6i and 
Oracle database-based applications to large corporations and my job was 
to identify the next technology we can use to step up to Web 2.0-ish 
applications. Having chosen Flex front-end and Ruby-on-Rails back-end 
against an existing Oracle database, I realize lots of IT people will be 
weary of having Ruby, numerous gems including Rails, Oracle adapter, 
Mongrels, nginx, start-stop-daemon, Monit installed on their servers...

Well, I'm still experimenting, but I'll have to come up with a 
technically and politically correct setup sometime soon!

Cheers,

Chris.

luben karavelov wrote:
>> post only 20 bytes of data so the volume being posted is low.  
>> http://www.w3.org/html/wg/html5/#network
>> into a queue.  If this happens, bidders will not receive timely 
>> updates from the server and then the whole service loses credibility.
>>
>> If Web Sockets is not an option, perhaps using Javascript in the 
>> visitor's browsers to send requests via XMLHttpRequest is the 
>> next-best option for reducing overhead?
>>
I suspect that nginx would be able to handle this without at problem,
although I would suggest that the best way to find out is to do some
load testing. How are the responses built? If that involves database
lookups, for example, it's more likely that your bottleneck will be
there. Incidentally, I don't think XMLHttpRequest will help you - from
the server's point of view, it's just another request, albeit one
serving a smaller amount of data.

>> Can nginx -- running on one server -- deliver 1000
>> requests per second without "bogging down" and 
>> pushing more and more requests into a queue?
> 
> I suspect that nginx would be able to handle this without
> at problem, although I would suggest that the best way to
> find out is to do some load testing. 

I will definitely do this after I buy a server.  I'm still
in the planning stage right now.


> How are the responses built? If that involves database
> lookups, for example, it's more likely that your
> bottleneck will be there.   

The responses will require a comparison of a posted value to
another value stored in a specific location in memory.
It's not a lookup or search in a databse but it required a
separate app to do the comparison so it's not as simple as
immediately serving a cached static web page.


> Incidentally, I don't think XMLHttpRequest will 
> help you - from the server's point of view, it's just
> another request, albeit one serving a smaller amount of
> data.

Thanks for this info.  I know it will result in less traffic
but if you're saying


Best,
Owkaye

owkaye wrote:
> The responses will require a comparison of a posted value to 
> another value stored in a specific location in memory.  
> It's not a lookup or search in a databse but it required a 
> separate app to do the comparison so it's not as simple as 
> immediately serving a cached static web page.
>   
How large are the responses? That's something else to consider, if
you're returning large amounts of data, as the bottleneck might then
move to the network.

Even though you haven't got your server yet, I recommend installing
nginx on your development machine and playing with it with a bit of load
testing. I think you'll be pleasantly surprised. What amazes me is how
tiny its demands on the CPU and memory are, even under heavy load.

Hi,

That's a benchmark I did some time ago on my PIII 500:
http://www.ruby-forum.com/topic/145783