Hey folks,
I've upgraded this system to buster and it seems that either the new
kernel (4.19.0-8-amd64) or new lxc version (1:3.1.0+really3.0.3-8) has
fixed this problem: I can now again re-exec systemd in containers even
with lxc.cap.drop = sys_admin enabled.
I guess this issue could be closed?
Control: reassign -1 lxc
On Wed, 16 Jan 2019 09:52:47 +0100 Matthijs Kooijman
wrote:
> severity 919259 normal
> found 919259 232-25
> retitle 919259 Reexecuting fails in containers without CAP_SYS_ADMIN
> thanks
>
> Hey Michael,
>
> > My suggestion would be to roll back to 232-25+deb9u1 and
severity 919259 normal
found 919259 232-25
retitle 919259 Reexecuting fails in containers without CAP_SYS_ADMIN
thanks
Hey Michael,
> My suggestion would be to roll back to 232-25+deb9u1 and then gradually
> upgrading to deb9u2, deb9u2 ... deb9u3
Yeah, that was my intention. I discovered some
Am 14.01.19 um 08:22 schrieb matthijs:
> I looked through the changelog from deb9u1 to deb9u7, and nothing springs out
> as an obvious cause. Only the last update was a security update (relating to
> the journal only), so this might be caused by one of the previous non-security
> updates as well
Package: systemd
Version: 232-25+deb9u7
Severity: important
Hi folks,
this morning, some lxc containers on my machine did an unattended upgrade from
systemd 232-25+deb9u1 to version 232-25+deb9u7. As part of that upgrade,
systemd was reexecuted, which resulted in systemd freezing:
systemd[1]:
5 matches
Mail list logo
