Conference decwet::networker

673.0. "savegrp err: exit w/ rtn code 9" by CSC32::K_GILFORD (The Call of the World) Mon May 12 1997 16:25

    When we attempt a savegroup to a particular client, it errors as
    follows:
    
     nterre.cxo.dec.com# savegrp -c gldu.cxo.dec.com gldu
     5/12/97 14:35:41 savegrp: cmd 'savefs -s nterre.cxo.dec.com -g gldu -p
    -l full
    -R -v ' for client gldu.cxo.dec.com exited with return code 9.
     5/12/97 14:35:41 savegrp: gldu.cxo.dec.com:probe unexpectedly exited.
    * gldu.cxo.dec.com:All Host nterre.cxo.dec.com cannot request command
    execution
     5/12/97 14:35:41 savegrp: gldu.cxo.dec.com:probe will retry 2 more
    times
     5/12/97 14:35:47 savegrp: gldu.cxo.dec.com:probe unexpectedly exited.
    * gldu.cxo.dec.com:index asavegrp: authtype nsrexec
    * gldu.cxo.dec.com:index /usr/bin/save: illegal option -- p
    * gldu.cxo.dec.com:index usage: save [<options>] [path ...]
    * gldu.cxo.dec.com:index
    * gldu.cxo.dec.com:index options: [-BEiLnqvx] [-s server] [-N name] [-e
    expirati
    on] [-f dirfile]
    * gldu.cxo.dec.com:index          [-b pool] [-F file] [-I input file]
    [-g group]
     [-l level] [-t date]
    * gldu.cxo.dec.com:index          [-m masquerade] [-W width]
    
    However, an rsh savefs -p to that client works fine.  See below:
    
    nterre.cxo.dec.com# rsh gldu savefs -p
    type: NSR client description;
    pools supported: Yes;
    arch: decaxp;
    CPU type: alpha;
    CPUs: 1;
    hosts: 1;
    IP address: 16.63.160.23;
    kernel arch: OSF1;
    License units: 1050;
    NAS Client: No;
    OS: OSF1 V4.0;
    version: V4.2A;
    save set: path=/, level=full, diskno=1, max_sessions=1, stype=save,\
    path=/usr, level=full, diskno=1, max_sessions=1, stype=save,\
    path=/var, level=full, diskno=1, max_sessions=1, stype=save,\
    path=/var/ftp/pub/unix/doc/cdrom, level=full, diskno=0, max_sessions=1,
    stype=sa
    ve ;
    parallelism: 8
    
    
    Any ideas where the problem is?  Server is running V4.2A.
    
    
    Thanks in advance,
    
    Kevin Gilford
    

I assume the client is also running NetWorker V4.2A.

Check the file /nsr/res/servers.  This file contains the names of 
the NetWorker servers that are allowed to launch commands via
nsrexecd. Yours should contain "nterre.cxo.dec.com".  If it does 
not, add it.  If it has two leading blanks, remove them.

Wes

    Wes,
    
    Sorry about not specifically listing the client version info (thought it
    was included in the error output), but it is V4.2A also.  Already had
    checked /nsr/res/servers and it included "nterre.cxo.dec.com".  Removed
    the two leading spaces as you recommended, but I still get the error.
    
    I just remembered something that may (or may not) be pertinent.  When I
    first re-installed the client software on "gldu" a couple of weeks ago,
    I ran into a problem because the client thought there was another valid
    server, "brain.cxo.dec.com", even though I only told it of one,
    "nterre.cxo.dec.com".  This was because there was a savegrp "running"
    on another server that had gldu as the client.  This savegrp never
    completed (and would be restarted again each night) because somebody
    had removed the tape drive on that server.  Even after removing the
    other server, "brain.cxo.dec.com", from /nsr/res/servers, the "gldu"
    client kept trying to connect there until I completely de-installed the
    server software on "brain.cxo.dec.com".  Is there something embedded
    somewhere within NSR that prevents "nterre.cxo.dec.com" from requesting
    command execution?  Should I just go ahead and re-install the client
    kit on "gldu"?
    
    Thanks again,
    
    Kevin Gilford
    592-4720
    
    

    Don't know the precise reason, but another re-install of the client kit
    fixed the prolem.
    
    Kevin