> I've already come up with an interesting plan to template out the entire
> logging aspect. Default system-wide logging methods with your choice of
> back-ends and per-service manual overrides, here we come...
That sounds perfectly reasonable. It's what I describe as the logging chain:
http://skarnet.org/software/s6/s6-log.html#loggingchain
> I've noticed this in a round-about way but haven't take the time to ponder
> it. After reading your description, the problem has been clarified and I
> suspect my approach is probably not going to fit well. But I might have a
> temporary solution.
Yes, you can emulate service management with processes. But it's kludgy
and at the end of the day you'll have to maintain processes that do
nothing, just as a boolean flag. Processes are cheap, but not cheap
enough that it's ok to maintain a live process to store one bit of
information.
Believe me, we've been here before. You *can* use a process supervision
suite to watch everything that needs to be watched, but you're fitting
a square peg into a round hole and it's not going to be pretty.
> There is a reasonable assurance that the interface will remain
> up, granted, but there is no guarantee that it will *stay* up. If some
> other program brings it down, or an administrator accidentally brings it
> down, or even if the cable is unplugged, then the "passive" nature of this
> approach will not catch it, and the state of the interface is out of sync
> with the expectations of the framework.
Oh, yes, services need to be supervised, of course, and that is one of the
big flaws of System V. But not every service will fit nicely in your
"supervise this process" squares. Try it and see for yourself.
As for your iptables rules example: this is a textbook case of
one-time initialization mixed with service startup. When you install
a new set of rules, it's a change in machine state that happens only
once, and there's no change in process state - so is a given iptables
configuration a service ? Does it need to be supervised ? It doesn't
fit that modelization. My conclusion is that the modelization is
insufficient and I'm setting time aside to work on something clean.
> I think one-time setups can be accommodated by state tracking in the
> service directory itself. Something like ...
>
> do-setup()
> {
> setup stuff here
> if $error then
> return 1
> else
> touch ./setup
> return $?
> fi
> }
>
> [ ! -f ./setup ] && do-setup || exit 1
And where do you put that, in your run file ? Does that mean that
when you try and up the service, if the one-time setup fails, the
supervisor will try to run it again and again ? That's very
dangerous. If a one-time initialization fails, you usually want
to make loud noises on the screen or in the logs, and wait for
user input. If you can't do that, and you retry stuff instead,
then at least you should make sure never to re-execute commands that
have already succeeded. That implies heavy state tracking in your
one-time initialization.
It's a harder problem than it looks, really, and all the easy
way outs are hackish and will fail horribly when you least expect it.
--
Laurent
Received on Fri Oct 03 2014 - 03:29:32 UTC