Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

binlogd(8) [osf1 man page]

binlogd(8)						      System Manager's Manual							binlogd(8)

NAME
binlogd - Binary event-log daemon SYNOPSIS
/usr/sbin/binlogd [-d] [-f config_file] OPTIONS
Enables debugging. Specifies the alternate binary configuration file. DESCRIPTION
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 priority code, which are described in </usr/sys/include/dec/binlog/*.h>. The binlogd 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 dae- mon 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 destina- tion by one or more tabs. 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 </usr/sys/include/dec/binlogd.h> and are as follows: Hardware-Related Events CPU machine checks and exceptions Memory Disks Tapes Device controllers Adapters Buses Stray interrupts Console events Stack dumps SCSI CAM events Software-Detected Events CI port-to-port driver events System communications services events Informational ASCII Messages Generic ASCII informational messages Operational Events ASCII startup messages ASCII shutdown messages Panic messages Timestamp Diagnostic status messages Repair and maintenance messages 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 mes- sages. 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 bin- log 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. Please see binlog.auth(8) for details. 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, if possible. The file contains a line that specifies the binlogd daemon's process identification number. Use this number to disable or reconfigure the binlogd daemon. To disable the binlogd daemon, send the process a SIGTERM signal. For example: kill -TERM `cat /var/run/binlogd.pid` To reconfigure the binlogd daemon, send the process a SIGHUP signal to cause it to read the configuration file again. For example: kill -HUP `cat /var/run/binlogd.pid` Processes on the local system also can connect to the binlogd daemon by using a local known socket (/dev/binlogdmb); this is referred to as a "mailbox". When the "mailbox" connection is established, the connected process receives the binary event records that the binlogd pro- cesses. The libbinlog.a library provides a set of routines that make using the "mailbox" easy. Refer to the descriptions in </usr/sys/include/dec/binlog/*.h> for information on using the "mailbox" programming interface. Cleanup of the Binary Error Log File Normally, a well-managed system will not produce excessively large files, and you will want to maintain the history and continuity of error logs. If it becomes necessary to clean up the binary error logs, use the following procedures. The binary error log file as configured by /etc/binlog.conf (defaulting to /usr/adm/binary.errlog) is not automatically cleaned (removing older versions). As long as binlogd daemon is running, the log file is kept open. Note that 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.) To save and clean up your binary.errlog files do the following: Note The saved log file will overwrite any preceding logfile copies in /usr/var/adm/binlog.saved. If you want to keep previous log files, you must either rename them first, or move them to another location. It is a good idea to compress saved log files to save disk space. After saving any existing logs that you want, run the following command to regain the disk space: # kill -USR1 `cat /var/run/binlogd.pid` This command will rename the current log file to: /usr/var/adm/binlog.saved/binary.errlog.saved and start a new version of the log file. If you prefer a automated cleanup approach, become the root user (superuser) and run the crontab command to uncomment the following crontab entry: #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/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 modi- fied 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 is a reporting tool primarily designed to be used with newer (EV6) processors. Refer to the Com- paq Analyze documentation on the Associated Products CD-ROM for information on installation and use. Refer to dia(8) and the DECevent doc- umentation for information on the DECevent Translation and Reporting Utility. (Note that DECevent must be running on remote hosts to receive notification of remote binlog events.) binlog is also a channel that is read by the Event Management utility (EVM). Messages are also converted to EVM events and notified to the EVM daemon, using DECevent as the translation mechanism. 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 binary.errlog.saved. FILES
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 file name for a saved copy of the log. The location of the PID value for the running binlog daemon. SEE ALSO
Commands: ca(8), dia(8), logger(1), savecore(8), sys_check(8), uerf(8), cron(8) Others: EVM(5), hier(5) System Administration binlogd(8)
Man Page