Bug#961584: [pkg-lxc-devel] Bug#961584: Bug#961584: lxc-stop fails with exit code 1
Hi, On Wed, Sep 16, 2020 at 11:14:58PM +0200, Pierre-Elliott Bécue wrote: > Le mercredi 16 septembre 2020 à 22:08:24+0200, Pierre-Elliott Bécue a écrit : > > Le vendredi 11 septembre 2020 à 11:12:25+0200, Iñaki Malerba a écrit : > > > Hi Pebs, > > > > > > Thanks for checking this. > > > > > > On Sat, 5 Sep 2020 23:23:30 +0200 Pierre-Elliott =?utf-8?B?QsOpY3Vl?= > > > wrote:> > > > > LXC's devs told me that 4.0.4 should solve it. I'm uploading this > > > > release now. Please don't hesitate to tell me if it helps. > > > > > > Run a pipeline removing the pinning of lxc, and the behaviour seems to > > > be the same. > > > > > > Image building: > > > https://salsa.debian.org/ina/pipeline/-/jobs/990332 > > > > Setting up lxc (1:4.0.4-1) .. > > > > > > Running lxc: > > > https://salsa.debian.org/ina/pipeline/-/jobs/990352 > > > > : failure: ['sudo', 'timeout', '600', 'lxc-stop', > > > '--quiet', '--kill', '--name', 'ci-254-b2fcad5f'] failed (exit status 1, > > > stderr '') > > > > > > Please let me know if you want us to test something else. > > > > > > Abrazos, > > > > Could you get me a full trace like the previous time? I have no > > technical means of running proper tests currently, sorry. :/ > > > > Cheers! > > I found a way to run tests on my own. > > Turns out I tried to add a lxc-attach autopkgtest-stable-amd64 -- ps > auxf to see the process tree in case I could find something useful, > and… the container successfully stopped that time. I retried and it kept > working. > > The process tree I see is: > ─( 23:09:35 )─< /home/becue/tmp > >───[ 0 ]─ > root@dawaj # docker run --rm --privileged -i autopkgtest > Starting LXC network bridge: :Starting LXC autoboot containers: :USER > PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > root 4 0.0 0.0 7644 2760 ?R21:09 0:00 ps auxf > root 1 0.0 0.0 20904 7492 ?Ds 21:09 0:00 /sbin/init > ok > > After some more tests, it seems that lxc-start && lxc-stop isn't working > properly because the signal is sent before the container is ready to > handle it. > > After this test I decided to add a sleep 2 before the lxc-attach ... -- > ps command: > > Starting LXC network bridge: :Starting LXC autoboot containers: :USER > PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > root 52 0.0 0.0 7644 2768 ?R21:10 0:00 ps auxf > root 1 2.5 0.1 21524 9596 ?Ss 21:10 0:00 /sbin/init > root 17 0.5 0.1 27444 8404 ?Ss 21:10 0:00 > /lib/systemd/systemd-journald > root 27 0.0 0.0 2348 1772 ?Ss 21:10 0:00 /sbin/ifup > -a --read-environment > root 42 0.0 0.0 2392 764 ?S21:10 0:00 \_ > /bin/sh -c /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf > /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases > eth0 . > root 43 0.0 0.0 8456 1936 ?S21:10 0:00 \_ > /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf > /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases > eth0 > root 44 0.0 0.0 9492 5644 ?S21:10 0:00 \_ > /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf > /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases > eth0 > message+ 50 0.0 0.0 8696 3636 ?Ss 21:10 0:00 > /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile > --systemd-activation --syslog-only > root 51 0.5 0.0 19308 6376 ?Ss 21:10 0:00 > /lib/systemd/systemd-logind > ok > > Turns out your lxc-stop is really fast, and therefore, not catched > properly by LXC. > > While I appreciate it shouldn't be a corner case that makes things > explode, do you think there's a way to take this realization into > account to lower the severity of this bug, having a temporary fix set up > in place? > > I'll still try to see what upstream could offer to handle this in a > better way. I did a little bit of debugging on this today. I think the provided Dockerfile does not really reproduce the real issue. The lxc-stop call from lxc comes after the tests are run, so plenty of time after the lxc-start call. I installed autopkgtest inside the container, did manually the mount steps listed in the Dockerfile, and tried it directly. Failed as expected: root@665d38b2f9e3:~/pkg# autopkgtest -B . -- lxc autopkgtest-stable-amd64 autopkgtest [12:41:01]: starting date: 2020-09-17 autopkgtest [12:41:01]: version 5.14 autopkgtest [12:41:01]: host 665d38b2f9e3; command line: /usr/bin/autopkgtest -B . -- lxc autopkgtest-stable-amd64 autopkgtest [12:41:07]: testbed dpkg architecture: amd64 autopkgtest [12:41:08]: testbed running kernel: Linux 5.8.0-1-amd64 #1 SMP Debian 5.8.7-1 (2020-09-05) autopkgtest [12:41:08]:
Bug#961584: [pkg-lxc-devel] Bug#961584: Bug#961584: lxc-stop fails with exit code 1
Le mercredi 16 septembre 2020 à 22:08:24+0200, Pierre-Elliott Bécue a écrit : > Le vendredi 11 septembre 2020 à 11:12:25+0200, Iñaki Malerba a écrit : > > Hi Pebs, > > > > Thanks for checking this. > > > > On Sat, 5 Sep 2020 23:23:30 +0200 Pierre-Elliott =?utf-8?B?QsOpY3Vl?= > > wrote:> > > > LXC's devs told me that 4.0.4 should solve it. I'm uploading this > > > release now. Please don't hesitate to tell me if it helps. > > > > Run a pipeline removing the pinning of lxc, and the behaviour seems to > > be the same. > > > > Image building: > > https://salsa.debian.org/ina/pipeline/-/jobs/990332 > > > Setting up lxc (1:4.0.4-1) .. > > > > Running lxc: > > https://salsa.debian.org/ina/pipeline/-/jobs/990352 > > > : failure: ['sudo', 'timeout', '600', 'lxc-stop', > > '--quiet', '--kill', '--name', 'ci-254-b2fcad5f'] failed (exit status 1, > > stderr '') > > > > Please let me know if you want us to test something else. > > > > Abrazos, > > Could you get me a full trace like the previous time? I have no > technical means of running proper tests currently, sorry. :/ > > Cheers! I found a way to run tests on my own. Turns out I tried to add a lxc-attach autopkgtest-stable-amd64 -- ps auxf to see the process tree in case I could find something useful, and… the container successfully stopped that time. I retried and it kept working. The process tree I see is: ─( 23:09:35 )─< /home/becue/tmp >───[ 0 ]─ root@dawaj # docker run --rm --privileged -i autopkgtest Starting LXC network bridge: :Starting LXC autoboot containers: :USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 4 0.0 0.0 7644 2760 ?R21:09 0:00 ps auxf root 1 0.0 0.0 20904 7492 ?Ds 21:09 0:00 /sbin/init ok After some more tests, it seems that lxc-start && lxc-stop isn't working properly because the signal is sent before the container is ready to handle it. After this test I decided to add a sleep 2 before the lxc-attach ... -- ps command: Starting LXC network bridge: :Starting LXC autoboot containers: :USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 52 0.0 0.0 7644 2768 ?R21:10 0:00 ps auxf root 1 2.5 0.1 21524 9596 ?Ss 21:10 0:00 /sbin/init root 17 0.5 0.1 27444 8404 ?Ss 21:10 0:00 /lib/systemd/systemd-journald root 27 0.0 0.0 2348 1772 ?Ss 21:10 0:00 /sbin/ifup -a --read-environment root 42 0.0 0.0 2392 764 ?S21:10 0:00 \_ /bin/sh -c /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0 . root 43 0.0 0.0 8456 1936 ?S21:10 0:00 \_ /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0 root 44 0.0 0.0 9492 5644 ?S21:10 0:00 \_ /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0 message+ 50 0.0 0.0 8696 3636 ?Ss 21:10 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only root 51 0.5 0.0 19308 6376 ?Ss 21:10 0:00 /lib/systemd/systemd-logind ok Turns out your lxc-stop is really fast, and therefore, not catched properly by LXC. While I appreciate it shouldn't be a corner case that makes things explode, do you think there's a way to take this realization into account to lower the severity of this bug, having a temporary fix set up in place? I'll still try to see what upstream could offer to handle this in a better way. Cheers, -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#961584: [pkg-lxc-devel] Bug#961584: lxc-stop fails with exit code 1
Le vendredi 11 septembre 2020 à 11:12:25+0200, Iñaki Malerba a écrit : > Hi Pebs, > > Thanks for checking this. > > On Sat, 5 Sep 2020 23:23:30 +0200 Pierre-Elliott =?utf-8?B?QsOpY3Vl?= > wrote:> > > LXC's devs told me that 4.0.4 should solve it. I'm uploading this > > release now. Please don't hesitate to tell me if it helps. > > Run a pipeline removing the pinning of lxc, and the behaviour seems to > be the same. > > Image building: > https://salsa.debian.org/ina/pipeline/-/jobs/990332 > > Setting up lxc (1:4.0.4-1) .. > > Running lxc: > https://salsa.debian.org/ina/pipeline/-/jobs/990352 > > : failure: ['sudo', 'timeout', '600', 'lxc-stop', > '--quiet', '--kill', '--name', 'ci-254-b2fcad5f'] failed (exit status 1, > stderr '') > > Please let me know if you want us to test something else. > > Abrazos, Could you get me a full trace like the previous time? I have no technical means of running proper tests currently, sorry. :/ Cheers! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#961584: lxc-stop fails with exit code 1
Hi Pebs, Thanks for checking this. On Sat, 5 Sep 2020 23:23:30 +0200 Pierre-Elliott =?utf-8?B?QsOpY3Vl?= wrote:> > LXC's devs told me that 4.0.4 should solve it. I'm uploading this > release now. Please don't hesitate to tell me if it helps. Run a pipeline removing the pinning of lxc, and the behaviour seems to be the same. Image building: https://salsa.debian.org/ina/pipeline/-/jobs/990332 > Setting up lxc (1:4.0.4-1) .. Running lxc: https://salsa.debian.org/ina/pipeline/-/jobs/990352 > : failure: ['sudo', 'timeout', '600', 'lxc-stop', '--quiet', '--kill', '--name', 'ci-254-b2fcad5f'] failed (exit status 1, stderr '') Please let me know if you want us to test something else. Abrazos, > > -- > Pierre-Elliott Bécue > GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 > It's far easier to fight for one's principles than to live up to them. -- - ina signature.asc Description: OpenPGP digital signature
Bug#961584: lxc-stop fails with exit code 1
Le mercredi 03 juin 2020 à 10:57:13+0200, Inaki Malerba a écrit :
> El 2/6/20 a las 20:07, Pierre-Elliott Bécue escribió:
> > Could you remove the --quiet bit to see if lxc-stop gives us a bit more
> > intel?
> >
> > If possible, have your testbed call lxc-stop --kill --logpriority trace
> > --logfile /dev/stdout --name ${NAME}, so we can have the most expressive
> > output. But if it's an error, removing the quiet bit could be enough.
> >
> > Thanks.
> >
>
> The POC I attached on a previous email it's not using debci, so you can
> modify the lxc-stop call.
>
> After enabling trace log level, the output is the following:
>
> > Starting LXC network bridge: :Starting LXC autoboot containers: :
> > lxc-stop autopkgtest-stable-amd64 20200603085059.718 TRACEcommands -
> > commands.c:lxc_cmd_rsp_recv:123 - Command "get_init_pid" received response
> > lxc-stop autopkgtest-stable-amd64 20200603085059.718 DEBUGcommands -
> > commands.c:lxc_cmd_rsp_recv:156 - Response data length for command
> > "get_init_pid" is 0
> > lxc-stop autopkgtest-stable-amd64 20200603085059.718 TRACEcommands -
> > commands.c:lxc_cmd:293 - Opened new command socket connection fd 4 for
> > command "get_init_pid"
> > lxc-stop autopkgtest-stable-amd64 20200603085059.719 TRACEcommands -
> > commands.c:lxc_cmd_rsp_recv:123 - Command "get_state" received response
> > lxc-stop autopkgtest-stable-amd64 20200603085059.719 DEBUGcommands -
> > commands.c:lxc_cmd_rsp_recv:156 - Response data length for command
> > "get_state" is 0
> > lxc-stop autopkgtest-stable-amd64 20200603085059.719 TRACEcommands -
> > commands.c:lxc_cmd:293 - Opened new command socket connection fd 4 for
> > command "get_state"
> > lxc-stop autopkgtest-stable-amd64 20200603085059.719 DEBUGcommands -
> > commands.c:lxc_cmd_get_state:656 - Container "autopkgtest-stable-amd64" is
> > in "RUNNING" state
> > lxc-stop autopkgtest-stable-amd64 20200603085059.719 TRACEcommands -
> > commands.c:lxc_cmd_rsp_recv:123 - Command "stop" received response
> > lxc-stop autopkgtest-stable-amd64 20200603085059.719 DEBUGcommands -
> > commands.c:lxc_cmd_rsp_recv:156 - Response data length for command "stop"
> > is 0
> > lxc-stop autopkgtest-stable-amd64 20200603085059.719 TRACEcommands -
> > commands.c:lxc_cmd:293 - Opened new command socket connection fd 4 for
> > command "stop"
> > lxc-stop autopkgtest-stable-amd64 20200603085059.720 ERRORcommands -
> > commands.c:lxc_cmd_stop:707 - No such file or directory - Failed to stop
> > container "autopkgtest-stable-amd64"
> > lxc-stop: autopkgtest-stable-amd64: commands.c: lxc_cmd_stop: 707 No such
> > file or directory - Failed to stop container "autopkgtest-stable-amd64"
LXC's devs told me that 4.0.4 should solve it. I'm uploading this
release now. Please don't hesitate to tell me if it helps.
--
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.
signature.asc
Description: PGP signature
Bug#961584: lxc-stop fails with exit code 1
PS, just to be sure: You do have mounted cgroupv2 on the Docker host and in the Docker container?
Bug#961584: lxc-stop fails with exit code 1
I am using LXC 4.0.2 on about 25 systems without problems. None of these hosts does nested virtualization, though. Nested virtualization and cgroups vs cgroups2 is a *highly* complex issue. Can you reproduce this problem outside of your Docker setup? I wouldn't like to see LXC dropped for Bullseye, just due to some hiccup thats is not relevant for anybody except the few guys running LXC within Docker. Regards Harri
Bug#961584: lxc-stop fails with exit code 1
El 2/6/20 a las 20:07, Pierre-Elliott Bécue escribió:
> Could you remove the --quiet bit to see if lxc-stop gives us a bit more
> intel?
>
> If possible, have your testbed call lxc-stop --kill --logpriority trace
> --logfile /dev/stdout --name ${NAME}, so we can have the most expressive
> output. But if it's an error, removing the quiet bit could be enough.
>
> Thanks.
>
The POC I attached on a previous email it's not using debci, so you can
modify the lxc-stop call.
After enabling trace log level, the output is the following:
> Starting LXC network bridge: :Starting LXC autoboot containers: :
> lxc-stop autopkgtest-stable-amd64 20200603085059.718 TRACEcommands -
> commands.c:lxc_cmd_rsp_recv:123 - Command "get_init_pid" received response
> lxc-stop autopkgtest-stable-amd64 20200603085059.718 DEBUGcommands -
> commands.c:lxc_cmd_rsp_recv:156 - Response data length for command
> "get_init_pid" is 0
> lxc-stop autopkgtest-stable-amd64 20200603085059.718 TRACEcommands -
> commands.c:lxc_cmd:293 - Opened new command socket connection fd 4 for
> command "get_init_pid"
> lxc-stop autopkgtest-stable-amd64 20200603085059.719 TRACEcommands -
> commands.c:lxc_cmd_rsp_recv:123 - Command "get_state" received response
> lxc-stop autopkgtest-stable-amd64 20200603085059.719 DEBUGcommands -
> commands.c:lxc_cmd_rsp_recv:156 - Response data length for command
> "get_state" is 0
> lxc-stop autopkgtest-stable-amd64 20200603085059.719 TRACEcommands -
> commands.c:lxc_cmd:293 - Opened new command socket connection fd 4 for
> command "get_state"
> lxc-stop autopkgtest-stable-amd64 20200603085059.719 DEBUGcommands -
> commands.c:lxc_cmd_get_state:656 - Container "autopkgtest-stable-amd64" is in
> "RUNNING" state
> lxc-stop autopkgtest-stable-amd64 20200603085059.719 TRACEcommands -
> commands.c:lxc_cmd_rsp_recv:123 - Command "stop" received response
> lxc-stop autopkgtest-stable-amd64 20200603085059.719 DEBUGcommands -
> commands.c:lxc_cmd_rsp_recv:156 - Response data length for command "stop" is 0
> lxc-stop autopkgtest-stable-amd64 20200603085059.719 TRACEcommands -
> commands.c:lxc_cmd:293 - Opened new command socket connection fd 4 for
> command "stop"
> lxc-stop autopkgtest-stable-amd64 20200603085059.720 ERRORcommands -
> commands.c:lxc_cmd_stop:707 - No such file or directory - Failed to stop
> container "autopkgtest-stable-amd64"
> lxc-stop: autopkgtest-stable-amd64: commands.c: lxc_cmd_stop: 707 No such
> file or directory - Failed to stop container "autopkgtest-stable-amd64"
--
- ina
signature.asc
Description: OpenPGP digital signature
Bug#961584: lxc-stop fails with exit code 1
Le mardi 26 mai 2020 à 12:55:10+0200, Inaki Malerba a écrit :
> Source: lxc
> Version: 1:4.0.2-1
> Severity: important
>
> Dear Maintainer,
>
> Since version 1:4.0.2-1, we've found a change on the behavior of
> lxc-stop when running on the Salsa-CI pipeline.
>
> debci calls `lxc-stop --quiet --kill --name $NAME` and it's returning
> exit code 1.
>
> This can be reproduced on salsa-ci pipeline, which calls `debci localtest`.
>
> https://salsa.debian.org/salsa-ci-team/pipeline/-/jobs/765946
>
> : failure: ['sudo', 'timeout', '600', 'lxc-stop',
> '--quiet', '--kill', '--name', 'ci-147-3f089355'] failed (exit status 1,
> stderr '')
Could you remove the --quiet bit to see if lxc-stop gives us a bit more
intel?
If possible, have your testbed call lxc-stop --kill --logpriority trace
--logfile /dev/stdout --name ${NAME}, so we can have the most expressive
output. But if it's an error, removing the quiet bit could be enough.
Thanks.
--
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.
signature.asc
Description: PGP signature
Bug#961584: lxc-stop fails with exit code 1
El 26/5/20 a las 23:35, Antonio Terceiro escribió:
> is there an easy/documented way of reproducing the salsa ci environment
> (i.e. lxc working under docker) locally?
Attached is a Dockerfile. It should be sufficient to reproduce the problem.
Changing the FROM statement from debian:unstable to debian:testing is
enough to make it work. It needs to be run as privileged.
$ docker build -t autopkgtest - < Dockerfile
$ docker run --rm --privileged autopkgtest
--
- ina
FROM debian:unstable
ENV SALSA_CI_AUTOPKGTEST_LXC
https://salsa.debian.org/salsa-ci-team/autopkgtest-lxc
ENV LXC_PATH /lxc
# Download and configure container.
RUN apt-get update && apt-get install -y wget
RUN wget --progress=dot:giga
${SALSA_CI_AUTOPKGTEST_LXC}/-/jobs/artifacts/master/raw/artifacts/lxc.tar?job=stable
-O lxc.tar
RUN mkdir ${LXC_PATH} && tar xf lxc.tar -C ${LXC_PATH}
RUN sed -i "/lxc.rootfs.path/ s@dir:.*/lxc/@dir:${LXC_PATH}/@"
${LXC_PATH}/autopkgtest-stable-amd64/config
# Install lxc.
RUN apt-get update && apt-get install -y eatmydata
RUN eatmydata apt-get install -y lxc iptables
RUN echo "lxc.lxcpath=${LXC_PATH}" | tee -a /etc/lxc/lxc.conf
RUN echo 'USE_LXC_BRIDGE="true"' | tee /etc/default/lxc-net
RUN echo 'tmpfs /sys/fs/cgroup tmpfs rw,relatime,seclabel' | tee /etc/fstab
RUN echo 'cgroup /sys/fs/cgroup/cpuset cgroup rw,relatime,cpuset,x-mount.mkdir'
| tee -a /etc/fstab
RUN echo 'cgroup /sys/fs/cgroup/devices cgroup
rw,relatime,devices,x-mount.mkdir' | tee -a /etc/fstab
# This steps need to be run as privileged.
CMD umount -R /sys/fs/cgroup && mount -a && \
/etc/init.d/lxc-net start && \
/etc/init.d/lxc start && \
lxc-start autopkgtest-stable-amd64 && \
lxc-stop autopkgtest-stable-amd64 && \
echo "ok"
signature.asc
Description: OpenPGP digital signature
Bug#961584: lxc-stop fails with exit code 1
Control: severity -1 serious On Tue, May 26, 2020 at 06:35:50PM -0300, Antonio Terceiro wrote: > On Tue, May 26, 2020 at 12:55:10PM +0200, Inaki Malerba wrote: > > Source: lxc > > Version: 1:4.0.2-1 > > Severity: important > > > > Dear Maintainer, > > > > Since version 1:4.0.2-1, we've found a change on the behavior of > > lxc-stop when running on the Salsa-CI pipeline. > > > > debci calls `lxc-stop --quiet --kill --name $NAME` and it's returning > > exit code 1. > > > > This can be reproduced on salsa-ci pipeline, which calls `debci localtest`. > > > > https://salsa.debian.org/salsa-ci-team/pipeline/-/jobs/765946 > > > > : failure: ['sudo', 'timeout', '600', 'lxc-stop', > > '--quiet', '--kill', '--name', 'ci-147-3f089355'] failed (exit status 1, > > stderr '') > > I have been using this version of lxc locally for autopkgtest for a > while without any issues, so this issue is probably specific to running > lxc under docker. > > is there an easy/documented way of reproducing the salsa ci environment > (i.e. lxc working under docker) locally? I downloaded > registry.salsa.debian.org/salsa-ci-team/pipeline/autopkgtest, started a > container with --privileged, and tried following the steps in the > salsa-ci-yml, but I am probably missing something because the containers > won't start apparently due to apparmor. I'm upgrading this bug to serious to prevent this version from reaching testing since this breaks Debian infrastructure. :-) signature.asc Description: PGP signature
Bug#961584: lxc-stop fails with exit code 1
On Tue, May 26, 2020 at 12:55:10PM +0200, Inaki Malerba wrote: > Source: lxc > Version: 1:4.0.2-1 > Severity: important > > Dear Maintainer, > > Since version 1:4.0.2-1, we've found a change on the behavior of > lxc-stop when running on the Salsa-CI pipeline. > > debci calls `lxc-stop --quiet --kill --name $NAME` and it's returning > exit code 1. > > This can be reproduced on salsa-ci pipeline, which calls `debci localtest`. > > https://salsa.debian.org/salsa-ci-team/pipeline/-/jobs/765946 > > : failure: ['sudo', 'timeout', '600', 'lxc-stop', > '--quiet', '--kill', '--name', 'ci-147-3f089355'] failed (exit status 1, > stderr '') I have been using this version of lxc locally for autopkgtest for a while without any issues, so this issue is probably specific to running lxc under docker. is there an easy/documented way of reproducing the salsa ci environment (i.e. lxc working under docker) locally? I downloaded registry.salsa.debian.org/salsa-ci-team/pipeline/autopkgtest, started a container with --privileged, and tried following the steps in the salsa-ci-yml, but I am probably missing something because the containers won't start apparently due to apparmor. signature.asc Description: PGP signature
Bug#961584: lxc-stop fails with exit code 1
Source: lxc Version: 1:4.0.2-1 Severity: important Dear Maintainer, Since version 1:4.0.2-1, we've found a change on the behavior of lxc-stop when running on the Salsa-CI pipeline. debci calls `lxc-stop --quiet --kill --name $NAME` and it's returning exit code 1. This can be reproduced on salsa-ci pipeline, which calls `debci localtest`. https://salsa.debian.org/salsa-ci-team/pipeline/-/jobs/765946 : failure: ['sudo', 'timeout', '600', 'lxc-stop', '--quiet', '--kill', '--name', 'ci-147-3f089355'] failed (exit status 1, stderr '') -- - ina signature.asc Description: OpenPGP digital signature
