non-root process and PID files

[Terry Lambert]

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