-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Rich Smrcina wrote: |> |> Actually, DB2's use of /etc/inittab is for a good reason: it wants to |> respawn a process if it ever dies, and init will do that properly. The |> inittab really needs a form of "directory include" capability so that |> packages can drop snippets of inittab instructions into separate files. |> But I don't think anyone wants to change how init works. |> | | Your explanation of why they use inittab is the first I've heard of why | they do it that way. A little blurb in the doc when I was hunting for | it back in the day would have been helpful. :) |
Hello, list. 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. 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. Infact, it was just today that I had a db2fm process continuously eat up 100% of cpu (for more than an hour) on a 31-bit DB2 Connect user, cornering two other development-related users by its excessive cpu utilization. Incidentally, the service needed to be online ASAP, because there was some introductory schooling going on, I was at a very interesting lecture at that time. Guess who drew the shorter straw. I dare asserting that given a *proper* way to have db2fmcd run on that system would've prevented that from happening, as it would've had been running with a significantly decreased priority and ulimit on CPU time, and the processes it spawned itself would've had inherited that from it. Yes, I know about share settings, but they're beside the point here. DB2 Connect was working flawlessly, and handling runaway processes in Linux is the first instance of intervention; I'd rather handle the problem at a level where I can pinpoint the exact cause, rather than penalising the entire system because one tiny part of it went berserk. All this rambling is, of course, something I do because the service agreement is preventing me from poking around such indolent solutions. I could fix that inittab thing in less than five minutes by starting up db2fmcd from an init script and set up a cron job that restarted it if it ever died, but I'd have certainly lost my cherished privilege of being able to complain about it not working the way it should. :) Kind regards, - -- ~ Grega Bremec ~ gregab at p0f dot net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDfOY2fu4IwuB3+XoRAwvbAJ9hOOgz1aQzwltxh/GtCcpXEYDOcACdHHg+ LVhmgvtPTOeR4lJV9Zix78o= =saIj -----END PGP SIGNATURE----- ---------------------------------------------------------------------- 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
