【发布时间】：2010-10-20 15:39:44
【问题描述】：
tar -xvzf $文件名.tar.gz || { 退出 $?; }
这里我的脚本会以 errorCode 141 退出。我正在使用 Fedora Core 6 和 tar 版本 1.15
它不会一直发生，但超过 70% 的时间会失败。
【问题讨论】：
标签： tar error-code
【发布时间】：2010-10-20 15:39:44
【问题描述】：
GNU tar 只返回一些东西，它们都不是 -141。但是，如果它正在运行一个子进程，例如 gzip，并且该进程异常终止，它会返回 that 返回代码。
我不确定子进程可能是什么。试试--verbose，看看有没有线索。
【讨论】：
-
我把脚本改成了 gunzip $filname.tar.gz ； tar -xvf $filename.tar 再次失败并显示 141 的 tar
-
您是否尝试使用 --verbose 运行它，您是否得到任何线索？ tar 还为远程磁带运行 rmt；间歇性问题可能是磁带驱动器的网络问题。了解您正在运行的操作系统可能会有所帮助。
作为一种解决方法，我们现在使用 cpio 进行存档，这对我们来说现在很好，虽然我想知道为什么 tar 会导致这个问题，它存在很长时间，并且多年来一直被用作标准工具。
【讨论】：
我知道这个帖子已经有几年的历史了，但我正在为那些偶然发现这个帖子并出现错误的人发表评论。
每当您使用压缩选项时，tar 都会使用管道隐式打开与底层程序的连接。因此，在 OP 的示例中：tar -xvzf $filename.tar.gz，tar 实际上会运行类似于此的内容：gunzip $filename.tar.gz | tar -xv -。您可以通过运行top 来验证这一点，您将在其中看到两个进程（一个用于 tar，一个用于 gzip）。
但有时，管道本身会中断。例如，如果文件不是 gzip 文件。以此为例：tar -xvzf somefile.iso，相当于gunzip somefile.iso | tar -xv -。在这种情况下，gzip 会出错。当 gzip 出错时，管道将中断。另一种可能性是 gzip 文件是否正确，但其中的 tar 文件已损坏。在这种情况下，gzip 开始将未压缩的流发送到 tar，但随后 tar 意识到有问题并关闭了流。然后这里的 gzip 会出错，因为它的输出已关闭。
在退出值中，大于 128 的值表示因信号而终止，大于 128 的值表示导致终止的信号。因此，如果我们从 OP 的退出代码 141 中减去 128，我们得到 13，它对应于 SIGPIPE（man 7 signal 用于标准信号及其对应整数值的列表）。
手册页将 SIGPIPE 的评论列为“Broken pipe: write to pipe without reader”。因此，看起来 gzip 正在尝试写入管道，但 tar 已停止侦听。我的猜测是 gzip 正在成功解压缩文件，但未压缩的流不是有效的 tar 存档。我的建议是在文件上运行 gunzip，然后在结果文件上运行 tar 并查看哪个失败（基于 SIGPIPE，我的猜测是 tar 会失败）。无论哪种情况，这些版本的工具似乎都无法读取文件（损坏或某种版本冲突）。
这些文件是如何制作的（tar 的哪些选项等）？ 它们是在这台机器上还是在另一台机器上创建的？ 如果您在这台机器上创建一个 .tar.gz 文件，这台机器可以提取这些文件而不会出现错误吗？
【讨论】：
-
谢谢！说得通。在 nohup 会话中使用 tar -xzf 时出现错误 141，该会话由 tar 命令之前的命令杀死的进程启动。我的解决方案是将子进程对父进程的杀戮延迟到解压缩 tarball 之后。重定向 tar 的输出可能有帮助，但我没有尝试。
-
当
tar的输出通过管道传输到另一个提前关闭管道的进程时也会发生这种情况，例如tar -tf x.tar | head或tar -tf x.tar | grep -q .（head在读取指定的行数后关闭管道，grep -q在看到模式后立即关闭管道。） -
继续并确保仍然安装了 gzip。 （ gzip --help ）在我的情况下，一些天才在服务器上覆盖了 /bin/gzip （可能是我）。