# No output to stdout/stderr from Docker image after upgrading to v8.15.x **URL:** \ **Category:** Beats\ **Tags:** docker, filebeat\ **Created:** [September 19, 2024, 2:57pm UTC](https://discuss.elastic.co/t/no-output-to-stdout-stderr-from-docker-image-after-upgrading-to-v8-15-x/366805 "2024-09-19T14:57:10Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![brynjar](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/brynjar/32/127491_2.png) [@brynjar](https://discuss.elastic.co/u/brynjar)\ **Post date:** [September 19, 2024, 2:57pm UTC](https://discuss.elastic.co/t/no-output-to-stdout-stderr-from-docker-image-after-upgrading-to-v8-15-x/366805/1 "2024-09-19T14:57:10Z")
Filebeat has a command line option named `--environment` (in `filebeat --help`) or `-environment` (in the [online command reference](https://www.elastic.co/guide/en/beats/filebeat/current/command-line-options.html#global-flags)): > **`-environment`** > For logging purposes, specifies the environment that Filebeat is running in. This setting is used to select a default log output when no log output is configured. Supported values are: `systemd`, `container`, `macos_service`, and `windows_service`. If `systemd` or `container` is specified, Filebeat will log to stdout and stderr by default. The official Dockerimage automatically runs filebeat with `-environment container` (through `CMD ["-environment" "container"]`) to enable output to stdout/stderr, and up until v8.14.3 this has worked flawlessly. After upgrading to v8.15.0 or v8.15.1, this configuration option seems to no longer have any effect, and filebeat no longer prints any information at all unless `-e` is specified in addition. This can be reproduced by running the official Docker images and comparing v8.14.3 with v8.15.1: ```auto $ docker run docker.elastic.co/beats/filebeat:8.15.1 filebeat version filebeat version 8.15.1 (amd64), libbeat 8.15.1 [88cc526a2d3e52dcbfa52c9dd25eb09ed95470e4 built 2024-09-02 08:36:21 +0000 UTC] ``` Version 8.15.1 never prints anything at all, but instead writes logs to `logs/filebeat-.ndjson` inside the Docker container: ```auto $ time timeout 10 docker run docker.elastic.co/beats/filebeat:8.15.1 real 0m11.101s user 0m0.010s sys 0m0.005s ``` In v8.14.3 usually ~36 log lines will be printed to stderr in the same amount of time: ```auto $ docker run docker.elastic.co/beats/filebeat:8.14.3 filebeat version filebeat version 8.14.3 (amd64), libbeat 8.14.3 [71819961045386b23edc18455f1b54764292816c built 2024-07-08 22:05:44 +0000 UTC] ``` ```auto $ time timeout 10 docker run docker.elastic.co/beats/filebeat:8.14.3 {"log.level":"info","@timestamp":"2024-09-19T14:30:35.160Z","log.origin":"",service.name":"filebeat","ecs.version":"1.6.0"} {"log.level":"info","@timestamp":"2024-09-19T14:30:45.000Z","log.origin":"","message":"filebeat stopped.","service.name":"filebeat","ecs.version":"1.6.0"} real 0m10.087s user 0m0.007s sys 0m0.009s ``` It looks like running the Docker image with `filebeat -e` in addition to any other flags is a possible workaround, but the `-environment`/`--environment` seems to be broken at the moment. This causes issues for anyone running filebeat in Kubernetes or similar environments, especially for anyone using these logs for monitoring, debugging or auditing purposes. (As a side note and a possible caution to anyone reading this, there's a [known issue with connection failure recovery affecting all beats in v8.15.1](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-8.15.1.html#_known_issues), but the problem with `-environment`/`--environment` is present in both 8.15.0 and 8.15.1) ---
**Author:** ![strawgate](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/strawgate/32/131008_2.png) [@strawgate](https://discuss.elastic.co/u/strawgate)\ **Post date:** [October 4, 2024, 2:23am UTC](https://discuss.elastic.co/t/no-output-to-stdout-stderr-from-docker-image-after-upgrading-to-v8-15-x/366805/2 "2024-10-04T02:23:01Z")
Thanks for reporting this, I'm able to reproduce this and am investigating. If I do not reply in the next day or so please post an issue in the beats repository here [GitHub · Where software is built](https://github.com/elastic/beats/issues) ---
**Author:** ![strawgate](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/strawgate/32/131008_2.png) [@strawgate](https://discuss.elastic.co/u/strawgate)\ **Post date:** [October 4, 2024, 2:55pm UTC](https://discuss.elastic.co/t/no-output-to-stdout-stderr-from-docker-image-after-upgrading-to-v8-15-x/366805/3 "2024-10-04T14:55:49Z")
Issue created here: > > > For confirmed bugs, please report: > \- Version: 8.15.0 and later versions > \- Operat…ing System: All > \- Discuss Forum URL: https://discuss.elastic.co/t/no-output-to-stdout-stderr-from-docker-image-after-upgrading-to-v8-15-x/ > \- Steps to Reproduce: Run any beat (Filebeat as an exmaple) in a container or with \`-environment container\` > > Reproducing with Docker: > \`\`\` > docker run --rm docker.elastic.co/beats/filebeat:8.14.3 > \`\`\` > Will log to stderr > > \`\`\` > docker run --rm docker.elastic.co/beats/filebeat:8.15.2 > \`\`\` > Will produce no logs on stderr > > \## Workaround > Pass the \`-e\` flag when running the Beat or add \`logging.to\_stderr: true\` to your configuration file. ---
**Author:** ![brynjar](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/brynjar/32/127491_2.png) [@brynjar](https://discuss.elastic.co/u/brynjar)\ **Post date:** [October 7, 2024, 3:54pm UTC](https://discuss.elastic.co/t/no-output-to-stdout-stderr-from-docker-image-after-upgrading-to-v8-15-x/366805/4 "2024-10-07T15:54:44Z")
Thanks for confirming and reporting back with the issue number - much appreciated! For anyone else who might be following this, seems like a fix is already on its way in [logp: don't write to files by default if running in a container environment by mauri870 · Pull Request #236 · elastic/elastic-agent-libs · GitHub](https://github.com/elastic/elastic-agent-libs/pull/236)