Linux – How to Understand Error Codes

error handlinglinuxsystem-calls

I am working on Linux (Kernel Version 2.6.32.28) laptop.
After I inserted/did file io/removed a SD combo card, I got following errors:

mmcblk0: error -123 sending status command  
mmcblk0: error -123 sending read/write command, response 0x0, card status 0x0  
mmcblk0: error -123 sending requesting status

Now, I would like to understand what these errors mean.

As I saw few standard error codes are located in arch/powerpc/boot/stdio.h and other scattered at various other places..

Is there any systematic way in Linux to track (& understand) the error codes (in the source) ?

Best Answer

There are standard error values, defined in errno.h. You can look at this file on your system to see the numerical values. On most systems, they're in /usr/include/errno.h or a file that it includes. On Linux, most are in /usr/include/asm-generic/errno-base.h or /usr/include/asm-generic/errno.h, with a few more in /usr/include/bits/errno.h.

If you have a numerical value, call the standard library function strerror or perror to obtain the corresponding error message (in your current locale). From the command line, a quick way to see an error string is one of

perl -MPOSIX -le 'print strerror 123'
python -c 'import os; print os.strerror(123)'
zmodload zsh/system; syserror 123  # in zsh

Related Solutions

Shell – Linux for VMS DCL “ON ERROR”

I think you want the trap function, specifically:

error_func() 
{
    echo 'An error occurred!'
    exit 1
}

trap error_func ERR

Errors later will jump to the function. This is supported by at least bash, zsh, and ksh.

Shell Pipes – How to Understand Pipes

About your performance question, pipes are more efficient than files because no disk IO is needed. So cmd1 | cmd2 is more efficient than cmd1 > tmpfile; cmd2 < tmpfile (this might not be true if tmpfile is backed on a RAM disk or other memory device as named pipe; but if it is a named pipe, cmd1 should be run in the background as its output can block if the pipe becomes full). If you need the result of cmd1 and still need to send its output to cmd2, you should cmd1 | tee tmpfile | cmd2 which will allow cmd1 and cmd2 to run in parallel avoiding disk read operations from cmd2.

Named pipes are useful if many processes read/write to the same pipe. They can also be useful when a program is not designed to use stdin/stdout for its IO needing to use files. I put files in italic because named pipes are not exactly files in a storage point of view as they reside in memory and have a fixed buffer size, even if they have a filesystem entry (for reference purpose). Other things in UNIX have filesystem entries without being files: just think of /dev/null or others entries in /dev or /proc.

As pipes (named and unnamed) have a fixed buffer size, read/write operations to them can block, causing the reading/writing process to go in IOWait state. Also, when do you receive an EOF when reading from a memory buffer ? Rules on this behavior are well defined and can be found in the man.

One thing you cannot do with pipes (named and unnamed) is seek back in the data. As they are implemented using a memory buffer, this is understandable.

About "everything in Linux/Unix is a file", I do not agree. Named pipes have filesystem entries, but are not exactly file. Unnamed pipes do not have filesystem entries (except maybe in /proc). However, most IO operations on UNIX are done using read/write function that need a file descriptor, including unnamed pipe (and socket). I do not think that we can say that "everything in Linux/Unix is a file", but we can surely say that "most IO in Linux/Unix is done using a file descriptor".

Best Answer

Related Solutions

Shell – Linux for VMS DCL “ON ERROR”

Shell Pipes – How to Understand Pipes

Related Question