Conference azur::mcc

5742.0. "DECterm/MAP dies on remote system" by GRANPA::AMEISHEID () Tue Nov 16 1993 09:26

    I am running DECmcc V1.3 on ULTRIX V4.3 workstation at a remote site,
    displaying to my local workstation, also running ULTRIX V.3.  When I
    start the iconic map to display locally, the map window dies (and all
    windows that had been opened when it started) but the process id (from
    ps ax |grep mcc) for the map continues to get time on the remote
    system.  mcc_kill ALL does not kill the map but hangs when it gets to
    the particular pid for the map - kill -9 map_pid# works fine.
    
    This happens inconsistently in the network we have set up (WAN).  The
    map can be restarted without a problem, but then there are two map
    PIDs running on the remote system - my concern from the NetMan
    perspective is how can I assure that whenever this happens in the real
    network, I won't have to constantly check to see if the map dies on the
    remote system and then have to kill -9 the old_map_PID?
    
    Both local and remote workstations (RISC) are running the same versions
    of Motif (V1.1.3) and ULTRIX (V4.3).  No core gets dumped, we do not
    get disconnected, the map_PID just keeps on running...it gets started
    as a backgkround process and continues to run as such, even though the
    DECterm window dies???
    
    The user will be telnetd into the remote DECmcc system, setting the
    DISPLAY env-var to their local workstation and then starting the iconic
    map to monitor the network.  Is there perhaps a "better" way to do
    this?  Maybe NOT starting the map as a background process would be
    better?
    
    Thanks.
    Anna

At BT, we see what I think is a similar problem.  At present, we are trying 
to gather enough information to sensibly report it :-)  The MAP users are 
located on SUN workstations and they access the ULTRIX 4.3 DECmcc 1.3 system 
by rsh-ing a shell script that does a setenv DISPLAY back to the SUN 
workstation and then runs mcc_iconic_map.

However, quite often, we find that there are 'orphaned' mcc_iconic_map 
processes running using high percentages of cpu (>70% between them) but no 
longer talking to anything on the SUN systems.  In theory, this shouldn't 
happen as the only way to exit the rsh'd shell script is after DECmcc has 
exited but something seems to break the link, the shell script drops out but 
leaves the cpu-bound mcc_iconic_map process (probably in a loop trying to 
print an error message on a now-closed x windows channel...).

This has a worrying knock-on effect of preventing notifications from being 
delivered because the cpu-bound maps seem to get high priority bites of the 
cpu than the normal notification fm and map pm processing and operators 
therefore stop getting notification delivery although they can navigate and 
use other map facilities.

chris