|
|
Error MessagesSummary: Finding MessagesOften 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. syslog.confLogging 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' . 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? 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 LogsSometimes 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. {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 MessagesSome error messages indicate a user error and some a program fault. bash: {xxx}: command not found tells you that the shell didn't find the command you were trying to run. ./ ./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. gdb {program name with full path}<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 Linux-FAQ: Solutions to Common Miscellaneous Problems Linux-FAQ: Frequently Encountered Error Messages Revision / Modified: Oct. 02, 2001 Legal: This page is covered by the GNU Free Documentation License . Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft. |