Conference noted::hackers_v1

    There's a bit in the STS longword of the PCB, PCB$V_NODELET, that does
    what you want. When this bit is set, $DELPRC will not delete the
    process. NETACP and processes like that that do not want to be deleted
    set this bit. The gotcha is that it isn't honored in versions of VMS
    before X3KR. This is V5 FT2, so you're going to have to wait. 

    	Jon

    
    Check the tools catalog for a "utility" called BUSY. It will "protect
    your process" from spirit, and has a couple of other nice features
    to boot.
    
    						Peter
    
    
    

>    	A quick question :  Is there a way that I can spawn a process
>    that cannot be killed by the system process killer called
>    SPIRIT. I have system priv's so privilage is no problem.

	You could spawn off a main process then suspend the parent
	and that should confuse $GETJPI. 
    
	You could write a routine that cancel wakeups to the 
	spirit process and help your fellow users. 

	and...

	You could write a routine to strip privs of the 
	spirit process and let it flounder...

	Finally, for completeness, since the only way to delete a 
	process is to queue an AST to it, which takes place at IPL 2
	then the only guaranteed way of not being deleted is to raise
	IPL to 2 or greater. This is not recommended. 	

    	$DELPRC still runs kernel mode exit handlers, I think, so you
    could set up one that just continues or restarts your image.

    I thought there was a macro file that SPIRIT reviewed containing
    UICs of processes that shouldn't be deleted (wouldn't want to delete
    NETACP or EVL now would you).  Wouldn't it be easy enough to add
    the UIC and recompile/start it?
    
-Andy    

    Re .0:
    
    If you have CMKRNL privilege then you CAN absolutely protect yourself
    against all $DELPRC attempts to kill you (including SPIRIT).
    
    Just set the DELPEN bit in your process header.  The side effects
    are interesting but if definitely works.
    
    
    --  Barry

Anyone have any suggestions on how to kill an unkillable process?  A group of
us are using a VAXstation where the UIS often hangs, as do any processes using
the windowing.  We have a deadline that prevents us from experimenting with
seeing if there's any hardware or software problems, and the only way to fix
this is rebooting the system and it then works fine (for a while) Trying to
kill the UIS processes don't make them go away, they hang there (with DELPEN
set).  I just wanted to see if just blowing away the 2 UIS processes and
restarting UIS would help, but they refuse to die.  Any suggestions on KILLING
any process, guaranteed?

-Mike

    Re .7:
    
    Well its a complicated situation.  First of all, why is the DELPEN
    set?  This normally gets set by the $DELPRC system service, but
    it is usually set BEFORE the deletion AST is queued.  If you have
    already tried to stop it, then this is why DELPEN is set.  Its just
    trying to tell you that it only needs to delete this process once,
    and that is in progress.
    
    On the other hand, the process may have set it itself as a prelude
    to running it self down.  In both of these cases you need to determine
    why it is hanging around before you can determine if it is safe
    to delete it.  VMS has already decide NOT to delete it because it
    believes that it is not safe to do so.  If you are going to do it,
    you have to know more about it than VMS does.

    If the DELPEN flag has been set just as the result of a hack like
    the one I suggested then, it is probably safe to delete it.  To
    do so write a kernel mode routine to go to that processes PCB and
    reset the DELPEN bit.  Now you should be able to stop it normally.
    
    If however VMS has set that bit then proceed with caution (if you
    mess up, bugchecks await you).  First of all determine what state
    it is in.  Show System can determine this for you (Show Process
    just claims that it doesn't exist).  If it is in an Mwait, then
    the best option is to determine what it is Mwait-ing for and see
    to it that it gets it.  IE, if its waiting for paged pool then delete
    another process to free some up (or something), if its waiting on
    a mailbox IO, then tweak the mailbox.  Once it recieves the resource
    that it needs, then it will be eligible for normal deletion.
    
    If it undeletable because it is executing a kernel-mode AST (ie.
    servicing some VMS BLKAST for that process), again the best way
    to handle it is to figure out what AST routine it is, what it is
    waiting on, and then deliver that thing to it (ie. make the lock
    available to it in this example).
    
    The last case that I can think of is that it is looping at IPL > 2.
    Again figure out what code is being executed, figure out why that
    code is waiting, then correct that.
    

    A final possibility is that the $DELPRC system service just screwed
    up, and left it in a half-baked state for no good reason (a bug).
    This you would have to take up with the VMS folks.

    
    --  Barry

>    are using a VAXstation where the UIS often hangs, as do any processes
>	using the windowing.  

    This happened to me a lot as well. It became a lot better after
    going to VMS V4.6 & VWS 3.2. It went away after upping PAGDYN
    from what I thought was a lot (3MB) to what I think is very much
    indeed: 5MB of which I am currently using 3.1 MB with some 6
    processes over and beyond the normal system stuff.
    
    Ah for those good old days (and nights) of RSX-11M V3.2 with
    it's 8KB or so of POOL...
    
    Hein.

re .8:

The UIS processes seems to be executing an AST and are in LEF when they hang.
They normally show up as HIB. Since they're in an AST, I believe this is why
they don't die immediately.  The processes whose "terminals" are WTAx: go into
RWAST when you try to kill them when UIS is hung. I know that there's a chance
of bugchecks, but since we reboot the system anyway, it's no big deal (as long
as the disks don't get lunched).  Besides, this is HACKERS, and I want to hack!
I don't know all that much about VMS yet (but I used to be deadly with CDC
machines running NOS).

re .9:  Has UIS hung since going to VMS 4.6 and VWS 3.2?  If not, maybe are
problems will be gone when we upgrade.  We have VMS 4.5 and VWS is 3.1 or 3.2
(don't remember, pretty sure it's 3.1)

-Mike

RE: .10

I know diddly-squat about UIS and VWS, but if they are going in RWAST, they
are waiting for a resource to become available.  For example, if these 
components communicate with mailboxes, a writer to a mailbox will go into 
this state if the mailbox fills up (because the reader died or went into a 
loop).

A good way to get around the hang so that you don't have to reboot is to
run all of the process with the /NORESOURCE_WAIT switch, provided these
guys are run via the RUN/DET or RUN/UIC= method.  This will force an
error and the affected process will die instaed of continuing to wait
for something which may never come.

BUGCHECK.MEM has a lot of good info about how to find out what resource
a process is waiting for.  Unfortunately, it is not always possible to satisfy
the request, so you end up rebooting anyway.

The guys in RWAST are waiting for the UIS routines (which are hung) to do
something. They aren't the problem, the hung UIS routines are.  I'm just
looking for a hack to kill/restart UIS.

-Mike

RE: .0

If you've got the privs, I would solve the problem by deleting the process
running SPIRIT.

--PSW

    	I think he wants the only side effect of his actions to be
    that his process does not get logged out by SPIRIT.  No?
    
    -mike z

    See also note 519.* for another discussion of this.
    I find that running NOTES keeps most process killers at bay.
    	-Rick

    re .9: 
    
    Five megs is *a lot* of paged pool. I've used three for years with no
    ill effect (I have almost 900K free right now, too). I'd reccommend
    that you look at some of the tuning notes in the VWS conference for
    help tuning your system. 
    
    There is an easy way to reload UIS and free up those hung processes.
    Type these two lines of DCL:
    
    $def opc$reboot y
    $mc opccrash
    
    	Jon

        Well, as one of the people who modified Spirit I must tell you
the following story: I am amazed that non of the 16 answers contains that
feature. Spirit does not touch processes which have an active subprocess
created. Believe it or not. Sooo if you spawn a subsprocess none of you
processes are touched.

        Julian.

    Re .17:
    
    Why wouldn't Spirit kill a subprocess that does not have its own
    subprocess?
    
    
    				-- edp 

        Ok, if I understood this correct...

        Spirit goes thru the process list using $GetJPI. For each process
        Spirit checks if the subprocess count is zero, if it is not zero
        the process is skipped. If the process in question is a subprocess
        than it is skipped anyway.

        Julian.

    I just watched it on showtime.......again!