On Wed, 15 Mar 2000, James Sutherland wrote:
> > > 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.
I am not sure about that -- Oracle has rather complex ideas about
transactions, data consistency and transaction logs. Other
"mission-critical" applications may be even more finicky about the state
of the system when their shutdown procedures are running.
> > > 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.
And what is wrog with that? As I understand it, it shouldn't be hard to
implement in kernel, and arguments about particular policies can be left
to userspace developers.
-- Alex- 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 : Thu Mar 23 2000 - 21:00:18 EST