Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

podman with healthcheck fills journal with error #454

Open
HerrFrutti opened this issue Sep 8, 2023 · 13 comments
Open

podman with healthcheck fills journal with error #454

HerrFrutti opened this issue Sep 8, 2023 · 13 comments

Comments

@HerrFrutti
Copy link

problem

My containers are healthy but my journal gets filled with error messages. The error seems to be related with healthchecks.

workaround

For now I disabled all healthchecks and the error disappeared.

logs

example line from my journal:

conmon[11328]: conmon 62de48d99d5858ab629f <error>: Unable to send container stderr message to parent Broken pipe

266649948-aee6269b-69e2-4ec6-846c-6f215ba270eb

additional info

conmon version 2.1.7
podman version 4.6.1
podman-compose version 1.0.6
OS: Fedora release 37 (Thirty Seven)

I'm using podman-compose to deploy my containers.

@mufeedali
Copy link

Any known workarounds for this other than just disabling the health checks?

@hdonnay
Copy link

hdonnay commented Nov 28, 2023

This is still a problem on Fedora 39

@mufeedali
Copy link

I have a couple of health checks and memory usage for journald is way beyond normal due to this. Until this bug gets fixed, I might have to disable my health checks, which is kind of sad :(

@benblasco
Copy link

benblasco commented Dec 11, 2023

@mufeedali I am experiencing this issue too. How have you been disabling the health checks?

@mufeedali
Copy link

@benblasco by simply removing them from my podman-compose files

@shyzus
Copy link

shyzus commented Dec 12, 2023

@benblasco If you are dealing with images like the gitlab image which provides health checks by default. You can use this option to disable it --health-cmd=none

@stryan
Copy link

stryan commented Dec 20, 2023

I've been noticing this problem on my OpenSUSE Leap 15.5 box. Containers are run through quadlet with podman 4.7.1.

@symysak
Copy link

symysak commented Dec 24, 2023

I am also facing this problem with Ubuntu 22.04 LTS 64-bit.
I am not using podman-compose.

raspberrypi@raspberrypi:~$ podman -v
podman version 4.6.2

@benblasco
Copy link

@benblasco If you are dealing with images like the gitlab image which provides health checks by default. You can use this option to disable it --health-cmd=none

Thanks for sharing this info. I will have to figure out how to do this with quadlet!

@benblasco
Copy link

Going through the documentation it appears as though the healthcmd directive can only be used for container units, and not pod units. Is there a way to override the healthcmd for a pod unit? Am I just reading the documentation incorrectly?

@rhatdan
Copy link
Member

rhatdan commented Jan 6, 2024

I don't think healthcmds effect Pods, they are a container concept. Pod's only have an infra container, which does not use healthcmds. Individual containers within the pod can have healthcmds.

@hdonnay
Copy link

hdonnay commented Jan 8, 2024

I ended up adding the following to my .container file:

[Service]
# The following is for a conmon bug where it emits warnings for expected behavior.
LogFilterPatterns=~Broken pipe

See systemd.exec(1) for more information.
YMMV if your container expects to have Broken pipe in its logging output during normal operation.

@daniarla
Copy link

I'm having the same issue on debian unstable. Hoping for a fix soon!

jnovy added a commit to jnovy/conmon that referenced this issue Dec 6, 2024
Issue containers#454 is likely caused by retryable_error()
not catching all possible retriable errors from
the write(2) syscall.

This PR should be FeeBSD compatible. The only
retriable result in question is ENOBUFS which
might be bound to network latencies. Hope
these are acceptable.

Signed-off-by: Jindrich Novy <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants