Grega Bremec writes:
>I feel compelled to comment on this a little bit. Adding all sorts of
>things to /etc/inittab is considered to be pretty much intrusive and
>unwise in the Unix world, and as far as I'm concerned, it is actually by
>far the worst thing to just to keep a process around. There are much
>better mechanisms to achieve that.
I agree! You've written a great description of what init is for, and I
really wish the DB2 folks had learned this as well as you have. While I
usuall excise long posts from my replies, I'm including your exposition
here so that I can say this: If you didn't read it before, read Grega's
comments on the init process now! He describes the purpose of things,
something that is seldom documented anywhere in UN*X-land.
>Namely - let me break this in two parts, so I can concentrate on each of
>the aspects a bit more - there is the issue of init(8), and there is the
>issue of why and how you want to respawn dead processes.
>
>Firstly, the tradition of Unix tools is they are simple, they perform at
>most a couple of tasks, and they do it well. init(8) is no exception to
>this rule. It takes care of several different profiles of starting up a
>system, runlevels (in System V), and it initiates the more intelligent
>means of setting those profiles up (invoking scripts that set up the
>environment and start up services). It is not meant for, or at least it
>has not proven to be, a job control tool, or infact anything else beyond
>a mere tool to do the basic one-time dispatching of the runlevel
>scripts, and on systems with at least one console attached full-time, a
>tool that will keep that console (or those consoles) occupied by a tty
>allocation program. In the even that one of the tasks it was assigned
>should fail, it will either pretend nothing ever happened, or blindly
>restart it a number of times, before stalling for a number of minutes
>(usually five) and repeating it all over again. There are far, far
>better tools than init(8) at an admin's disposal if they want to keep a
>process hanging around. Various watchdogs come to mind, and even cron(8)
>is far from being useless here.
>
>Secondly, and this is the more icky issue here, tools that one
>dispatches on a Unix system, will usually require at least some amount
>of attention from a person who knows what the system is being used for
>before being left to run unattended, so they can be spawned in an
>environment that is *friendly* to the rest of the system, such as one
>where ulimits and priorities have been sorted out. Moreover, if the
>processes really need to be kept alive, one will most probably care
>about their exit status, so they can do something useful to prevent the
>death of a daemon from taking place again. And even causing the death of
>a process on purpose, should it ever become necessary. init(8) is, plain
>and simple, utterly incapable of doing any of the aforementioned.
Grega then goes on to describe his woes with db2fmcd, which is exactly the
same behavior I've had it do to me, with no apparent cause and at very
random and unfortunate times. There's actually a very simple solution,
which I wish the DB2 team would consider, because it is the UN*X way of
doing it. Instead of starting it from init, start db2fmcd from the DB2
rc-script, along with the other admin tools. When db2fmcd starts up, it
should immediately spawn off a child process that does all the work. The
parent should do nothing but wait around for its child to die, and can then
loop to start up another one in its place. The parent process is very
robust because it only executes a very tiny bit of code. That's the UN*X
way of implementing a daemon that keeps itself alive.
Had they just done that simple thing, we'd all be happy with it, and their
installer would have been easier to write, and all kinds of goodness
follows.
- MacK.
-----
Edmund R. MacKenty
Software Architect
Rocket Software, Inc.
Newton, MA USA
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
