I Can Haz Init Script(devo.ps)
devo.ps
I Can Haz Init Script
http://devo.ps/blog/2013/06/19/I-can-haz-init-script.html
6 comments
Where I work we have a standardised script for controlling programs, and then the init script itself just looks like:
> 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:
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 <[email protected]>
+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.
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.
also it's more or less distro-agnostic. something initscripts usually are not.
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
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...
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?
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.
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.
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).
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.