From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 15 14:32:06 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 078D316A4CE for ; Sat, 15 Nov 2003 14:32:06 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id E823243FDD for ; Sat, 15 Nov 2003 14:32:04 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfj2j.dialup.mindspring.com ([165.247.204.83] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AL8wc-0003D7-00; Sat, 15 Nov 2003 14:31:07 -0800 Message-ID: <3FB6A907.1CC86D3E@mindspring.com> Date: Sat, 15 Nov 2003 14:30:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jos@catnook.com References: <3F9CF3F6.8307.ABC1250@localhost> <20031111071944.GA5778@lizzy.catnook.com> <3FB360BE.779DB42F@mindspring.com> <20031113165647.GA80504@lizzy.catnook.com> <3FB4A449.7452A382@mindspring.com> <20031114174607.GA42257@lizzy.catnook.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e92a567895908f402052d7278feef8242601a10902912494350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 22:32:06 -0000 Jos Backus wrote: > On Fri, Nov 14, 2003 at 01:45:45AM -0800, Terry Lambert wrote: > > OK. We already have one of those. We call it "init". 8-). > > Feature-wise init and svscan/supervise don't quite match; svscan has more > features, one of which being that it doesn't use a single control file which > if you screw it can render your system unusable. Even SysV init has more > (useful) features than ours. Also, init is kinda hard to use by non-root users > for that reason. People have been known to successfully replace init with > svscan, btw. The main feature svscan lacks for me is the right license. 8-). Practically, init does what you want: monitors and restarts things that die. This whole discussion, though, is pretty stupid, since the things you are worring about keeping running should be written to not die in the first place, and if they *are* dying, it's generally dumb to restart them thinking that they will magically not die again, since, having ben restarted, they are now among the blessed. 8-) 8-). > This is really off-topic. But sure, there are instances where this approach is > less than robust. So what? Using pidfiles doesn't solve this problem either. Not using PID files won't fix it either. So portraying PID files as being a bad way to solve this problem (which is what people were originally complaining about) is really dumb: PID files work very well for resolving the problem that they were intended to resolve. You just need to create them when you are first started, which is done by "root", unless you are SUID to some other UID, in which case it's done by that ID instead. After that, the same UID has priviledges on the file, and the problem is entirely solved. [ ... ] > Also, software can fail in ways unaccounted > for. But this is really off-topic. It can't fail that way if you account for it failing that way. 8-). But see the above: restarting sshd because it core dumps when you try to login using putty isn't going to magically make attempting to login via putty not core dump it. > > Anyway, FreeBSD has steadfastly disliked the concept of a registry, > > ever since Microsoft implemented it in Windows95; it's on of the > > biggest "NIH" items of all time. > > I think it would help if config files had a common structure and could be > queried for "interesting" service metadata like dependencies. See the Arusha > project for an example. This is totally bogus. Data interfaces are the same things that screw us over with "proc size mismatch" messages every time the proc structure changes. The only reasoanble interface is one that provides procedural accessor/mutator functions to abstract the format of the interned vs. the externed data, so that it then becomes *impossible* to get a "proc size mismatch". FreeBSD currently continues to have the "proc size mismatch" problem because it currently insists on continuing to use data interfaces. FreeBSD continues to use data interfaces in this are because it can not use procedural interfaces to operate against system dumps. FreeBSD can't use procedural interfaces to operate against system dumps because it does not take advantage of the ELF format to add an ELF section to the kernel image to contain the shared library for the procedural interface to use against the kernel (with an internal, but therefore hidden, data interface), so that there is never a discrepancy. > Anyway, we were talking about the use of pidfiles versus using a process > monitor. I'm simply claiming that using a process monitor is far superior. And I'm simply claiming that they solve different problems, and that complaining about not having a solution to the problem that a process monitor solves (to wit: restartting buggy programs that should not be crashing in the first place) is OK, but complaining that PID files don't solve the same problem is incredibly bogus. They solve different problems, and you can't simply replace PID files with process monitors, and continue to solve the problems that PID files solve that process monitors don't solve. -- Terry