Bug#922447: lighttpd: autopkgtest regression
Hi Antonio, Thank you for correcting my analysis. It would have taken me quite a while to figure that out without your explanation. On Mon, Feb 18, 2019 at 10:01:00PM +0100, Antonio Terceiro wrote: > I have downloaded the lighttpd source here, and read all the tests. All > of them to start lighttpd directly, and at least the first test requires > being run as root; Tests that need to run as root need to say so in the > control file; salsa-ci runs stuff as root already, and that's why it > doesn't fail there. Indeed, the idea was to not run them as root where avoidable to make it easier to run tests on developer systems. > In fact, just adding `Restrictions: needs-root` makes the test pass again. > Just tested this here. After your explanation, that makes very much sense and we will change that. Again thank you for going in depth. > By the way, since all the tests are starting lighttpd directly means > that the service definitions and the init integration is not being > tested being "the service starts" (because the package installation, and > therefore autopkgtest, would fail if that fails). Also, note that when > you start lighttpd directly in your script, there will be another > instance -- the one started by the init system -- running in the > background. Oh, testing the system-wide lighttpd service is a good idea. We should fix that indeed. As for conflicts with other instances, that part has been avoided: * The invocations with -tt only check the configuration and do not open a port. * The invocations without -tt deliberately use a different port to avoid the situation you describe. Therefore I'm inclined to only add needs-root to the failing defconfig tests. I do expect the others to pass unprivileged. And now I'm confident that ci.d.n will tell me when they don't. Thank you for the awesome service. Even the very limited autopktests that lighttpd has now have revealed quite a number of problems. The "just works" experience is great. Helmut
Bug#922447: lighttpd: autopkgtest regression
On Mon, Feb 18, 2019 at 07:38:49PM +0100, Paul Gevers wrote: > Hi Helmut, > > [Adding the debian-ci team into the discussion] > > On 18-02-2019 08:06, Helmut Grohne wrote: > >> autopkgtest [00:11:07]: test defconfig: [--- > >> 2019-02-16 00:11:07: (configfile.c.1599) server.upload-dirs doesn't > >> exist: /var/cache/lighttpd/uploads > >> 2019-02-16 00:11:07: (mod_compress.c.275) can't stat compress.cache-dir > >> /var/cache/lighttpd/compress/ Permission denied > > > > What happens here is that /var/cache/lighttpd/compress is not created > > during installation. That actually is a problem, but the question is > > whether the test environment is "sane". > > The ci.d.n runs its tests in a standard LXC. So depending on what you > think you should support, that is where delta's from bare metal > configurations come from. > > > The very same autopkgtest does not fail on salsa-ci: > > https://salsa.debian.org/debian/lighttpd/-/jobs/126948 > > I don't know how salsa-ci runs it's pipelines. > > > Upon closer inspection the difference becomes apparent. salsa-ci is > > performing a regular package installation. > > As does ci.d.n, except in an LXC. > > > lighttpd's init script > > ensures the presence of said directory as does the tmpfile.d config. > > However ci.debian.net runs neither (because it seems to come without an > > init system). > > Didn't know about that. Does anybody know if that is normal for LXCs? That is not the case; it's the other way around: salsa-ci runs stuff on docker containers -- and so have no init system. LXC is designed to run system containers, and it does have a full init system. > > We can of course create these locations in the package itself. Indeed we > > already do that for e.g. /var/log/lighttpd (and that makes us require > > root for build). > > > > It turns out that ci.debian.net's environment is a bit artificial in > > this regard. Should we weaken the test here or should we ensure presence > > of those locations through non-init means? Again, this argument does not hold. LXC (and ci.debian.net) boots an actual init system inside the container, and it has *always* been like this. I have downloaded the lighttpd source here, and read all the tests. All of them to start lighttpd directly, and at least the first test requires being run as root; Tests that need to run as root need to say so in the control file; salsa-ci runs stuff as root already, and that's why it doesn't fail there. In fact, just adding `Restrictions: needs-root` makes the test pass again. Just tested this here. By the way, since all the tests are starting lighttpd directly means that the service definitions and the init integration is not being tested being "the service starts" (because the package installation, and therefore autopkgtest, would fail if that fails). Also, note that when you start lighttpd directly in your script, there will be another instance -- the one started by the init system -- running in the background. signature.asc Description: PGP signature
Bug#922447: lighttpd: autopkgtest regression
Hi Helmut, [Adding the debian-ci team into the discussion] On 18-02-2019 08:06, Helmut Grohne wrote: >> autopkgtest [00:11:07]: test defconfig: [--- >> 2019-02-16 00:11:07: (configfile.c.1599) server.upload-dirs doesn't >> exist: /var/cache/lighttpd/uploads >> 2019-02-16 00:11:07: (mod_compress.c.275) can't stat compress.cache-dir >> /var/cache/lighttpd/compress/ Permission denied > > What happens here is that /var/cache/lighttpd/compress is not created > during installation. That actually is a problem, but the question is > whether the test environment is "sane". The ci.d.n runs its tests in a standard LXC. So depending on what you think you should support, that is where delta's from bare metal configurations come from. > The very same autopkgtest does not fail on salsa-ci: > https://salsa.debian.org/debian/lighttpd/-/jobs/126948 I don't know how salsa-ci runs it's pipelines. > Upon closer inspection the difference becomes apparent. salsa-ci is > performing a regular package installation. As does ci.d.n, except in an LXC. > lighttpd's init script > ensures the presence of said directory as does the tmpfile.d config. > However ci.debian.net runs neither (because it seems to come without an > init system). Didn't know about that. Does anybody know if that is normal for LXCs? > We can of course create these locations in the package itself. Indeed we > already do that for e.g. /var/log/lighttpd (and that makes us require > root for build). > > It turns out that ci.debian.net's environment is a bit artificial in > this regard. Should we weaken the test here or should we ensure presence > of those locations through non-init means? If your package/test only works on bare metal, you should declare an isolation-machine restriction (and it will be skipped on ci.d.n). If your package should also work in LXC, you should probably fix the package. If you want the test to run on the current ci.d.n infrastructure and don't want/need to support LXC usage of your package, you can fix the situation in your test only. Paul signature.asc Description: OpenPGP digital signature
Bug#922447: lighttpd: autopkgtest regression
Control: tags -1 + confirmed Hi Paul, On Sat, Feb 16, 2019 at 08:42:35AM +0100, Paul Gevers wrote: > With a recent upload of lighttpd the autopkgtest of lighttpd fails in > testing when that autopkgtest is run with the binary packages of > lighttpd from unstable. It passes when run with only packages from > testing. In tabular form: >passfail > lighttpd from testing1.4.53-2 > all others from testingfrom testing Thank you for looking through failures thoroughly. In this case, I was aware of the issue. I confirm that it is a genuine regression of the upload. While I have your attention, I'm interested in your input though. :) > autopkgtest [00:11:07]: test defconfig: [--- > 2019-02-16 00:11:07: (configfile.c.1599) server.upload-dirs doesn't > exist: /var/cache/lighttpd/uploads > 2019-02-16 00:11:07: (mod_compress.c.275) can't stat compress.cache-dir > /var/cache/lighttpd/compress/ Permission denied What happens here is that /var/cache/lighttpd/compress is not created during installation. That actually is a problem, but the question is whether the test environment is "sane". The very same autopkgtest does not fail on salsa-ci: https://salsa.debian.org/debian/lighttpd/-/jobs/126948 Upon closer inspection the difference becomes apparent. salsa-ci is performing a regular package installation. lighttpd's init script ensures the presence of said directory as does the tmpfile.d config. However ci.debian.net runs neither (because it seems to come without an init system). We can of course create these locations in the package itself. Indeed we already do that for e.g. /var/log/lighttpd (and that makes us require root for build). It turns out that ci.debian.net's environment is a bit artificial in this regard. Should we weaken the test here or should we ensure presence of those locations through non-init means? Thanks for your input Helmut
Bug#922447: lighttpd: autopkgtest regression
Source: lighttpd Version: 1.4.53-2 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of lighttpd the autopkgtest of lighttpd fails in testing when that autopkgtest is run with the binary packages of lighttpd from unstable. It passes when run with only packages from testing. In tabular form: passfail lighttpd from testing1.4.53-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=lighttpd https://ci.debian.net/data/autopkgtest/testing/amd64/l/lighttpd/1936982/log.gz autopkgtest [00:11:07]: test defconfig: [--- 2019-02-16 00:11:07: (configfile.c.1599) server.upload-dirs doesn't exist: /var/cache/lighttpd/uploads 2019-02-16 00:11:07: (mod_compress.c.275) can't stat compress.cache-dir /var/cache/lighttpd/compress/ Permission denied 2019-02-16 00:11:07: (server.c.1472) Configuration of plugins failed. Going down. autopkgtest [00:11:07]: test defconfig: ---] autopkgtest [00:11:08]: test defconfig: - - - - - - - - - - results - - - - - - - - - - defconfigFAIL non-zero exit status 253 autopkgtest [00:11:08]: test defconfig: - - - - - - - - - - stderr - - - - - - - - - - 2019-02-16 00:11:07: (configfile.c.1599) server.upload-dirs doesn't exist: /var/cache/lighttpd/uploads 2019-02-16 00:11:07: (mod_compress.c.275) can't stat compress.cache-dir /var/cache/lighttpd/compress/ Permission denied 2019-02-16 00:11:07: (server.c.1472) Configuration of plugins failed. Going down. signature.asc Description: OpenPGP digital signature
