On Wed, 15 Mar 2000, Alex Belits wrote:
> On Wed, 15 Mar 2000, James Sutherland wrote:
>
> > > Killing Oracle, or any other server that depends on some process being
> > > alive and keeping a valuable, complex, hard to recover data on disk and
> > > in memory, is in some cases not any better than just blowing up the box.
> >
> > It may not be any better, but it is certainly no worse - particularly if
> > we can SIGTERM the process first. In the case of the Oracle server, it
> > should be able to use this to sync the database, close connections and
> > exit gracefully.
>
> All that without being able to allocate more memory?
It's just closing files and sockets, flushing buffers etc. It should be
able to manage that without needing to increase memory usage at all.
> > Later, I would like to add priorities (e.g. try to kill x, y and z first,
> > then kill all the non-root processes (or the non-dbuser processes, or
> > whatever), then kill the rest.)
> >
> > No strategy will ever be perfect, but this system is pretty good, IMO.
>
> Why not just make some means to set strategy from userspace? Say, init
> runs xdm through a wrapper that gives it an ability to set the
> survivability policy for its children, and xdm runs local X server with
> high "proprity to survive". When user logs in, Xsession runs with this
> ability lost, so mortal user won't be able to mess with this policy unless
> he runs some restrictive setuid wrapper for his programs (not unlike
> sudo), so some "important" programs can run as user yet will not be killed
> too soon. inetd runs with high "priority to survive" yet the policy is
> set so its children won't inherit it unless they are run through a
> wrapper. And to make things even more flexible, sysadmin or some
> "smart" daemon then can use something similar to renice(8) that will be
> able to change this policy for already running processes.
That's what I suggested originally.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:29 EST