51–60 of 68 posts
My favorite remains BSD style (rc.conf+rc.d/) init - which for some reason receives no mention here. Arch Linux used to have it too, but then inexplicably dumped it. http://www.freebsd.org/cgi/man.cgi?query=rc&sektion=...
"Process Supervision: Solved Problem" [0] is a great rundown too (from one of the Chef Opscode guys). His recommendation is to use runit (based on djb's daemontools). He recommends against using Bluepill, God, Foreman, supervisor and others. [0] http://jtimberman.housepub.org/blog/2012/12/29/process-super...
That's weird, because that's one of the things i like about Upstart. The ability to set pam limits and others in the same file. Upstart seems to support the same options Runit memory wise: stack, data, memlock ...
limit nofile 10000 10000
limit nproc 1024 1024
nice 3
chroot /var/roots/mychroot
Monit is another standard program, but I think these these things being compared are really not similar. Aren't upstart and systemd replacements for init.d runlevel scripts? While God & Monit make sure programs are running. I suppose there is overlap.
There's no clear delineation here. Upstart and Systemd are init.d replacements, both of which can make sure that programs are up and running, and incorporate some basic process monitoring. Runit is similar, and can replace init.d, but will happily run as just another process. God can't replace init.d, but it can easily handle the daemonize-and-keep-running functionality that's at the core of what we want from all thi…
Amazed to see so many simple responses in this thread given that the single-system paradigm is sort-of heading out of date now (manual Unix systems administration is arguably a dying horse). For any serious (ie. highly available) systems, a major option that should be under discussion is Pacemaker/Corosync. http://clusterlabs.org/ It's a pain to learn, easy to screw up, non-trivial to test exhaustively, but provides…
You still have to get, and keep, things running on boxes though. HA does not magically remove that need.
My favorite remains BSD style (rc.conf+rc.d/) init - which for some reason receives no mention here. Arch Linux used to have it too, but then inexplicably dumped it. http://www.freebsd.org/cgi/man.cgi?query=rc&sektion=...
Because having long bash scripts and every process implementing it's own daemonisation in weird and wonderful ways is redundant and inconsistent, and makes making something a daemon frustrating.
Has nothing to do with BSD style init? No part of the system should be either long or bash.
>it's own daemonisation in weird and wonderful ways is redundant and inconsistent
Calling daemon() is not that hard.
>and makes making something a daemon frustrating
That doesn't even make sense. People writing shitty software that should be a daemon but isn't makes that "frustrating".
Amazed to see so many simple responses in this thread given that the single-system paradigm is sort-of heading out of date now (manual Unix systems administration is arguably a dying horse). For any serious (ie. highly available) systems, a major option that should be under discussion is Pacemaker/Corosync. http://clusterlabs.org/ It's a pain to learn, easy to screw up, non-trivial to test exhaustively, but provides…
Do you know of some decent article, blog post, video, whatever that presents these products, what they are good for and a typical use case?