|
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, usetail /var/log/messages instead of 'less'. Using the
'-f' option even allows you to follow changes made to that file in real time.
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.
 section index  top
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
dot!). 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.
section index top
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.
section index top
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./in
front of the filename (that is ./configureinstead of 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 [program name with full path]
(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. ;-)
section index top
|
