Conference iosg::all-in-1_v30

3859.0. "FC servers stop and start by themselves" by GIDDAY::LEH () Tue Feb 08 1994 06:07

IOS 3.0A (with MUPA) on VMS 5.5-2

A 3-node cluster was having 3 FC servers enabled on each of indiv nodes: 73, 
202 and 222. Those servers seemed to have been running OK though the period of 
TeamLinks fieldtest 2.0; just recently, they experienced some weird things, I 
was told.

They said those servers periodically stopped and started automatically with no 
intervention. I saw one instance myself when the 202 server was in stopped 
state, I then issued STA(rt), got msg

 %OA-I-LASTLINE, CNB06V::"202=" is already running
Server was not started, Edit the server and specify a startup queue

and this sever came back to Running/Enabled; i.e. it must have been back to 
this state prior to my STA(rt) attempt.

Turning on tracing will be done on these servers; their log files so far 
contained the following

o In OAFC$SERVER.LOG: a lot of

 8-FEB-1994 12:19:21.43  Server: CNB06V::"73="  Error: %OAFC-I-UNKNOWNNODE, A
proxy connection was attempted from unknown remote node, default proxy account
used.  Message: SecCheckProxy; Attempted proxy check from unknown node.

(These happened today with intermittent server problems)

o In OAFC$SERVER_ERROR.LOG: a lot of

        The lock on the following drawer has become invalidated by another
        process.  Note that the lock has been granted and OafcNormal will be
        returned to the client, however, all other processes wishing to share
        this lock will also be granted invalid locks until all processes
        sharing this lock are terminated.
        Drawer directory: DISK$USER11:[SFC.AP1.A1]
        Drawer owner: AP1

plus a couple of 

Error opening DISK$USER15:[OA$SHARA]OA$DAF_A.DAT
Error opening DISK$USER15:[OA$SHARA]OA$DAF_A.DAT

(These are not recorded today when this problem was observed)

Recent changes included the enabling of some 40+ TeamLinks users who now have 
IOS filecab on TL clients. AIDA server seemed to work fine

Any idea while awaiting the FC server trace ?

Thanks

Hong
CSC Sydney

    It was most probably caused by FC servers not being configured with
    correct process quota values, e.g. ASTLM, BYTLM etc., as found out in
    note 3864.
    
    Since the adjustments are in place, no more similiar incident was ever
    observed, at least for the last 2 days or so. Those info in FC server
    transaction log OAFC$SERVER.LOG and error log OAFC$SERVER_ERROR.LOG
    were having nothing to do with this particular problem since they're
    still in the above log files.
    
    Am still concerned of nothing was recorded in related log files, such
    as the above log files and FC trace file.
    
    Hong

    
    Hong.
    
    >Am still concerned of nothing was recorded in related log files, such
    >as the above log files and FC trace file.
    
    I don't see a problem with this:
    
    the trace file traces user actions, nothing more
    oafc$server.log logs internal errors, startup, shutdown messages
    oafc$server_error.log usually has invalid lock messages
    
    None of these fit your situation. If there are no startup/shutdown
    messages in oafc$server.log, then the FCS was not starting/stopping
    by itself. Alos note that this is impossible, it can't spawn itself
    from nowhere. I would guess that what you were seeing were side effects
    of an invalid setup, the FCS was up the whole time, just running out
    of resources.
    
    -bob