mysql - FreeBSD、MySQL、Perl、bash : intermittent blocking on named pipes?

Question

这很奇怪，我不确定真正的罪魁祸首是谁。

我正在 FreeBSD (6.2) 上编写一些脚本？它广泛使用了以下 ***bash***ism:

do_something <(mysql --skip-column-names -B -e 'select ... from ... where ...;')

... 其中“do_something 是一个有点笨拙的实用程序(在 Perl 中)，它不会从管道中读取。如果我使用常规文件，它工作正常。我的 bash 脚本使用诸如exec 4< <(...) 这些类型的查询(后面是 while read x y z <&4; do ... 形式的循环似乎从来没有任何问题。

但是，Perl (5.8.x) 似乎会周期性地阻塞(显然是永远)。我尝试更改 chomp(my $data = <MYDATA>);与一个使用 sysread 的例程一起，我用 Python 编写了一些测试用例以进行比较。这些似乎比惯用的 Perl 代码阻塞的频率要低得多，但它们有时仍然会阻塞。 (使用 f.read() 或 os.read(f.fileno()...) 的 Python 代码在这个问题上似乎表现得差不多)。

我尝试使用 ... <(cat ...) 重现问题(我正在 cat 常规文件)并且似乎永远不会重现那个停顿。

我浏览了一些ktrace/kdump 数据...但我更熟悉 Linux strace 甚至 Solaris truss ...所以我也还没弄清楚接下来会发生什么。

我想我们基本上可以排除 Perl，因为我已经使用 Python 重现了同样的问题......我不明白 bash 怎么会在这里做错任何事情(它只是创建/var/tmp/sh-np-xxx 中的一个命名管道，并将进程连接到它)。

mysql shell/utility 正在做什么可能会导致这种情况？我不认为我从其他任何东西(例如 cat 或 dd)看到它。我没有在 Linux 下测试过这种情况……但我使用了 <(...) (进程替换)在 Linux 下使用多年，不记得曾经见过这个。

这是 FreeBSD 的问题吗？

当然我可以使用临时文件来解决这个问题......但我肯定更愿意理解它为什么这样做(并避免临时文件带来的一些竞争和清理困惑)。

有什么建议吗？

Answer 1

对 mysql 的输出进行操作和直接对文件进行操作之间的最大区别在于时间。当 perl 进程停止时，最大的问题是:“为什么它没有向前推进”？您可以使用 ps 的“l”选项来查看 perl 进程的等待 channel ；这样你就可以看到它是否在读取时被阻塞，或者是否发生了其他事情。如果它真的被管道输入阻塞，我希望 perl 的 MWCHAN 条目是“piperd”。

对于 mysql 进程，同样的信息会很有趣。

您的 Python 测试代码是什么样的？

另一种避免 bashism 的写法是这样的；这将允许你排除 bash:

mysql --skip-column-names -B -e 'select ... from ... where ...;' | do_something /dev/stdin

其他有趣的问题:

• mysql 的 --unbuffered 选项会改变什么吗？

• 通过 dd 管道传输 mysql 输出会改变什么吗？ (例如，“perlscript <(mysql ... | dd)

总结:需要更多信息。