2.15 Understanding Error Messages

When you encounter a problem on a Unix-like system such as Linux, you must read the error message. Unlike messages from other operating systems, Unix errors usually tell you exactly what went wrong.

p. 30

2.15.1 Anatomy of a Unix Error Message

Most Unix programs generate and report the same basic error messages, but there can be subtle differences between the output of any two programs. Here’s an example that you’ll certainly encounter in some form or other:

$ ls /dsafsda
ls: cannot access /dsafsda: No such file or directory

There are three components to this message:

• The program name, ls. Some programs omit this identifying information, which can be annoying when you’re writing shell scripts, but it’s not really a big deal.
• The filename, /dsafsda, which is a more specific piece of information. There’s a problem with this path.
• The error No such file or directory indicates the problem with the filename.

Putting it all together, you get something like “ls tried to open /dsafsda but couldn’t because it doesn’t exist.” This may seem obvious, but these messages can get a little confusing when you run a shell script that includes an erroneous command under a different name.

When troubleshooting errors, always address the first error first. Some programs report that they can’t do anything before reporting a host of other problems. For example, say you run a fictitious program called scumd and you see this error message:

scumd: cannot access /etc/scumd/config: No such file or directory

Following this is a huge list of other error messages that looks like a complete catastrophe. Don’t let those other errors distract you. You probably just need to create /etc/scumd/config.

note

Don’t confuse error messages with warning messages. Warnings often look like errors, but they contain the word warning. A warning usually means something is wrong but the program will try to continue running anyway. To fix a problem noted in a warning message, you may have to hunt down a process and kill it before doing anything else. (You’ll learn about listing and killing processes in Section 2.16.)

2.15.2 Common Errors

Many errors you’ll encounter in Unix programs result from things that can go wrong with files and processes. Quite a few of these errors stem directly from conditions that kernel system calls encounter, so you can learn something about how the kernel sends problems back to processes by looking at them.

p. 31

No such file or directory

This is the number one error. You tried to access a file that doesn’t exist. Because the Unix file I/O system doesn’t discriminate much between files and directories, this error message covers both cases. You get it when you try to read a file that doesn’t exist, when you try to change to a directory that isn’t there, when you try to write to a file in a directory that doesn’t exist, and so on. This error is also known as ENOENT, short for “Error NO ENTity.”

note

If you’re interested in system calls, this is usually the result of open() returning ENOENT. See the open(2) manual page for more information on the errors it can encounter.

File exists

In this case, you probably tried to create a file that already exists. This is common when you try to create a directory with the same name as a file.

Not a directory, Is a directory

These messages pop up when you try to use a file as a directory, or a directory as a file. For example:

$ touch a
$ touch a/b
touch: a/b: Not a directory

Notice that the error message applies only to the a part of a/b. When you encounter this problem, you may need to dig around a little to find the path component that is being treated like a directory.

No space left on device

You’re out of disk space.

Permission denied

You get this error when you attempt to read or write to a file or directory that you’re not allowed to access (you have insufficient privileges). This error also shows when you try to execute a file that does not have the execute bit set (even if you can read the file). You’ll read more about permissions in Section 2.17.

Operation not permitted

This usually happens when you try to kill a process that you don’t own.

Segmentation fault, Bus error

A segmentation fault essentially means that the person who wrote the program that you just ran screwed up somewhere. The program tried to access p. 32 a part of memory that it was not allowed to touch, and the operating system killed it. Similarly, a bus error means that the program tried to access some memory in a way it shouldn’t have. When you get one of these errors, you might be giving a program some input that it did not expect. In rare cases, it might be faulty memory hardware.