you asked for my feedback, so here it is:
I think the general idea of creating such a standardized "service
template" is good, and we probably would need to have something
similar for other languages we use as well. I have taken a look at the
code and I think the general direction you're taking (conventions,
declarative config, etc) are all very good and sensible ideas. This
kind of scaffolding/standardization is what I asked for at the dev
summit, so it's all welcome - we'd be able to add features/plugins to
existing services just by updating the service-runner.
The only critique I feel is needed here is to the whole idea of having
a node process acting as a supervisor. Can we really resolve what is
there are better ways to spin up node processes and deliver HTTP
requests to them - I think using this supervisor is perfectly correct
and good in a dev environment or when prototyping your service, but
I'd like to have the option of thinking at alternatives when we run it
in production. So, is there a way to run a single worker without
forking out? If not, I guess it would be easy to add this option ('run
as a single worker on port XXX') to the service-runner.
Thanks a lot for working on this!
P.S. Why can't I find this project on
or gerrit, and
just on a closed-source, proprietary platfrom like github?
On Tue, Feb 24, 2015 at 7:02 AM, Gabriel Wicke <gwicke(a)wikimedia.org> wrote:
On Mon, Feb 23, 2015 at 4:46 PM, S Page <spage(a)wikimedia.org> wrote:
I'm surprised there isn't something like
this already in nodejs that you
get "for free"
the closest in terms of feature set that I'm aware of is
. It has slightly more features
than service-runner even, and we would likely have used it a while ago if
there wasn't this catch about it being commercial software that also
requires a subscription.
when you use forever to run a node command.
consider forever-service  ? It sounds similar:
I knew about forever, but not forever-service. Thanks for the link!
Both are solving a different problem: forever basically tries to be a
replacement for daemon managers like start-stop-agent, while
forever-service hooks it up with the actual init system. Both could
potentially come in handy as part of a distribution solution on less common
platforms, especially where there isn't a good init system. On Linux we now
have a very modern init system with systemd though, and I think just using
it makes a lot of sense.
While forever (like an init system or start-stop-daemon) is all about
managing a subprocess, system-runner actually becomes part of the node
service process. It parallelizes web services by managing workers all
listening on the same socket, sets up non-blocking remote logging and
automatically collects heap metrics in each worker it spawns. It is
complementary to init systems or forever in many ways. For example, forever
or init systems typically send a SIGTERM to ask for a graceful restart,
while service-runner has a handler for SIGTERM that triggers the actual
graceful restart by instructing its workers to stop accepting new requests
& exiting after ongoing requests have finished.
It's _great_ that
mentions similar packages, I made a pull request to add forever-service to
the README though I didn't compare its features.
Thank you! I merged & tweaked it a little in a follow-up.
For small (third party) installs with limited
memory, we also added the
capability to cleanly run multiple services in a
Yay. Should MediaWiki-Vagrant use this, or does it only benefit when you're
running more -oids than just Parsoid?
The memory saving comes from only starting one process (which parsoid
already supports). Service-runner additionally lets us run multiple
services in a single process, which can save memory over having one process
per service. You lose isolation and parallelism of course, but that's an
okay price to pay if you are set on running all those services in 100mb of
RAM. Also, Parsoid does not use service-runner yet. First commit was only
I'm so excitoid
Ha! And I thought we had just freed ourselves from the *oids ;)
Wikitech-l mailing list