binlogd(8) — Maintenance

NAME

binlogd − Binary event-log daemon

SYNOPSIS

/usr/sbin/binlogd [−d] [−f config_file]

OPTIONS

−dEnables debugging.

−f config_file
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 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. 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

100CPU machine checks and exceptions

101Memory

102Disks

103Tapes

104Device controllers

105Adapters

106Buses

107Stray interrupts

108Console events

109Stack dumps

199SCSI CAM events

Software-Detected Events

201CI port-to-port driver events

202System communications services events

Informational ASCII Messages

250Generic ASCII informational messages

Operational Events

300ASCII startup messages

301ASCII shutdown messages

302Panic messages

310Timestamp

350Diagnostic status messages

351Repair and maintenance messages

You can specify the following severity levels:

severe
Specifies events that cannot be recovered and that are usually fatal to system operation.

high
Specifies events that either can be recovered or cannot be recovered but are not fatal to system operation.

lowSpecifies 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. 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 processes. 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:

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

2.Automatically rename the current log file to be:

/usr/var/adm/binlog.saved/binary.errlog.saved

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 newer (EV6) processors. Refer to the Compaq Analyze documentation on the Associated Products CD-ROM for information on installation and use.

DECevent
Refer to dia(8) and the DECevent documentation 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.)

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

sys_check
The sys_check(8) utility uses translation and reporting tools to read system error files such as binary.errlog.saved.

FILES

/usr/sbin/binlogd
Command path.

/etc/binlog.conf
Binary configuration file.

/etc/binlog.auth
Specifies the remote hosts that are allowed to forward messages to the local host.

/var/run/binlogd.pid
Process identification number.

/dev/binlogdmb
Name of the “mailbox” socket.

/dev/kbinlog
Kernel log device.

/usr/var/adm/binlog.saved/binary.errlog.saved
The default file name for a saved copy of the log.

/var/run/binlogd.pid
The location of the PID value for the running binlog daemon.

Museum

Related Articles