Replies: 11 comments 9 replies
-
The main problem is that without logs |
Beta Was this translation helpful? Give feedback.
-
Whoops, seems I misunderstood that. You're right, it says so in the docs as well. I have updated the issue description.
That's an interesting point, I wasn't aware of that. |
Beta Was this translation helpful? Give feedback.
-
How is the log driver in podman implemented? I.e. when I run a container interactively and then detach it via |
Beta Was this translation helpful? Give feedback.
-
That's still a breaking change. The expectation is that If we're seeing issues with journal performance, we can look into fixes for that (or, potentially, improve the file driver to make it a more viable alternative). Disabling logging should not be the solution. |
Beta Was this translation helpful? Give feedback.
-
Is there really an application for this? Do people have use cases where they run containers interactively and still resort to Can I at least change the default behavior on my machine? I see that the man page for
Is this an oversight? Also that doesn't really solve the problem: If I change the default to Would it maybe be possible to add a new "dynamic" log driver, but not use it as default then? |
Beta Was this translation helpful? Give feedback.
-
Yes, Again, a dynamic driver sounds like a hack around bad behavior; let's just fix the existing drivers to behave sanely. |
Beta Was this translation helpful? Give feedback.
-
Thanks for clarifying. Where can I file a PR to add this to the manpage/config file?
I was arguing more out of a user-friendliness perspective. Opening your
I agree with that, see the issue I raised against systemd. I was just thinking maybe it'd be worthwhile discussing this proposal here not as a workaround but maybe a new default behavior. You have made it clear, however, that from your point of view this is very unlikely to happen. I'll leave this open in case someone else wants to state their opinions on this. Us two arguing isn't really representative of the broader podman user base I guess. Feel free to close this issue if you see no point in further discussing it. |
Beta Was this translation helpful? Give feedback.
-
Converting to a discussion. |
Beta Was this translation helpful? Give feedback.
-
@mheon what do you think about adding a flag --log-opt detached-nolog |
Beta Was this translation helpful? Give feedback.
-
Hello, I've read through the discussion and am quite confused on the outcomes. So, @har7an points out that running a We are using Podman in CI, and needless to say I was very surprised to see that every build with thousands of lines gets written to our journal for no reason. @rhatdan then converted the issue to discussion, for reasons to me unclear. Then later discussion went on discussing systemd nuances, which I don't see how is relevant to the problem regarding the bad defaults. So, what about the original problem? While on it, should perhaps this be converted back to an issue? |
Beta Was this translation helpful? Give feedback.
-
Changing the default just so is not an option as it must be considered a breaking change, it is a long standing behavior so it is possible that there are users relying on it. Sure it may not be what you expect but that does not mean that all users think the same. I agree with your overall points but having different behaviors for logging when attched/detached also requires extra documentation and can be confusing as we now have two different logging defaults that depend on another option (--detach). So something like using --log-driver none as default and --log-driver journald when running with detach is possible but not straight forward either, the user can overwrite the default with --log-driver but now what is about the Attached/Detached is not so clear defined as well, users can attach any time via So are you willing to do that work? Write a proper design on how to implement this and get approval for the majority of the maintainers, you can attend over Community Cabal meetings to talk to us if you like to discus such things. Of course written form here on github also works. The fact is that it is a old default (I think docker does the same) and apart from the few voices here it doesn't seem to cause issues for most users I would assume so it was never really something we considered. |
Beta Was this translation helpful? Give feedback.
-
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature
Description
When running heavy container workloads, especially tools that produce a lot of output on
stdout
, the system can freeze entirely. I noticed this first when running bees from a container, I have meanwhile reported it to systemd since I assume it is a bug there: systemd/systemd#23804This seems to happen when the journal grows beyond a certain size (?). The freeze comes creeping, but once I realize it is happening I cannot do anything against it any longer.
I propose that the
--log-driver
setting is automatically set tonone
(from the defaultjournald
) when a container isrun
with thewithout the-i/--interactive
-d/--detach
CLI argument. The rationale for this is that any containerrunning interactivelynot running detached will most likely run in the foreground (unless being sent to the background viaCtrl+P, Ctrl+Q
), hence there is no need to preserve all of its output in the system journal. I don't expectbash
to pipe a recording of all my terminal sessions to the journal either.Steps to reproduce the issue:
Let it run for a while. You can get a copy of the whole output when calling
journalctl -f
in another terminal.Describe the results you received:
The system freezes after about 95 minutes. On the next boot I find that my journal is multiple gigabytes in size and contains many million lines of text.
Describe the results you expected:
The system operates as usual. The output of the container commands isn't piped to the journal.
Additional information you deem important (e.g. issue happens only occasionally):
On my system the issue is reproducible very reliably. It first occured about 3 weeks ago when I started experimenting with bees. Yesterday it happened again after running a lot of interactive containers to replace CLI tools I use infrequently.
Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Additional environment details (AWS, VirtualBox, physical, etc.):
Host is a Fedora 36 Silverblue (Version 36.20220617.0)
Beta Was this translation helpful? Give feedback.
All reactions