Is this even a thing?

[skepticoitusInteruptus]

Howdy y'all 👋

Inside around ten days, I've asked a couple (as yet, unanswered) questions of the Podman team; four separate times within two separate issues.

I could infer any number of things from their unresponsiveness so far:

1. I'm just not patient enough I need to be even more patient than I have been
2. The issue tracker is not the appropriate place for asking questions — Q & A is
3. The people I asked only skimmed the comments and missed seeing my questions
4. Like we all are, the Podman team members I asked are super busy with highest-priority commitments and don't have the spare cycles for answering questions
5. The questions I asked probably are so naive and noobyish that answering them probably feels like a waste of time to folk who are old hats at Podman
6. The members I asked the questions, genuinely don't know the answers themselves; easier to not respond at all
7. The members are not comfortable answering the questions for some sensitive commercial or strategic reason or another
8. <…and so forth and so on…>

My favorites out of all the above are numbers 1 and 2. So I'll try my luck here with the wider community.

Context

First, the context of my questions refers to these commands:¹

• Run a Docker container that will drop you into /bin/sh in an Alpine Linux container:

my@host $ docker run -it -m 1024m --memory-max 1024m --privileged skepticoital/system.me:hmmm

• Inside the Docker container,² run a nested Podman container using runc instead of crun:³

/system.me # podman --runtime runc run -it skepticoital/mem_limit:hmmm

/system.me # dmesg | grep -i killed

• If Podman and the container runtime both work as expected, then I would expect to see something like this in stdout:

Allocated = 0 to 1 MB
Allocated = 1 to 2 MB
…
Allocated = 420 to 421 MB
…
Allocated = 933 to 934 MB
<Killed>

Expecting that the outer docker run -m 1024m limit was applied, I'd then expect to find that the out-of-memory killer did the needful; i.e., killed the nested mem_limit process that the nested Podman ran:

…
dmesg | grep -i killed
…
Memory cgroup out of memory: Killed process 42 (mem_limit) total-vm:962004kB…

My questions

1. How unreasonable are the above expectations?
2. Is the use case⁴ that the above commands model, atypical in your opinion?

Muchas Thankyas in advancias 🙏

—

 ¹ _{Executed on a host with a kernel configured for cgroup v2}

 ² _{Has Podman and runc installed; does not use systemd though}

 ³ _{This nested container execs a C proggy that consumes memory up to a hard coded total of 1050 MB}

 ⁴ _{Is Alpine; no systemd; cgroup v2-control of a nested Podman container inside an outer Docker container even a thing?}

[flouthoc]

Hi @skepticoitusInteruptus I think similar issue is already raised here and some context is already here containers/crun#923 do you think this is redundant ? If not lets keep this open.

[skepticoitusInteruptus]

Hey there @flouthoc 👋 Thanks for reaching out.

"...some context is already here containers/crun#923..."

You are correct. The same two questions were asked there. Also, though worded differently, in /containers/podman/issues/14236.

"...do you think this is redundant ?..."

Sorry. No. I don't. Since I haven't got an answer to either of the questions yet.

The fact that I haven't is becoming more intriguing to me than the questions themselves; I gotta say 😕

"...If not lets keep this open..."

Yes. Please. That would be awesome!

Or if you are you able to answer them right now @flouthoc, we could close it sooner instead of later. Up for it?

My questions

1. How unreasonable are the above expectations?
2. Is the use case that the above commands model, atypical in your opinion?

TIA.

[skepticoitusInteruptus]

Hey again, @flouthoc

"...similar issue is already raised..."

BTW, probably a good idea not to conflate the actual bug report with questions whose context happens to be only related to the issue use case described in the bug report.

The difference is subtle. Granted. But there is a difference.

Also, I can tell you are such a chill bro (I've read a few of your past comments on issues and PRs). Your people skills are exceptional! I would love to give you especially the points for answering my questions.

They're not trick questions. One is even a one word Yes | No type deal.

You'd have to admit, @flouthoc. Such hesitancy to answer such straightforward, simple questions would make any reasonable person wonder "What's up with that?"

[TomSweeneyRedHat]

@skepticoitusInteruptus I think the slow response is number 3, 4, and maybe a mix of 6. Certainly not 1 or 5. The past couple of weeks has been a crush for most of the Red Hat Maintainers with a number of fires, plus a number of vacations and PTO time sprinkled into the mix. @flouthoc had one pointer. I think what you're asking is reasonable, but it's not something I've mucked with myself. Hopefully, we'll hear from @rhatdan early next week who's played a lot in this space. HTH.

[skepticoitusInteruptus]

Howdy @TomSweeneyRedHat 👋

Thanks for reaching out!

Turns out my bud @flouthoc had already answered my Q1 in /containers/crun/issues#923. I just hadn't seen his answer yet at that point.

My other good buds @giuseppe and @n1hility chimed in too. Which was awesome! Thanks again fellas 💯

[rhatdan]

@skepticoitusInteruptus have your questions been answered at least in the crun case?

[skepticoitusInteruptus]

"…have your questions been answered at least in the crun case?…"

Howdy @rhatdan 🤠 Thanks for asking!

My Q1 and Q2 above were answered awesomely by @flouthoc and @n1hility respectively. Muchas Thankyas, amigos!

However, as far as an answer to the original question that #923 asks implicitly (i.e., Is this error I'm observing a bug in crun?), I can't say right now whether or not that was ever answered explicitly.

If an answer was implied in one of the guys' comments, then it probably flew over my head since I only skimmed the comments.

So I need to reread, more attentively, all of the different comments from the three guys again at some later point to get a clearer understanding of how (or if) their responses answer, "Is this error I'm observing a bug in crun?" .

What I do understand right now though — having skimmed @flouthoc's and @giuseppe's additional comments — is they recommend I run commands that are significantly different than the very specific commands of the reproducer I shared.

Those would be absolutely awesome answers if #923's question was, "What commands do I need to change?"

The reproducer commands I shared were as specific as they were, because they are the same specific commands my team will ultimately run IRL.

I imagine you and the other guys probably have a question of your own for me: "What makes you think there's a bug in crun?"

I'm sure you all know that runc is the reference implementation of an industry standard for container runtimes.

My observation is that Podman with runc does what my reproducer expects would be done. Podman with crun though, chokes with the error I reported. That suggests, to me at least, that crun might need to be looked at to rule out a bug there.

Of course it might be that I'm barking up the wrong tree and runc is the the one with a bug.

[rhatdan]

If your reproducer works with runc and not with crun, then you should open an issue with crun

[skepticoitusInteruptus]

"…If your reproducer works with runc and not with crun, then you should open an issue with crun…"

Howdy do, @rhatdan 👋

Been there …done that… Bought the … 👕

😀