*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> binlogd (8)              
Title
Content
Arch
Section
 

binlogd(8)

Contents


NAME    [Toc]    [Back]

       binlogd - Binary event-log daemon

SYNOPSIS    [Toc]    [Back]

       /usr/sbin/binlogd [-d] [-f config_file] [-r] [-R] [-C]

OPTIONS    [Toc]    [Back]

       Enables debugging.  Specifies the alternate binary configuration
 file.  Allows the binlogd daemon to create an inet
       port  for remote access. This is the default behavior. Use
       the -R option to prevent the binlogd daemon from  creating
       an  inet  port.  If  you  specify  the  -r  and -R options
       together, the last one specified takes  precedence.   Prevents
 the binlogd daemon from creating an inet port. Using
       the -R option prevents all remote access.  Remote  systems
       cannot  send  messages to be logged locally, and the local
       daemon cannot send messages to be logged remotely. If  you
       specify the -r and -R options together, the last one specified
 takes precedence.  Prevents the binlogd daemon  from
       running  the  binex utility on startup.  If this option is
       not specified, the daemon uses binex -w  to  validate  the
       error  log  and  to  remove any invalid data that may have
       been appended to the file if the previous  sesssion  ended
       with  a  system panic or a power failure. See binex(8) for
       more information.

DESCRIPTION    [Toc]    [Back]

       The binlogd daemon logs binary event records to the  files
       specified in the /etc/binlog.conf configuration file.

       Each  binary  event  record  includes  an  event class and
       severity   code,    which    are    described    in    the
       /usr/sys/include/dec/binlog/*.h  header  file. The binlogd
       daemon reads from the /dev/kbinlog special device and from
       the  Internet domain socket specified in the /etc/services
       file. The binlogd daemon is configured when it  starts  up
       and when it receives a hangup signal.

       The  /etc/binlog.conf  file  contains entries that specify
       the event class, the severity level, and  the  destination
       to which the binlogd daemon sends the messages.  Each line
       of the /etc/binlog.conf file contains an entry.

       The event class and the severity level are separated by  a
       period  (.).  The event class and severity level are separated
 from the destination by one or more tabs or  spaces.
       Blank lines and lines beginning with a # (number sign) are
       ignored.

       If you specify an asterisk  (*)  for  an  event  class  or
       severity  level,  all event classes or all severity levels
       are selected.  The event class is specified as  a  decimal
       number.   The  available  class codes are specified in the
       /usr/sys/include/dec/binlogd.h header file.

       You can specify the following severity  levels:  Specifies
       events that cannot be recovered and that are usually fatal
       to system operation.  Specifies events that either can  be
       recovered or cannot be recovered but are not fatal to system
 operation.  Specifies informational messages.

       The destination for the messages can be  either  the  full
       pathname  of  a local file or the name of a remote system.
       The remote host must be known to the system.  You  specify
       a remote system as follows: @host

       For  security  reason,  logging of messages forwarded from
       remote hosts is by default  turned  off.  To  configure  a
       local  host  for  accepting  binlog  messages  from remote
       hosts, you must become the superuser (root)  and  manually
       create  the  /etc/binlog.auth  file using a text editor on
       the local host.

       The /etc/binlog.auth file specifies which remote hosts are
       allowed  to  forward  binlog  messages  to the local host.
       Unless the domain host name of a remote host is  given  in
       the  local  /etc/binlog.auth file, the local host will not
       log any binlog messages from that remote  host.  See  binlog.auth(8) for details.

       Operational  timestamp (310) events are not forwarded to a
       remote daemon.

       You can specify dumpfile instead of  an  event  class  and
       severity  level  to identify the pathname of the file that
       will contain the kernel binary event-log buffer, which the
       savecore command recovers from a system dump.

       The  default /etc/binlog.conf file causes the binlogd daemon
 to create  a  binary  event-log  file  for  all  event
       classes and severity levels and specifies the binary crash
       dump file. The following is  an  example  of  the  default
       /etc/binlog.conf file:

       *.* /usr/adm/binary.errlog dumpfile /usr/adm/crash/binlogdumpfile


       The binlogd daemon also creates  the  /var/run/binlogd.pid
       file.   This  file contains a line specifiying the binlogd
       daemon's process identification number  (PID).    Use  the
       contents  of this file to send signals to the binlogd daemon,
 as described below.

       If you modify the daemon's configuration  file,  you  must
       instruct  the  daemon  to  re-read it.  To reconfigure the
       daemon, send it a SIGHUP signal as follows: kill -HUP `cat
       /var/run/binlogd.pid`


   Managing the Binary Error Log File    [Toc]    [Back]
       The  binary error log file contains historical information
       that might be important in diagnosing system problems, and
       you  should generally avoid archiving or removing the file
       unless it has grown excessively large.  The  size  of  the
       file  is  reported  to the Event Manager (EVM) every night
       and you can monitor its growth rate  using  the  following
       EVM  command:  #  evmget  -f  '[name *.binlog_chan]' -A -t
       "@timestamp  @@"  29-Mar-2001  02:00:01   binlog  channel:
       Binary  error  log size is 0.3 Mbytes 30-Mar-2001 02:00:00
       binlog channel:  Binary  error  log  size  is  0.3  Mbytes
       31-Mar-2001  02:00:00   binlog  channel:  Binary error log
       size is 0.3 Mbytes 01-Apr-2001 02:00:00   binlog  channel:
       Binary  error  log size is 0.3 Mbytes 02-Apr-2001 02:00:00
       binlog channel:  Binary  error  log  size  is  0.3  Mbytes
       03-Apr-2001  02:00:00   binlog  channel:  Binary error log
       size is 0.3 Mbytes 04-Apr-2001 02:00:00   binlog  channel:
       Binary  error  log size is 0.3 Mbytes 05-Apr-2001 02:00:00
       binlog channel: Binary error log size is 0.3 Mbytes

       If it becomes necessary to clean up the binary error logs,
       use the procedures described below.

       The binary.errlog file is a symbolic link to:

         ../cluster/members/{memb}/adm/binary.errlog

       This  symbolic  link is a CDSL (Context Dependent Symbolic
       Link) and must not be deleted.  (See the  System  Administration
  manual and hier(5) reference page for more information
 on CDSLs.)

       The archive  procedure  overwrites  any  existing  logfile
       copies     in     /usr/var/cluster/members/{memb}/adm/binlog.saved.
 The /usr/adm/binlog.saved directory is  a  symbolic
   link  to  /usr/var/cluster/members/{memb}/adm/binlog.saved
 and  must not be deleted. If you  want  to  keep
       previous  log files, you must either rename them first, or
       move them to another location.  Compress saved  log  files
       to save disk space.

       After saving any existing archived logs, use the following
       command to archive the current  log:  #  kill  -USR1  `cat
       /var/run/binlogd.pid`

       The  preceding  command copies the current log file to the
       following location:

       /usr/var/cluster/members/{memb}/adm/binlog.saved/binary.errlog.saved


       A  new  version of the binary.errlog log file is then created.


       If you prefer an automated cleanup  approach,  become  the
       root  user  (superuser)  and run the crontab -e command to
       uncomment the following crontab entry by  removing  the  #
       character from the start of the line:

       #0 2 1 * * kill -USR1 `cat /var/run/binlogd.pid`

       See  the  crontab(1)  reference page for more information.
       When implemented, this crontab entry will do  the  following:
  Run at 2:00 AM on the first day of every month Automatically
 rename the current log file to be:

              /usr/var/cluster/members/{memb}/adm/binlog.saved/binary.errlog.saved
  Start  a new copy of
              the log file, /usr/adm/binary.errlog.

       Note that the saved log file overwrites the previous  version,
  so  you  should  add  a line to crontab to copy the
       existing saved file if you want  to  preserve  it.   Using
       this  crontab  entry means that the current and saved version
 combined will  preserve  up  to  two  months  of  log
       records.   Regular  backups  and a restore are required in
       order to reconstruct older binary error logs. The  crontab
       entry  can also be modified to adjust the frequency of the
       automatic cleanup.






   Examining the Event-Log File    [Toc]    [Back]
       In previous releases, the uerf event report formatter  was
       used to translate the binary event-log file to ASCII text.

       For this release, a number of  options  are  available  as
       described  in  the  following sections.  It is recommended
       that you migrate from uerf to one of these solutions: Compaq
  Analyze  is a reporting tool primarily designed to be
       used with EV6 and later model processors.  Use the psrinfo
       -v  command  to  determine your processor model.  Refer to
       ca(8) and the Compaq Analyze documentation for information
       on installation and use.  Refer to dia(8) and the DECevent
       documentation for information on the DECevent  Translation
       and  Reporting  Utility.  binlog is also a channel that is
       read by the Event Management utility (EVM).  Messages  are
       converted  to  EVM  events and notified to the EVM daemon.
       Refer to the EVM(5) reference page and System  Administration
  for  more  information  on  event  management.   The
       sys_check(8) utility uses translation and reporting  tools
       to  read  system error files such as the binary.errlog and
       binary.errlog.saved.

   Using the Mailbox Programming Interface    [Toc]    [Back]
       Processes on the local system can connect to  the  binlogd
       daemon  by  using  a  local known socket (/dev/binlogdmb).
       This socket is referred to as a mailbox.  When  a  process
       establishes  a  mailbox  connection it receives the binary
       event records processed by the binlogd daemon.   The  libbinlog.a
  library  provides a set of routines that you can
       use to access the mailbox.  Refer to the  descriptions  in
       the /usr/sys/include/dec/binlog/*.h header file for information
 on using the mailbox programming interface.

FILES    [Toc]    [Back]

       Command path.  Binary configuration file.   Specifies  the
       remote  hosts  that are allowed to forward messages to the
       local host.  Process identification number.  Name  of  the
       mailbox  socket.  Kernel log device.  The default location
       for saved copies of the log.

SEE ALSO    [Toc]    [Back]

      
      
       Commands: binex(8),  ca(8),  cron(8),  dia(8),  logger(1),
       psrinfo(1), savecore(8), sys_check(8), uerf(8)

       Others: EVM(5), hier(5)

       System Administration



                                                       binlogd(8)
[ Back ]
 Similar pages
Name OS Title
binex Tru64 Binary event log extraction utility
evmd Tru64 Event Manager daemon
rtmond IRIX system event monitoring daemon
EvmConnection Tru64 Connection to the Event Management daemon
eventmond IRIX system event monitoring daemon
sysevent IRIX System Log Event Capture System Daemon
alPendingEvents IRIX Get total number of event queued in event queue
alCheckEvent IRIX Looks for an event in the event queue and retrieves it.
sat_eventtostr IRIX convert an audit event index to/from an audit event string
tsearch Linux manage a binary tree
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service