[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: How Unix manages processes in userland
On 2013-12-06 kre%munnari.OZ.AU@localhost wrote:
There's no need to impose anything in particular on anyone, just create
I started out disagreeing, but I think I somewhat changed my mind before
hitting send :/. What you say makes sense to me in that modularity
encourages more well defined interactions between simpler parts (dealing
with packages, etc.), which makes it easier to figure out what is going on
at each step of the way. I do think it is super important to have
something that works well in the base system.
I've had two basic problems with most init systems: the most common is
just having no idea WTF is going on or how to find out, and the much less
common one is wanting to replace as little as possible if the system just
doesn't do what I want. Being able to replace the whole system doesn't
help if there is no other system that does all of what I want and at least
means I need to learn how some other system works.
NetBSD seems to do very well on both of these basic issues and I think
it is a major reason to use NetBSD. I've had the misfortune of being
stuck mostly running various versions of Linux over the past year or two
and NetBSD's rc.d is one of the things I miss most (sh, mtree, vis, and
build.sh are other things that come to mind easily). My current Linux
system uses systemd and netctl and when something fails it is either
silent or tells me to check two different log files which have a bunch of
lines but usually nothing more helpful than "... status: FAILED".
daemontools is one that uses the "don't fork" model with per-service
monitors. I think it has some good ideas and is much simpler than the
others I've seen. I don't think it deals with dependencies, though, which
is a major issue. I think it would be great if something like that was
merged nicely with rc.d and used by default.
daemontools has a fghack program to try to work around services that
fork by opening some pipes before starting the service and exiting when
they all get closed.
djb also wrote a single service inetd-like program (ucspi-tcp).
OTOH, I'm personally not that fond of having an extra monitoring process
for every service and I also think it makes sense for init to do generic
"is it running" monitoring. I don't think it makes that much difference
either way, though, and I don't think init should try to do anything more
complex then checking if something is running and restarting it if not.
Another thing that I think should be part of a service monitoring system
is dbus type "message bus" functionality and ability to deal with on
demand services. Unfortunately, dbus itself has a quite unfriendly UI.
IMO, the basic Unix/BSD security model, while useful for servers, does
not cover how users actually interact with a personal computer. Fixing
that involves defining and limiting what any individual application and
application instances can do (in a way relevent to the user, such as this
app can only modify files in this particular directory or must get
approval for files to be written through a notification mechanism or
something like that). Which probably involves moving more things into a
service realm with processing capability but not the direct ability to do
things with side effects. With fewer and simpler programs doing things
with side effects (and the OS enforcing this), it would be eaiser to
visualize and control what those side effects are.
Main Index |
Thread Index |