Nathaniel S. H. Brown wrote:
After reading this how-to,
You will find that by running the script/server and spinner/spawner
instances that it runs a single instance for that process.
I didn’t say anything about spinner and spawner. In fact, the stuff I’ve
seems to indicate that spinner/spawner are meant to be used with
deployments. I was talking about the reaper command for restarting the
listeners that control your app. Lighttpd is really just a HTTP reverse
for the application, if it’s run by FastCGI/SCGI.
My server runs many domains, and requires each to have their own instance of
the lighttpd being able to be managed without disturbing the next.
No problem. That’s not only easy to do, it’s one of the preferred ways
Lighttpd should be run, based on the stuff I’ve read. (I don’t claim to
The lighttpd.sh script that was included with the lighttpd 1.3.7 package when
ran, starts the instance itself, but when I ran stop, it would kill all
processes matching the /usr/local/bin/lighttpd binary. This package solves
that by specifically addressing the PID file associated to the lighttpd
instance for that configuration file.
My question is why are you starting and stopping the specific Lighttpd
when there’s a better way to restart/reload your Rails application? Are
fact, making new changes to the lighttpd.conf file each time you start
Lighttpd? If not, then I don’t understand why you are bouncing that
In addition, the script that I have created can be placed in the
/etc/init.d/ or rc.d directory and will be ran on boot time of the server,
or manually managed by running the (start|stop|restart|reload|status)
options on the script.
Having startups automatically happen is a good thing. But all you really
something that calls Lighttpd with the specific .conf file for your
app/domain/virtual host. Right? Am I missing something?
David G. had mentioned on his blog about using the @restart flag within
the cron entry to manage the lighttpd instance. This will work well for
starting the lighttpd server on reboot. But what happens if someone decides
to killall -9 all the /usr/bin/local/lighttpd processes by accident?
If that last statement is indicative of what can happen on the
that hosts your Rails apps, I’m really sorry to hear that. I guess,
need to do to try and operate under those potential conditions is
start >/dev/null 2>&1
Like I said. If there’s a possibility that someone with root access on
server would “accidentally” kill -9 just the Lighttpd processes,
need to do to keep them running is fine by me. I would be looking for
server admin, or a new hosting service, rather than trying to deal with
level of potential accident.
In addition to this bash script, I have just completed a full
lighttpd-package template which I use to deploy my lighttpd installs on my
system. And have made it available at http://nshb.net/lighttpd-package.html
Sounds good. I will most likely take a look, as I like to learn from
more experience than me in the systems that run my
However, I’ve been running Lighttpd on my OS X Tiger server and I’ve
never had a
case where the Lighttpd process was accidentally killed (at least, not a
that didn’t coincide with a building/campus wide power outage that
than our UPS’s.
For those not in the extreme situation as Nathaniel, please quit mucking
your Lighttpd processes if you aren’t making changes to the associated
that you need to enable. Use reaper to reload your Rails app code and
page caches. Based on what I’ve read and how I’ve seen it used, that’s
reaper was built for…
Brian V. Hughes
Associate Director for Web Operations (aka. Webmaster)
Computing Technical Services