blocks|key|2403949|text|这是一个标准的linux进程，是专门安装的第三方包还是自定义编写的代码？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2403950|标准linux进程应该没有这样的问题，而自定义代码是最有可能的罪魁祸首。调试这种情况的最简单方法是添加特殊的调试代码。|2403951|否则，请查看您的std实用程序或第三方软件包是否具有冗余模式，通常是-v,+or+-vv,+or+-vvv。|offset|length|style|CODE|2403952|最后，您可以使用您的操作系统的truss+(for+solaris)版本，对于某些strace版本，您可以查看它挂在哪里。|2403953|IHTH|2403954|entityMap^0|0|0|Y|J|0|F|J|15|6|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@$F|S|G|T|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@$F|V|G|W|H|I]|$F|X|G|Y|H|I]]|9|@]|A|$]]|$1|L|3|M|5|6|7|Z|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|O|$]]

Is this a std linux process, a specially installed 3rd party package or custom written code ? 

Std linux processes should have no such issues, while custom code is the most likely culprit. The easiest way to debug that situation is to add special debugging code. 

Else, look to see if your std utility or 3rd-party package has a verbose mode, often <code>-v, or -vv, or -vvv</code>. 

Finally you can use your OS's version of <code>truss (for solaris)</code> , <code>strace</code> for some Linux versions, to see where it is hanging. 

IHTH

blocks|key|1200934|text|关于你的另一种理论，看看SO。我发现this很有趣，我希望这里的一些东西是有用的。干杯|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1200935|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/10803122/how-can-i-check-if-a-cli-program-is-waiting-for-input-from-stdin|1|http://www.pixelbeat.org/programming/stdio_buffering/^0|C|2|0|I|4|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

Regarding your alternate theory, have a look at <a href="https://stackoverflow.com/questions/10803122/how-can-i-check-if-a-cli-program-is-waiting-for-input-from-stdin">SO</a>. I found <a href="http://www.pixelbeat.org/programming/stdio_buffering/" rel="nofollow noreferrer">this</a> interesting, I hope something here is useful. CHEERS

blocks|key|1200937|text|附加gdb和运行回溯几乎证实了我的理论……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1200938|$+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...|code-block|syntax|javascript|1200939|而像shelter+suggested这样的策略似乎也能做到这一点。|offset|length|1200940|$+strace+-p+27689
Process+27689+attached+-+interrupt+to+quit
write(1,+"some_text"...,+293|1200941|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/14432284/797^0|0|0|2|H|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@$I|X|J|Y|1|Z]]|A|$]]|$1|K|3|L|5|D|7|10|8|@]|9|@]|A|$E|F]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

Attaching gdb and running backtrace pretty much confirms my theory...

<pre><code>$ 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...
</code></pre>

And strace as <a href="https://stackoverflow.com/a/14432284/797">shelter suggested</a> also seems like it would do the trick...

<pre><code>$ strace -p 27689
Process 27689 attached - interrupt to quit
write(1, "some_text"..., 293
</code></pre>

Given a process on a Linux machine which appears to be stuck, how can I tell if it is stuck due to the STDOUT or STDERR buffer being full?

In my particular case, I have a process which is performing no CPU activity, but remains running when I would expect it to have exited within a few seconds. My suspicion is that the process has filled up the buffer for STDOUT or STDERR and the process which is supposed to be reading from that the buffer has stopped doing so for some reason.

Is there any way I can confirm this suspicion?

How to check if a process has filled the STDOUT or STDERR buffer

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

假设Linux机器上的一个进程似乎卡住了，我如何判断它是否由于STDOUT或STDERR缓冲区已满而卡住？在我的特殊情况下，我有一个没有执行CPU活动的进程，但当我期望它在几秒钟内退出时，它仍然在运行。我怀疑该进程已经填满了STDOUT或STDERR的缓冲区，而本应从该缓冲区读取数据的进程由于某种原因而停止了读取。我有...

问如何检查进程是否已填充STDOUT或STDERR缓冲区
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何检查进程是否已填充STDOUT或STDERR缓冲区EN