k when the
container is ready, without having to inject anything
To be clear, I'm not looking for alternative solutions for my specific
example, I was raising the general architectural issue.
On Fri, 29 Sept 2023 at 12:06, Luca Boccassi
wrote:
> On Fri, 29 Sept 2023 at 12:00, Lewis Ga
Hi systemd team,
I've encountered an issue when running systemd inside a container using
cgroups v2, where if a container exec process is created at the wrong
moment during early startup then systemd will fail to move all processes
into a child cgroup, and therefore fail to enable controllers due
> What's stopping you from mounting a private "named" cgroup v1
> hierarchy to such containers (i.e. no controllers). systemd will then
> use that when taking over and not bother with mounting anything on its
> own, such as a cgroupv2 tree.
We specifically want to be able to make use of cgroup
Boccassi wrote:
> On Wed, 19 Jul 2023 at 11:30, Lewis Gaul wrote:
> >
> > Hi Lennart, all,
> >
> > TL;DR: A container making use of cgroup controllers must use the same
> cgroup version as the host, and in the case of it being a systemd container
> on an arbitrary ho
Hi Lennart, all,
TL;DR: A container making use of cgroup controllers must use the same
cgroup version as the host, and in the case of it being a systemd container
on an arbitrary host then a lack of cgroup v1 support from systemd would
place a cgroup v2 requirement on the host, which is an
somewhere between v239 and v245 for host systemd when the container is
running v245 (also seen with v244 and v249).
Thanks,
Lewis
On Thu, 12 Jan 2023 at 15:31, Lewis Gaul wrote:
> Hey Michal,
>
> Thanks for the reply.
>
> > I'd suggest looking at debug level logs from the ho
ld try telling the
container systemd to run in 'legacy' mode somehow?
Thanks,
Lewis
On Thu, 12 Jan 2023 at 13:12, Michal Koutný wrote:
> Hello.
>
> On Tue, Jan 10, 2023 at 03:28:04PM +0000, Lewis Gaul
> wrote:
> > I can confirm that the container has permissions since executing a
On Tue, 10 Jan 2023 at 15:28, Lewis Gaul wrote:
> I'm aware of the higher level of collaboration between podman and systemd
> compared to docker, hence primarily raising this issue from a podman angle.
>
> In privileged mode all mounts are read-write, so yes the container has
&g
r?
Thanks,
Lewis
On Tue, 10 Jan 2023 at 14:48, Lennart Poettering
wrote:
> On Di, 10.01.23 13:18, Lewis Gaul (lewis.g...@gmail.com) wrote:
>
> > Following 'setenforce 0' I still see the same issue (I was also
> suspecting
> > SELinux!).
> >
> > A few additional data
'cgroupfs' to 'systemd'
Thanks,
Lewis
On Tue, 10 Jan 2023 at 11:12, Lennart Poettering
wrote:
> On Mo, 09.01.23 19:45, Lewis Gaul (lewis.g...@gmail.com) wrote:
>
> > Hi all,
> >
> > I've come across an issue when restarting a systemd container, which I'm
>
Hi all,
I've come across an issue when restarting a systemd container, which I'm
seeing on a CentOS 8.2 VM but not able to reproduce on an Ubuntu 20.04 VM
(both cgroups v1).
The failure looks as follows, hitting the warning condition at
Hi everyone,
[Disclaimer: cross posting from
https://github.com/containers/podman/discussions/14538]
Apologies that this is more of a Linux cgroup question than specific to
systemd, but I was wondering if someone here might be able to enlighten
me...
Two questions:
- Why on cgroups v1 do
t;
> Yes.
Ah ok, that's interesting. So it's not technically possible to always be
able to say "the host's active cgroup version is {1,2}", it would have to
be on a per-controller basis such as "the cgroup memory controller is
enabled on version {1,2}"? In practice is this likely
Hi all,
I've been trying to get a deeper understanding of Linux cgroups and their
use with containers/systemd over the last few months. I have a few
questions, but given the amount of context around the questions I've
written up my understanding in a blog post at
14 matches
Mail list logo
