如何检查的过程充满了stdout或stderr缓冲

鉴于这似乎被卡在Linux机器上的过程，我怎么能告诉如果还停留由于STDOUT或STDERR缓冲区已满？如何检查的过程充满了stdout或stderr缓冲

在我的具体情况，我也正在执行没有CPU活动的过程，但是当我希望它已在几秒钟内退出保持运行。我怀疑这个过程已经填满了STDOUT或STDERR的缓冲区，以及由于某种原因应该从缓冲区停止读取的过程。

有什么办法可以证实这种怀疑吗？

来源

2013-01-21 Matt Sheppard

另一种理论如果不能平移 - 我可以检查过程是否被阻塞，等待在STDIN上的输入？ –

这是一个std Linux的过程中，专门安装第三方软件包或定制编写的代码？

标准Linux进程不应该有这样的问题，而自定义代码是最有可能的罪魁祸首。调试这种情况的最简单方法是添加特殊的调试代码。

否则，看看是否您的STD实用程序或第三方封装具有冗余模式，往往-v, or -vv, or -vvv。

最后，对于某些Linux版本，您可以使用您的操作系统版本truss (for solaris),strace来查看挂载的位置。

IHTH

来源

2013-01-21 03:50:42 shellter

这是一个在这里开发的C程序，它由一些Java代码（也是我们自己的设计）发起的，但它不是可重现的情况，所以我试图从已经运行的过程中获得什么信息在我杀死它之前。 –

实际上，虽然-v等是有趣的，但是strace几乎总是可以放在正确的位置（通过函数名），问题是，通常你可以知道100个“printf”的哪个位置（例如）在你的代码中被调用。希望你看到的参数和值可以让你知道你的代码库中哪一行是挂起的。企业级系统中的高概率是磁盘集群中的特定驱动器。好luk。 – shellter

关于你的替代理论，看看SO。我发现this有趣，我希望这里的东西很有用。 CHEERS

来源

2013-01-21 03:53:56

你有没有试过pidstat？（：http：//khaidoan.wikidot.com/pidstat）向您展示了如何使用它来获取关于I/O问题以及关于您的流程的其他信息的一些信息，如果您拥有现代化的内核并且您已设置好正确。 CHEERS –

GDB连接并运行回溯几乎证实了我的理论......

$ gdb /opt/our_process pid 
...blah blah blah... 
(gdb) bt 
#0 0x0000003f27adae60 in __write_nocancel() from /lib64/libc.so.6 
#1 0x0000003f27a71583 in _IO_new_file_write() from /lib64/libc.so.6 
#2 0x0000003f27a7144a in _IO_new_file_xsputn() from /lib64/libc.so.6 
#3 0x0000003f27a49531 in buffered_vfprintf() from /lib64/libc.so.6 
#4 0x0000003f27a4449e in vfprintf() from /lib64/libc.so.6 
#5 0x0000003f27a4f03a in printf() from /lib64/libc.so.6 
...out process's stack...

而且strace的作为shelter suggested也好像它会做的伎俩......

$ strace -p 27689 
Process 27689 attached - interrupt to quit 
write(1, "some_text"..., 293

来源

2013-01-21 03:57:26

所以这是答案？或更多的证据供人们使用？：-）祝你好运。 – shellter

从我的角度来看，我认为我已经证实了我的理论（当两天的等待期结束时我会接受这个答案），除非有人提供了更完整/彻底的答案:) –

如何检查的过程充满了stdout或stderr缓冲

回答

相关问题