[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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

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

Attachment: signature.asc
Description: PGP signature

Reply to: