Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Apropos / Subsearch:
optional field

binlogd(8)							   binlogd(8)


  binlogd - Binary event-log daemon


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


  -d  Enables debugging.

  -f config_file
      Specifies	the alternate binary configuration file.

  -r  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.

  -R  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.


  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	bin-
  logd daemon reads from the /dev/kbinlog special device and from the Inter-
  net 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.

  low 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:


  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	for-
  ward 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 speci-
  fies 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	fol-

       kill -HUP `cat /var/run/binlogd.pid`

  Managing the Binary Error Log	File

  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 pro-
  cedures described below.

  The binary.errlog file is a symbolic link to:


  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. If you want	to keep	pre-
  vious	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 loca-


  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	cron-
  tab 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:

   1.  Run at 2:00 AM on the first day of every	month

   2.  Automatically rename the	current	log file to be:


   3.  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

  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 (CA)
      Compaq Analyze is	a reporting tool primarily designed to be used with
      EV6 and later model processors.  Use the psrinfo -v command to deter-
      mine your	processor model.  Refer	to ca(8) and the Compaq	Analyze	docu-
      mentation	for information	on installation	and use.

      Refer to dia(8) and the DECevent documentation for information on	the
      DECevent Translation and Reporting Utility.

  Event	Manager	(EVM)
      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

  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	mail-
  box.	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.


      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.


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

  Others: EVM(5), hier(5)

  System Administration