SLAC CMLOG Home Page

Starting/Restarting cmlogServer and Related Programs

Also Notes on Client and Server Management Issues



CONTENTS OF THIS WEB PAGE:

Linux Special Notice:

It is best to not use the unix "daemon" command to start the cmlog components in the startup file.
It doesn't seem to work on Linux.

cmlogClientD Special Notice:

The rule for starting cmlogClientD is as follows:
cmlogClientD is to be started and restarted by solaris client applications that need it.
Or, it should be restarted only in the order as explained below under the Realm descriptions.
Background:Problems sometimes arise when cmlogClientD is restarted out from under client applications that are actively using it. The pipe connection between the clients and the new cmlogClientD is not reestablished when cmlogClientD is restarted. It is then necessary to restart the applications. It is obvious that further problems will occur when multiple solaris applications are running on the same node. So, we don't worry about all that here by making the rule that it's up to the applications to manage cmlogClientD themselves, or the startup order below must be strictly observed.

Starting UNIX components for ESD PRODUCTION (also called PEPII)

  • Log onto any unix machine under your account
  • The assumption is that you have the environment set up using ENVS and have ssh login autentication set up

  • Kill applications across all nodes that are logging to the cmlogServer in question. At this point, they consist of CW and ALH.

    1. procmanager CW kill PEPII
    2. procmanager CW kill P2RF
    3. alhmanager $ALHPEPII_NAME kill (note: this kills $ALHP2RF_NAME too)
  • Kill cmlogClientD across all nodes that are logging to the cmlogServer in question.

  • procmanager cmlogClientD kill prod
  • Restart all the cmlog components (this is preferred over using procmanager)

  • cmlogmanager all restart prod
  • Start cmlogClientD on all nodes that need to log to the cmlogServer in question

  • procmanager cmlogClientD start {prod...}
  • Start the applications that were killed in the step above

    1. procmanager CW start PEPII
    2. procmanager CW start P2RF
    3. alhmanager $ALHPEPII_NAME start (note: this starts $ALHP2RF_NAME too)
  • Alternately, you can operate on the cmlog components individually using some variation of this command (but you need to know what you're doing)

  • procmanager {cmlogServer, fwdBro, fwdCliS} {show,start,restart,kill} prod

Starting VMS component for ESD PRODUCTION (also called PEPII)

  • Log onto mcc using the slcshr account
  • Restart the Error Message Forwarding program CMLOG_ERR_FWD by executing this command:
    $warmslcx CMLOG_FWD_PEP /restart

Starting UNIX components for ESD NLCDEV (also called NLCTA)

  • Save the log file and core file if a crash occured
    • Log onto opi00gtw04 using cddev account
    • Mv the cmlogServer.log and core files to files with different names in the same dir: /u2/nlcta/cmlog/data
  • Log onto any unix machine under your account
  • The assumption is that you have the environment set up using ENVS and have ssh login autentication set up

  • Kill applications across all nodes that are logging to the cmlogServer in question. At this point, they consist of CW and ALH.

    1. procmanager CW kill nlcta
    2. procmanager CW kill pack
    3. alhmanager $ALHNLCTA_NAME kill (note: this kills $ALHPACK_NAME too )
  • Kill cmlogClientD across all nodes that are logging to the cmlogServer in question.

  • procmanager cmlogClientD kill nlcdev
  • Restart all the cmlog components (this is preferred over using procmanager)

  • cmlogmanager all restart nlcdev
  • cmlogClientD will be restarted by the applications that use it, so don't worry about it.

  • Start the applications that were killed in the step above

    1. procmanager CW start nlcta
    2. procmanager CW start pack
    3. alhmanager $ALHNLCTA_NAME start (note: this starts $ALHPACK_NAME too)
  • Check that messages are being logged to MCC error log. If not, warmslcx REMOTE_ERR_FWD on MCC
  • Alternately, you can operate on the cmlog components individually using some variation of this command (but you need to know what you're doing)

  • procmanager {cmlogServer, fwdBro, fwdCliS} {show,start,restart,kill} nlcdev

Starting VMS component for ESD NLCDEV

  • Log onto mcc using the slcshr account
  • Restart the Error Message Forwarding program CMLOG_ERR_FWD by executing this command:
    $warmslcx CMLOG_FWD_NLC /restart
    Error messages are then forwarded from VMS to CMLOG
  • Restart the Error Message Forwarding program REMOTE_ERR_FWD by executing this command:
    $warmslcx REMOTE_ERR_FWD /restart
    REMOTE_ERR_FWD (acting like the proxy) receives messages from fwdBro and puts them into the vms error log

Starting UNIX components for ESD DEVELOPMENT (also called LAB)

Starting VMS component for ESD DEVELOPMENT

  • Log onto mccdev using the slcshr account
  • Restart the Error Message Forwarding program CMLOG_ERR_FWD by executing this command:
    $warmslcx CMLOG_FWD_DEV /restart

Starting UNIX components for Babar

  • Start the cmlogServer and client daemon using Babar procedures. I'd recommend calling Dayle and asking for permission.

Starting UNIX components for SPEAR



A General sketch for Starting the client on a VxWorks Processor

The cmlog production /bin and /lib directories should be copied to a disk where the processor can load them.

In the processor's startup files, load the following images from the appropriate target directory:

  • cmlogClientD (bin)
  • libcmlog.a (lib)
  • cmlogVxLogMsg (bin)

Before starting the cmlog tasks, the startup files must do a putenv of CMLOG_PORT to be the port that cmlogServer is using. NOTE: It can also do a putenv of CMLOG_HOST to specify the exact host (ie. bbr-srv01) that the processor should connect. But, if its not defined, the daemon is smart enough to find the host on its own on the local network using just the port number.

Finally, the startup files must spawn the cmlog tasks. If the processor is an EPICS IOC, these tasks must tbe spawned before EPICS is started:

  • taskSpawn( "tCmlogDaemon",100,0,20000,cmlogClientD )
  • taskSpawn( "tCmlogLogMsg",100,0,10000,cmlogVxLogMsg )

Client and Server issues

  • Multiple client processes on one solaris machine can only send to one cmlogServer


  • There is only one cmlogClientD process per solaris machine.
    All client processes sending cmlog messages from
    that machine send messages through that single daemon.
    o That daemon can only connect to one cmlogServer. The result is
    that all the messages go to a single cmlogServer.
    A future release may support multiple client daemons.

Development server disk storage management

The cmlog database files are trimmed daily by the
TRSCRONTAB JOB 

This trimming keeps the database from taking too much room on the disk.

See the link above for full details on commands to control the job, but, here are a few hints:


    log on (don't ssh) as cddev to slcs1
    crontab -l (list job)
    crontabl -r (kills job)
    cd /afs/slac/g/cd/soft/script
    crontab < trscrontab.cddev (starts job)


RETURN TO SLAC CMLOG HOME PAGE 

SLAC Last modified: 26-Sep- 2005 by Ron MacKenzie