Error Messages

Summary:

• Error Messages
• Finding Messages
• syslog.conf
• Generating Error Logs
• Making Sense of Error Messages
  • Related Resources:

Finding Messages

Often if something doesn't work as expected you don't see an error message. In most cases it is actually there, but you'll have to know where to look for it.

Kernel, modules, and daemons log messages in '/var/log/messages'. This is an ordinary text file you can have a look at as 'root'. Since you usually only want to see the last few lines and 'messages' becomes quite large, use

tail /var/log/messages

Notice that '/var/log' contains a lot of other helpful log files, too, like 'boot.log', which contains boot messages or further subdirectories which contain logs for running services like 'cups/', 'httpd/' or 'mail/'. Whereas 'messages' usually lists a short summary of system messages, these other logs should be checked for more detailed messages by specific services.

Mandrake Linux 8.1 and later provide you with a convenient log file viewer via the 'Mandrake Control Center' ('System' - 'Logs').

During installation you can press 'ALT-F3' and 'ALT-F4' to see messages from the kernel and the installer. This might be helpful if your stuck and the graphical installer provides no intelligible error message.
After installation you will find three log files in 'root's' home directory: 'ddebug.log', 'install.log' and 'report.bug'. 'ddebug.log' contains kernel messages, 'install.log' package installation messages and 'report.bug' contains both, plus detailed system and installation information.
If you are reporting installation errors to Mandrake, make sure you include the 'report.bug' file.

syslog.conf

Logging is configured via the 'root-only' file '/etc/syslog.conf'. There you can also see which other log files exist and which programs or services write which messages to them. At the bottom of the file, you might find a line like this:

*.* /dev/tty12

This line tells the number of the virtual terminal system messages are logged to (in addition to writing them to the log files). To have a look at this screen, press ALT-CTRL-F12 simultaneously. To get back to X, press ALT-CTRL-F7.

It may sometimes be a good idea to redirect error messages from a certain process to a file of its own. The basic syntax for this is:

{facility}.{priority} {log file}

Example:

mail.=debug;mail.=info;mail.=notice -/var/log/mail/info

writes all messages from the mail daemon of levels 'info', 'debug' and 'notice' to the file '/var/log/mail/info' .
Valid facilities (mail, news, cron etc) and priorities (info, notice, warning etc) are described in

man syslog.conf

X Window writes its startup messages to '/var/log/XFree86.{x}.log'. Error messages are additionally logged to '~/.xsession-errors' (beware the dot1.1 ). Window managers usually write errors to a file called '~/.{name of wm}-errors' and to the system console (the one you used to log in). Messages written to the system console are - of course - not visible as long as you are in X, i.e. unless you switch to terminal 12. You can see them anyway, just start a virtual terminal like 'xterm' or 'rxvt' with the '-C' option and they will show every message written to the system console.

With X programs it's a different thing. Maybe you've clicked a button which is supposed to run a program, but nothing happens. What now?
Easy. Open a virtual terminal like xterm and type the command that should run the program. Now you will be shown any error message that the program may generate. To write these messages to a file, see the next chapter.

Often programs offer options to make error messages more explicit (e.g. RPM or PPP), usually by an option called '––verbose' or '-v'. Consult the program's documentation.

Generating Error Logs

Sometimes error messages scroll by too fast (e.g. when starting X or running 'make'). It would be very convenient to have them written to a file.
You can generate error logs for every program by yourself:

{command} 2> error.log

will send all error messages of {command} to a file called 'error.log' in your current working directory using a built-in shell mechanism called output redirection.

Making Sense of Error Messages

Some error messages indicate a user error and some a program fault.
For example

bash: {xxx}: command not found

tells you that the shell didn't find the command you were trying to run.
This is most likely a user error. Possible causes are numerous: typos, binary resides in a directory which is not part of $PATH or which you don't have access to. It is also important to remember that the directory you are in does not become part of $PATH by default in all security levels but the lowest. Therefore you have to tell the shell explicitly to run a binary in it by putting

./

./configure

configure

{xxx}: permission denied

You've tried to open a file or run a program you do not have the proper permissions to get access to or the program writes entries into directories you are not permitted to write to.

Errors like the dreaded segmentation fault

{xxx} got SIGSEGV at (etc.)

belong to the group of SIGNAL errors you really can't do anything about in most cases (unless you're a programmer, that is). Either the program has serious difficulties with handling memory or it accesses the wrong version of a code library. Tell its author about it after you have made sure there isn't an update available already and that you've got the correct library versions installed.
If you want to be helpful you might first run the GNU debugger gdb to do a 'backtrace' with

gdb &#123;program name with full path&#125;<br> (gdb) run

(now try to reproduce the situation in which the program crashed on you.)

and mail its output to the author along with a description of your system (architecture, operating system, distribution, version numbers).

Doing an 'strace' with

strace -o {output file} {program name}

will generate lots of output and you should send this output only to people who have explicitly requested it.

However it is always a good idea to look up the program's documentation first before asking someone else. ;-)

Related Resources:

man 7 signal

man syslog.conf

man X

Revision / Modified: Oct. 02, 2001
Author: Tom Berger

Legal: This page is covered by the GNU Free Documentation License. Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft.