blocks|key|1347401|text|作为一个快速的解决方法，尝试如下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1347402|from+__future__+import+print_function
#+some+code
print("App+started",+file=sys.stderr)|code-block|syntax|javascript|1347403|当我遇到同样的问题时，这对我来说是可行的。但是，老实说，我不知道为什么会发生这种错误。|1347404|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

As a quick fix, try this:

<pre><code>from __future__ import print_function
# some code
print("App started", file=sys.stderr)
</code></pre>

This works for me when I encounter the same problems. But, to be honest, I don't know why does this error happen.

blocks|key|2646412|text|最后，我找到了一个在Docker中运行守护进程时查看Python输出的解决方案，这要感谢GitHub上的@ahmetalpbalkan。本人在此作答，以供进一步参考：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2646413|使用未缓冲的输出|2646414|CMD+["python","-u","main.py"]|code-block|syntax|javascript|2646415|而不是|2646416|CMD+["python","main.py"]|2646417|解决问题；您可以通过以下方式看到输出(包括stderr和stdout)|2646418|docker+logs+myapp|2646419|现在!|2646420|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/docker/docker/issues/12447#issuecomment-94417192^0|18|6|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@$A|13|B|14|1|15]]|C|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|17|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|C|$]]|$1|M|3|N|5|H|7|19|8|@]|9|@]|C|$I|J]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|C|$]]|$1|Q|3|R|5|H|7|1B|8|@]|9|@]|C|$I|J]]|$1|S|3|T|5|6|7|1C|8|@]|9|@]|C|$]]|$1|U|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]]|V|$W|$5|X|Y|Z|C|$10|11]]]]

Finally I found a solution to see Python output when running daemonized in Docker, thanks to @ahmetalpbalkan over at <a href="https://github.com/docker/docker/issues/12447#issuecomment-94417192">GitHub</a>. Answering it here myself for further reference :

Using unbuffered output with

<pre><code>CMD ["python","-u","main.py"]
</code></pre>

instead of 

<pre><code>CMD ["python","main.py"]
</code></pre>

solves the problem; you can see the output (both, stderr and stdout) via

<pre><code>docker logs myapp
</code></pre>

now!

blocks|key|302090|text|在我的例子中，使用-u运行Python并没有改变任何事情。然而，诀窍是将PYTHONUNBUFFERED=1设置为环境变量：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|302091|docker+run+--name=myapp+-e+PYTHONUNBUFFERED=1+-d+myappimage|code-block|syntax|javascript|302092|编辑:在Lars的评论之后，将PYTHONUNBUFFERED=0更新为PYTHONUNBUFFERED=1。这不会改变行为，也不会增加清晰度。|302093|entityMap^0|9|2|10|I|0|0|F|I|10|I|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|M|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|N|$]]

In my case, running Python with <code>-u</code> didn't change anything. What did the trick, however, was to set <code>PYTHONUNBUFFERED=1</code> as environment variable:
<pre><code>docker run --name=myapp -e PYTHONUNBUFFERED=1 -d myappimage
</code></pre>
[Edit]: Updated <code>PYTHONUNBUFFERED=0</code> to <code>PYTHONUNBUFFERED=1</code> after Lars's comment. This doesn't change the behavior and adds clarity.

blocks|key|1347526|text|请参阅这篇文章，它解释了行为的详细原因：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1347527|通常有三种缓冲模式：|blockquote|1347528|如果文件描述符未被缓冲，则不会发生任何缓冲，并且会立即发生读取或写入数据的函数调用(并将阻止)。|unordered-list-item|1347529|如果一个文件描述符是完全缓冲的，那么使用一个固定大小的缓冲区，并且读或写调用简单地从缓冲区读或写。直到缓冲区满了，缓冲区才会被冲洗。|1347530|如果文件描述符是行缓冲的，则缓冲区等待直到它看到换行符。因此，数据将缓冲和缓冲，直到看到\n，然后所有缓冲的数据在那个时间点被刷新。实际上，缓冲区上通常有一个最大大小(就像在完全缓冲的情况下一样)，因此这个规则实际上更像是“缓冲区，直到看到换行符或遇到4096字节的数据，以先发生者为准”。|1347531|GNU+libc+(glibc)使用以下规则进行缓冲：|1347532|Stream+++++++++++++++Type++++++++++Behavior
stdin++++++++++++++++input+++++++++line-buffered
stdout+(TTY)+++++++++output++++++++line-buffered
stdout+(not+a+TTY)+++output++++++++fully-buffered
stderr+++++++++++++++output++++++++unbuffered|code-block|syntax|javascript|1347533|因此，如果使用-t，在码头文件中，它将分配一个伪tty，然后stdout变成line-buffered，因此docker+run+--name=myapp+-it+myappimage可以看到一行输出。|style|CODE|1347534|而且，如果只使用-d，则没有分配tty，那么，stdout是fully-buffered，一行App+started肯定无法刷新缓冲区。|1347535|然后，使用-dt到make+stdout+line+buffered或者在python中添加-u到flush+the+buffer是修复它的方法。|1347536|entityMap|0|LINK|mutability|MUTABLE|url|https://eklitzke.org/stdout-buffering|1|https://docs.docker.com/engine/reference/run/#foreground^0|3|4|0|0|0|0|0|0|0|0|7|2|U|6|12|D|1I|12|B|4|1|0|8|2|N|6|U|E|1B|B|0|5|3|9|P|1A|2|1D|G|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@$A|1D|B|1E|1|1F]]|C|$]]|$1|D|3|E|5|F|7|1G|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|1H|8|@]|9|@]|C|$]]|$1|J|3|K|5|I|7|1I|8|@]|9|@]|C|$]]|$1|L|3|M|5|I|7|1J|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|1K|8|@]|9|@]|C|$]]|$1|P|3|Q|5|R|7|1L|8|@]|9|@]|C|$S|T]]|$1|U|3|V|5|6|7|1M|8|@$A|1N|B|1O|W|X]|$A|1P|B|1Q|W|X]|$A|1R|B|1S|W|X]|$A|1T|B|1U|W|X]]|9|@$A|1V|B|1W|1|1X]]|C|$]]|$1|Y|3|Z|5|6|7|1Y|8|@$A|1Z|B|20|W|X]|$A|21|B|22|W|X]|$A|23|B|24|W|X]|$A|25|B|26|W|X]]|9|@]|C|$]]|$1|10|3|11|5|6|7|27|8|@$A|28|B|29|W|X]|$A|2A|B|2B|W|X]|$A|2C|B|2D|W|X]|$A|2E|B|2F|W|X]]|9|@]|C|$]]|$1|12|3|-4|5|6|7|2G|8|@]|9|@]|C|$]]]|13|$14|$5|15|16|17|C|$18|19]]|1A|$5|15|16|17|C|$18|1B]]]]

See <a href="https://eklitzke.org/stdout-buffering" rel="noreferrer">this article</a> which explain detail reason for the behavior:

<blockquote>
 There are typically three modes for buffering:
 
 <ul>
 <li>If a file descriptor is unbuffered then no buffering occurs whatsoever, and function calls that read or write data occur immediately (and will block).</li>
 <li>If a file descriptor is fully-buffered then a fixed-size buffer is used, and read or write calls simply read or write from the buffer. The buffer isn’t flushed until it fills up.</li>
 <li>If a file descriptor is line-buffered then the buffering waits until it sees a newline character. So data will buffer and buffer until a \n is seen, and then all of the data that buffered is flushed at that point in time. In reality there’s typically a maximum size on the buffer (just as in the fully-buffered case), so the rule is actually more like “buffer until a newline character is seen or 4096 bytes of data are encountered, whichever occurs first”.</li>
 </ul>
</blockquote>

And GNU libc (glibc) uses the following rules for buffering:

<pre><code>Stream Type Behavior
stdin input line-buffered
stdout (TTY) output line-buffered
stdout (not a TTY) output fully-buffered
stderr output unbuffered
</code></pre>

So, if use <code>-t</code>, from <a href="https://docs.docker.com/engine/reference/run/#foreground" rel="noreferrer">docker document</a>, it will allocate a pseudo-tty, then <code>stdout</code> becomes <code>line-buffered</code>, thus <code>docker run --name=myapp -it myappimage</code> could see the one-line output.

And, if just use <code>-d</code>, no tty was allocated, then, <code>stdout</code> is <code>fully-buffered</code>, one line <code>App started</code> surely not able to flush the buffer.

Then, use <code>-dt</code> to <code>make stdout line buffered</code> or add <code>-u</code> in python to <code>flush the buffer</code> is the way to fix it.

blocks|key|2646477|text|如果将print更改为logging，则可以在独立图像上看到日志。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2646478|main.py：|2646479|import+time
import+logging
print+"App+started"
logging.warning("Log+app+started")
while+True:
++++time.sleep(1)|code-block|syntax|javascript|2646480|Dockerfile：|2646481|FROM+python:2.7-stretch
ADD+.+/app
WORKDIR+/app
CMD+["python","main.py"]|2646482|entityMap^0|3|5|B|7|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|Y|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|Z|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|10|8|@]|D|@]|E|$K|L]]|$1|Q|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|R|$]]

You can see logs on detached image if you change <code>print</code> to <code>logging</code>.

main.py:

<pre><code>import time
import logging
print "App started"
logging.warning("Log app started")
while True:
 time.sleep(1)
</code></pre>

Dockerfile:

<pre><code>FROM python:2.7-stretch
ADD . /app
WORKDIR /app
CMD ["python","main.py"]
</code></pre>

blocks|key|302242|text|通常，我们将其重定向到特定的文件(通过从主机挂载卷并将其写入该文件)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|302243|使用-t添加tty也可以。你得把它放在码头日志里。|302244|使用大型日志输出，在没有将其放入dockers日志的情况下，缓冲区存储没有任何问题。|302245|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Usually, we redirect it to a specific file (by mounting a volume from host and writing it to that file).

Adding a tty using -t is also fine. You need to pick it up in docker logs. 

Using large log outputs, I did not have any issue with buffer storing all without putting it in dockers log.

blocks|key|1347598|text|因为我还没看到这个答案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1347599|您还可以在打印到它之后刷新标准输出：|1347600|import+time

if+__name__+==+'__main__':
++++while+True:
++++++++print('cleaner+is+up',+flush=True)
++++++++time.sleep(5)|code-block|syntax|javascript|1347601|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Since I haven't seen this answer yet:

You can also flush stdout after you print to it:

<pre><code>import time

if __name__ == '__main__':
 while True:
 print('cleaner is up', flush=True)
 time.sleep(5)
</code></pre>

blocks|key|2646540|text|我必须在我的docker-come.yml文件中使用PYTHONUNBUFFERED=1来查看django+runserver的输出。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2646541|entityMap^0|Q|I|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

I had to use <code>PYTHONUNBUFFERED=1</code> in my docker-compose.yml file to see the output from django runserver.

blocks|key|2646573|text|如果您希望在运行docker-compose+up时将打印输出添加到您的酒瓶输出中，请将以下内容添加到您的停靠器撰写文件中。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2646574|web:
++environment:
++++-+PYTHONUNBUFFERED=1|code-block|syntax|javascript|2646575|https://docs.docker.com/compose/environment-variables/|2646576|entityMap|0|LINK|mutability|MUTABLE|url^0|8|H|0|0|0|1I|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|W|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|X|8|@]|D|@$9|Y|A|Z|1|10]]|E|$]]|$1|M|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|N|$O|$5|P|Q|R|E|$S|L]]]]

If you want to add your print output to your Flask output when running <code>docker-compose up</code>, add the following to your docker compose file.

<pre><code>web:
 environment:
 - PYTHONUNBUFFERED=1
</code></pre>

<a href="https://docs.docker.com/compose/environment-variables/" rel="noreferrer">https://docs.docker.com/compose/environment-variables/</a>

blocks|key|2646587|text|尝试将这两个环境变量添加到解决方案PYTHONUNBUFFERED=1和PYTHONIOENCODING=UTF-8中|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2646588|entityMap^0|H|I|10|M|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

Try to add these two environment variables to your solution <code>PYTHONUNBUFFERED=1</code> and <code>PYTHONIOENCODING=UTF-8</code>

blocks|key|302391|text|如果您不使用docker-compose，而只使用普通的docker，则可以将其添加到承载瓶应用程序的Dockerfile中。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|302392|ARG+FLASK_ENV="production"
ENV+FLASK_ENV="${FLASK_ENV}"+\
++++PYTHONUNBUFFERED="true"

CMD+[+"flask",+"run"+]|code-block|syntax|javascript|302393|entityMap^0|6|E|S|6|1F|A|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|U|8|@]|D|@]|E|$]]]|L|$]]

If you aren't using <code>docker-compose</code> and just normal <code>docker</code> instead, you can add this to your <code>Dockerfile</code> that is hosting a flask app

<pre><code>ARG FLASK_ENV="production"
ENV FLASK_ENV="${FLASK_ENV}" \
 PYTHONUNBUFFERED="true"

CMD [ "flask", "run" ]
</code></pre>

blocks|key|302398|text|在Django应用程序中使用python+manage.py+runserver时，添加环境变量PYTHONUNBUFFERED=1可以解决我的问题。print('helloworld',+flush=True)也为我工作。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|302399|然而，python+-u不适合我。|302400|entityMap^0|E|Q|1C|I|23|V|0|3|9|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|I|$]]

When using <code>python manage.py runserver</code> for a Django application, adding environment variable <code>PYTHONUNBUFFERED=1</code> solve my problem. <code>print('helloworld', flush=True)</code> also works for me.
However, <code>python -u</code> doesn't work for me.

blocks|key|302433|text|如果有人正在使用conda运行python应用程序，那么您应该将--no-capture-output添加到命令中，因为默认情况下，conda缓冲区为stdout。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|302434|ENTRYPOINT+["conda",+"run",+"--no-capture-output",+"-n",+"my-app",+"python",+"main.py"]|code-block|syntax|javascript|302435|entityMap^0|W|J|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

If anybody is running the python application with conda you should add <code>--no-capture-output</code> to the command since conda buffers to stdout by default.
<pre><code>ENTRYPOINT [&quot;conda&quot;, &quot;run&quot;, &quot;--no-capture-output&quot;, &quot;-n&quot;, &quot;my-app&quot;, &quot;python&quot;, &quot;main.py&quot;]
</code></pre>

I have a Python (2.7) app which is started in my dockerfile:

<pre><code>CMD ["python","main.py"]
</code></pre>

main.py prints some strings when it is started and goes into a loop afterwards:

<pre><code>print "App started"
while True:
 time.sleep(1)
</code></pre>

As long as I start the container with the -it flag, everything works as expected:

<pre><code>$ docker run --name=myapp -it myappimage
&gt; App started
</code></pre>

And I can see the same output via logs later:

<pre><code>$ docker logs myapp
&gt; App started
</code></pre>

If I try to run the same container with the -d flag, the container seems to start normally, but I can't see any output:

<pre><code>$ docker run --name=myapp -d myappimage
&gt; b82db1120fee5f92c80000f30f6bdc84e068bafa32738ab7adb47e641b19b4d1
$ docker logs myapp
$ (empty)
</code></pre>

But the container still seems to run;

<pre><code>$ docker ps
Container Status ...
myapp up 4 minutes ... 
</code></pre>

Attach does not display anything either:

<pre><code>$ docker attach --sig-proxy=false myapp
(working, no output)
</code></pre>

Any ideas whats going wrong? Does "print" behave differently when ran in background?

Docker version:

<pre><code>Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.4.2
Git commit (client): a8a31ef
OS/Arch (client): linux/arm
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.4.2
Git commit (server): a8a31ef
</code></pre>

Python app does not print anything when running detached in docker

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

我有一个Python (2.7)应用程序，它在我的dockerfile中启动：CMD ["python","main.py"]main.py在启动时打印一些字符串，然后进入循环：print "App started"while True:    time.sleep(1)只要我使用-it标志启动容器，一切就会如愿以偿：...

问Python应用程序在docker中运行时不会打印任何内容。
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Python应用程序在docker中运行时不会打印任何内容。EN