Conference pamsrc::decmessageq

2774.0. "killed app poisons queue and qe (v3.2A/Solaris)?" by WHOS01::ELKIND (Steve Elkind, Digital SI @WHO) Tue Feb 18 1997 01:56

    One of my users is having a problem using DmQ for HP-UX v 3.2A (no
    ECO).  If he kills (-15) a process attached to a single-reader
    permanent queue, the queue can no longer be attached to, and the QE can
    no longer be stopped with dmqmonc.

    This is happening on a Solaris (2.5?) system.  I have asked him to try
    to repeat this behavior on an HP-UX system (where I've never seen the
    behavior), and also to set PAMS_TRACE and DMQ_IPI_TRACE variables on
    the application process.  When I get back to the site on Wednesday, I
    will install the ECO and see if it makes a difference, although judging
    by the readme file onthe dowload page it should not.  In the meantime
    - does this sound familiar to anyone?

    > I am having a problem with DMQ32A.  If a server attaches to a permanent
    > queue (also permanent active), and the server process is killed, the 
    > queue is not released.  When I try to restart the server, I get a
    > [attach] error, with error code -106 (PAMS__DECLARED).
    > 
    > Even worse, when I try to bring down DmQ to clear the problem, using
    > dmqmonc, the dmqqe just doesn't die, even if I shut down bus and group.
    > If I manually kill dmqqe, I still have some ipc resource hanging, so
    > I have to clear the resource manually.
    > 
    > I know my server didn't do [detach] when killed.  But, shouldn't
    > DmQ still take care of this situation any way?  This didn't happen with 
    > DMQ30B or earlier.
    > 
    > Could you take a look at this and report it as a DmQ problem, if it is?
    > If it's some error on my side, please let me know what I did wrong.

    
    not reproducible here on any platform.
    
    one thing to check is if their server process is still out there
    after the SIGTERM.  for instance,  if  the  process  has  mostly
    exited,  but the process is a child of anoher process  that  has
    not handled the SIGCHLD signal,  then the  process  may  be  out
    there as a zombie process.  if the process is still out there in
    any form,  then we leave it alone (don't detach it's queues).
    
    _sjz.

    Thanks, zach, I'll look into it.  This problem is on the same host on
    which we are having the dmqgcp signal 11 problems, naturally.

    
    well,  if your gcp is dead then there is no one to clean
    up after processes that abnormally exit.
    
    _sjz.

    sorry to confuse you.  The gcp problem was another user, bus, and
    group from this problem - not related at all other than being on the
    same machine.

    
    next timet his happens,  please check the state of your  dmqgcp
    process.  you can use ps, and/or top if you have it.  what i am
    looking for is CPU consumption.
    
    _sjz.