Date: Sat, 15 Nov 2003 15:58:07 -0800 From: Jos Backus <jos@catnook.com> To: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files Message-ID: <20031115235829.GB98569@lizzy.catnook.com> In-Reply-To: <3FB6A907.1CC86D3E@mindspring.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> <3FB6A907.1CC86D3E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 15, 2003 at 02:30:31PM -0800, Terry Lambert wrote:
> 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-).
Heh. Let's not go there. There are similar tools out there with friendly
licenses; see /usr/ports/sysutils/mktool for an example.
> Practically, init does what you want: monitors and restarts things
> that die.
I want more :-) I also want a uniform, cross-platform way to control daemons
on UNIX. Hell, even Windows has one.
> 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-).
That's true, but it's also irrelevant :-) This is not just about automatically
restarting daemons when they die. For example, such a mechanism lets me give
members of the lmadmin group control over lmgrd, even though it runs as a
different user.
> > 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.
So you mean adding the complexity/fragility of managing/using pidfiles, even
though we can just use the natural parent/child relationship is a good thing?
Doesn't make sense to me but I must be really dumb :-)
Let's drop the argument and agree to disagree (I didn't really expect many
people to agree with me anyways). After all, _I_'m not the one having the
pidfile problem.
> > 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.
It depends. Maybe it only cores under certain circumstances.
> > > 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".
Again, I disagree. This interface is just poorly designed. I guess you don't
like SOAP, XML/RPC, etc. either. But it's really off-topic so this is all I'm
going to say about this. We can always discuss this over lunch sometime :-)
> 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.
You are dragging all kinds of other issues into this discussion. How can a
pidfile restart a service, provided you agree that this sometimes useful
behavior?
Please, rather than trying to bring about world peace, let's agree to disagree
because this discussion is not going anywhere (sound familiar?). Apparently
you oppose the incremental improvement (imo) that process monitors bring.
Fine.
> 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.
Hm, what problems do pidfiles solve that a process monitor doesn't?
--
Jos Backus _/ _/_/_/ Sunnyvale, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/ _/
jos at catnook.com _/_/ _/_/_/ require 'std/disclaimer'
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031115235829.GB98569>