binlogd(8)binlogd(8)NAMEbinlogd - Binary event-log daemon
SYNOPSIS
/usr/sbin/binlogd [-d] [-f config_file] [-r] [-R] [-C]
OPTIONS
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 bin‐
logd 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
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 con‐
tains 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 speci‐
fied 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 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 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 bin‐
log.auth(8) for details.
Operational timestamp (310) events are not forwarded to a remote dae‐
mon.
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 identifi‐
cation 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 sig‐
nal as follows: 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:
../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) ref‐
erence 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/bin‐
log.saved directory is a symbolic link to /usr/var/cluster/mem‐
bers/{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 imple‐
mented, 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/bin‐
log.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 recon‐
struct 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 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 informa‐
tion 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 informa‐
tion 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 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
Command path. Binary configuration file. Specifies the remote hosts
that are allowed to forward messages to the local host. Process iden‐
tification number. Name of the mailbox socket. Kernel log device.
The default location for saved copies of the log.
SEE ALSO
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)