Date: Tue, 17 Jan 2012 13:47:21 -0800 From: Jos Backus <jos@catnook.com> To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= <des@des.no> Cc: Doug Barton <dougb@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? Message-ID: <CAETOPp1MQrh1XvMTaUkxnjDOZvHf1OkAYS2HaPykPih2vJ_udw@mail.gmail.com> In-Reply-To: <86mx9msog3.fsf@ds4.des.no> References: <CAETOPp2Wcww1_fPonru0c6XoX%2BAV_HWoGZKiEMvmY50a5%2ByxRQ@mail.gmail.com> <4F14E291.5090803@FreeBSD.org> <CAETOPp1z0TJecz8kjDvf7trEOS5eogrcqEtDveUYzN=J-SvDNQ@mail.gmail.com> <86mx9msog3.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
2012/1/17 Dag-Erling Sm=F8rgrav <des@des.no> > Jos Backus <jos@catnook.com> writes: > > If FreeBSD had a solid solution out of the box, all this pidfile hacker= y > in > > the base system wouldn't be necessary. I always thought FreeBSD was abo= ut > > good engineering. Perpetuating the pidfile mess in the base is not a si= gn > > of good engineering. > > Software written by DJB hardly qualifies as "good engineering". PID > files are well-known and well-tested, we have a solid implementation > with a simple API (pidfile(3)), and a lot of our infrastructure depends > on them (/etc/rc, newsyslog etc.) > Just because lots of people have been doing something for a long time that is widely supported, doesn't mean it's the right thing to do. As I said before, pidfiles export partial information that is already available in the process table, without requiring extra cached file system copies that need to be created/removed, have their permissions managed carefully and can get stale. daemontools is one implementation that solves the same problem without using pidfiles. It also gives you the option of a well-defined startup environment for each service (not tied to the environment of the caller) and the ability to add fine-grained control over a service (by manipulating the permissions on the control socket, so select non-root users can start root services if desired). It also comes with built-in logging (multilog). Additionally, using the finish script functionality, policies around crashes can be instituted (e.g. down the service and send an alert if it crashes more than N times within M minutes). These are just some of the features that I have used in the past to run services on hundreds of machines in multiple data centers. daemontools is surprisingly flexible, and it doesn't require complex configuration commands or configuration files - a boon when used in combination with tools like Puppet. That said, I don't care what we pick as long as we pick something that can do all the above. Jos > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > --=20 Jos Backus jos at catnook.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAETOPp1MQrh1XvMTaUkxnjDOZvHf1OkAYS2HaPykPih2vJ_udw>