X-no-Archive:yes
Yikes! * shudder *
OK, if something like this were to work, it would just about have to run as
manager.sys, which is a great way to discover that your script has this one
tiny little mistake, and you just killed the wrong pid. Oops. Now, we can
enjoy gratuitous system crashes and reboots, just like UNIX and NT.
The only other approach that I could see would be to have such scripting as
would get the user name and account of the job that "needs killing", then ps
for any pids that that id happens to be running. Is there any guarantee that
the user that runs a daemons runs little or nothing else? Might there be any
other jobs that run under the same user name as, say, sendmail or syslog?
Or, and this is scary, if they run under manager.sys, now we're creating
jobs that run under those ids... I can't think of any universal way to map
user name and account to a particular daemon, although someone more familiar
with the various daemons on MPE would certainly know more about this than I
do (which is asymptotic to zero).
I just don't get this. Why is it hard, if we start up inetd, httpd, nmbd,
smbd, sendmail, syslog, etc., in the start up job streams, to have
corresponding and simple shutdown jobs that do the right thing to issue the
POSIX kill for that daemon? For two of the four daemons we run (inetd, nmbd,
smbd, httpd), we have nice simple ways to kill the daemon, which makes the
job end gracefully, which our third party scheduler (NOBIX JobPak) is
perfectly happy to see as normal. It's only the abortjobs that it complains
about, and with the patch above, we should be able to eliminate those.
Ted, are you suggesting that an ABORTJOB UDC could look up, say,
jinetd,manager.sys, and find that the command to end it is to run inetd -k
or stream a job containing this? Or for homegrown apps, it might find that
someutil,job.app requires it to stream killutil,job.app? How would one
handle the security considerations for allowing this shutdown job to stream
whatever other job streams? And then, the lookup file would have to be
secured, so that a wily hacker could not add an interesting entry, to have
abortjob stream an arbitrary job (which the other security * ought * to be
able to prevent). Could something like this work with the patchwork of
third-party job managers, MasterOp, SEC / 3000, SAFE / 3000, Security
Monitor, nothing, and home grown hacks?
Greg Stigers
http://www.cgiusa.com
should I be nervous,
or just be glad that it's Friday so I can get some much needed rest?
-----Original Message-----
From: Ted Ashton [mailto:[log in to unmask]]
Sent: Friday, December 08, 2000 1:30 PM
To: [log in to unmask]
Subject: Re: improved abortjob (was PX2LXD4(A))
<snip>
I don't have time to write it now, but a UDC built on the same lines as
Jeff's
STREAM or Volume UDCs should be able to do what's needed. The different
aborting techniques would be put into a configuration file and if the
job was not represented in that file, it would be aborted by the normal
method.
HTH,
Ted
--
Ted Ashton ([log in to unmask]), Info Sys, Southern Adventist University
==========================================================
Common sense is the collection of prejudices acquired by age eighteen.
-- Einstein, Albert (1879-1955)
==========================================================
Deep thoughts to be found at http://www.southern.edu/~ashted
|
