I Can Haz Init Script | Hacker News Reader

I Can Haz Init Script

devo.ps

14 pointshunvreus14 comments

Where I work we have a standardised script for controlling programs, and then the init script itself just looks like:

  #!/bin/sh
  # chkconfig: 2345 90 10
  # description: The magical daemon

  . /etc/init.d/daemon-functions

  init_daemon "$1" /usr/bin/magic-daemon

> Wanna have multiple memcache buckets, ... [snip]

On Gentoo, you would just create /etc/conf.d/memcached.xxx and then symlink /etc/init.d/memcached.xxx to /etc/init.d/memcached.

Relevant ChangeLog entry:

  14 Jan 2005; Lisa Seelye <lisa@gentoo.org>

  +metadata.xml, +files/1.1.12/conf, +files/1.1.12/init, +memcached-1.1.12_rc1.ebuild:

  Add 1.1.12-rc1 and retool the conf/init scripts to take advantage of the new
  -P (pidfile) option. The default behavior is to save the pidfile in
  /var/run/memcached/memcached-PORT.pid. This, it seems would make it easier
  for people to have multiple instances of memcached running (simply rename
  /etc/init.d/memcached to /etc/init.d/memcached.instance and the conf.d file
  accordingly.

Systemd helps a little because its service files are declarative and thus easier to understand and write; also stuff like detecting processes or managing commands are done in a consistent way.

also it's more or less distro-agnostic. something initscripts usually are not.

We use upstart instead (Ubuntu Server boxes), and I much prefer them over init scripts, which need a lot of boilerplate for the simpler of tasks. Implementation concerns aside, the UI is much better all around.

Advertising an empty repo is not very helpful. Sure, I could check back, but who's to say they'll ever be anything there?

http://sivers.org/zipit

All is pushed now, I only have 2 hands :)

Fair enough, sorry if over-harsh. I think we've all seen too many half-started projects.

> You have no other choice but to restart it. No big deal, really;

Losing a server to a rogue process for whatever reason used to be a big deal. Sometimes you even set resource limits...

Why not contribute better init scripts upstream?

I asked the same thing to my teammates; it seems to be the plan ultimately, but upstream contributions are not necessarily easy to get in, especially on big pieces of code.

I am the Debian (and by approxiate extension, Ubuntu) maintainer of the Redis package. Assuming its done correctly, multi-installation would be a great feature to have - please send a patch to the BTS.

I added similar functionality to Gunicorn (where multiple gunicorn workers per physical machine is a rather common requirement).

The redis init-script in the repo is only a sample I hacked as an example; to avoid an empty repo :) I've tested and it's working, though I'll perform some more checks tmr and will gladely commit it back.

Ultimately that is be the goal indeed.

At the same time all init script are not suitable upstream; keeping the balance between simplicity and features is a hard one. Not every use would require a 10 foot long scripts that cover some awkward features that is seen in 1% of the cases - yet having a repository of capable init scripts seems a good way to mitigate the issue.

Reply on news.ycombinator.com