tty3 and tty4 reflect certain log files. Log files always contain messages from all the loglevels, including debug, but the minimal loglevel on the terminals can be controlled with the loglevelcommand line option.

There are two other log files created on the target filesystem, in the /root directory, also accessible at /mnt/sysimage/root during the installation:

/mnt/sysimage/root/install.log.syslog, messages from installation chroot logged through the system's syslog. Mostly information about users and groups created during yum's package installation.

Log format

In files the format of the log messages is as follows:

H:M:S,ms LOGLEVEL facility:message

where:

H:M:S is the message timestamp

ms is the millisecond part of timestamp. Note that this will usually become zero on a remote syslog.

LOGLEVEL is the message loglevel. In theory, because kernel messages are part of anaconda logs, all loglevels that are defined in rsyslog can appear in the logfiles. Anaconda itself will however log only at the following loglevels:

DEBUG

INFO

WARN

ERR

CRIT

facility is the program or component that created the message. Could be for instance kernel<code>, <code>anaconda, storage or similar.

message is the log message itself.

For the logs running in terminals, the format simply is:

LOGLEVEL facility:message

Remote logging

Anaconda supports remote logging handled through the rsyslog daemon running on the installed system. It can be configured to forward its logs through TCP to an arbitrary machine in network that is also running a syslog daemon. This is controlled with the syslogcommand line option. Do not forget to enable the port you are running your local syslog daemon on in firewall."

What is logged remotely

Everything that is logged directly by anaconda should also appear in the remote logs. This includes messages emitted by the loader and the storage subsystem. Log files used by external programs (x.org.log) are currently not transferred to the remote.

The remote logging only works when the installer initializes network. Once network is up, it takes a couple of minutes for rsyslogd to realize this. Rsyslog has a queue for messages that couldn't be forwarded because of inaccessible network and it eventually forwards all of them, in the correct order.

Configuration

It's up to you how the remote logging daemon is configured, you can for instance log all incoming messages into one file or sort them into directories according to the IP address of the remote system.

The anaconda RPM provides the analog script, which generates a suitable rsyslogd configuration file based on a couple of install parameters. It is also able to generate a bash command to launch rsyslogd with the generated configuration. Thus you can do from a shell:

This starts an rsyslog daemon that will listen on port 6080. The logs from the remote machine with IP 10.34.33.221 will be stored under /home/akozumpl/remote_inst/10.34.33.221/, e.g. /home/akozumpl/remote_inst/10.34.33.221/anaconda.log.

The remote syslog configuration exploits several log message characteristics to be able to sort them into the correct files:

the IP of the message sender to know which machine generated the message and thud what directory does the message belong to.

anaconda.log, storage.log and program.log have the name embedded in them as programname.

syslog/code> messages are coming in from kernel and daemon facilities, just like they do on the installed system

<code>install.log.syslog made during package installation is logged as a special sysimage hostname.

Run analog without the -o option to see how exactly does a fitting configuration file look like. Also notice that it uses the same message format for remote logging as anaconda does, but you can of course modify this to specify any format you want.

See also

Anaconda logs on the running system

After every successful installation, anaconda logs are copied into /var/log on the system you just installed. To avoid name clashes with other log files there, the anaconda logs are renamed:

Name during installation

Name on the target system

/tmp/anaconda.log

/var/log/anaconda.log

/tmp/syslog

/var/log/anaconda.syslog

/tmp/X.log

/var/log/anaconda.xlog

/tmp/program.log

/var/log/anaconda.program.log

/tmp/storage.log

/var/log/anaconda.storage.log

/tmp/yum.log

/var/log/anaconda.yum.log

Logging tips

If you are asked to provide logs for a bugzilla, your best option is switching from the anaconda GUI to tty2 and then use scp to copy the files to your computer, e.g.:

cd /tmp
scp anaconda.log aklap:/home/akozumpl/

It is also possible to make a complete dump of a state of running anaconda process (the same dump that is compiled automatically if an unhandled exception occurs). To do this send the main anaconda process SIGUSR2:

kill -USR2 `cat /var/run/anaconda.pid``

This builds a file /tmp/anaconda-tb-????? that also contains anaconda.log, storage.log and syslog.

To do

The current list of logging requirements and tasks is maintained in bugzilla 524980.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.