Error code 141 with tar

Question

tar -xvzf $filename.tar.gz || { exit $?; }

Here my scripts would exit with errorCode 141. I am using Fedora Core 6 with tar version 1.15

it wont happen all the time, but more than 70 percent of the time it fails.

Answer 1

As a workaround we are now using cpio for archiving, that works fine for us now, although I would want to know why tar is causing this issue, its around for long time, and being used as standard tool for years.

Answer 2

I realize this thread is more than a few years old, but I'm commenting for those people who stumble upon this thread with the error.

Whenever you use a compression option, tar implicitly opens a connection to the underlying program using a pipe. So, in the OP's example: tar -xvzf $filename.tar.gz, what tar will actually do is run something similar to this: gunzip $filename.tar.gz | tar -xv -. You can verify this by running a top, where you will see two processes (one for tar and one for gzip).

Sometimes though, the pipeline itself breaks. For instance, if the file is not a gzip file. Take this for example: tar -xvzf somefile.iso, which would be equivalent to gunzip somefile.iso | tar -xv -. In such a situation, gzip will error out. When gzip errors out, the pipeline will break. Another possibility would be if the gzip file was correct, but the tar file inside of it was corrupt. In this case, gzip starts sending the uncompressed stream to tar, but then tar realizes something is wrong and closes the stream. gzip here would then error out, because it's output is closed.

In exit values, a value above 128 indicates termination due to a signal, and the amount above 128 signifies which signal caused the termination. So, if we subtract 128 from the OP's exit code of 141, we get 13, which corresponds to SIGPIPE (man 7 signal for a list of standard signals and their corresponding integer values).

The man page lists SIGPIPE's comment as "Broken pipe: write to pipe with no readers". So then, it would appear that gzip is trying to write to the pipe, but tar has stopped listening. My guess here is that gzip is uncompressing the file successfully, but the uncompressed stream is not a valid tar archive. My advice here would be to run gunzip on the file, then run tar on the result file and see which one fails (based on the SIGPIPE, my guess here is that the tar will fail). In either case, it looks like the file isn't readable by these versions of the tools (either corruption or a version conflict of some kind).

How were these files made (what options to tar, etc)? Are they created on this machine or another machine? If you create a .tar.gz file on this machine, can this same machine extract those files without the error?

Answer 3

GNU tar only returns a few things, none of them being -141. however, if it's running a subprocess, like gzip, and that process terminates abnormally, it returns that return code.

I'm not sure what the subprocess might have been though. try it with --verbose and see if you get any clues.