List for cgit developers and users
 help / color / mirror / Atom feed
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: John Keeping <john@keeping.me.uk>
Cc: cgit@lists.zx2c4.com
Subject: Re: cgit 1.2.3: lighttpd 1.4.57, AlpineLinux [edge]: using cache breaks delivery
Date: Mon, 21 Dec 2020 20:31:27 +0100	[thread overview]
Message-ID: <20201221193127.zbZeP%steffen@sdaoden.eu> (raw)
In-Reply-To: <X+DiDgGaPaynnocI@john.keeping.me.uk>

Hi.

John Keeping wrote in
 <X+DiDgGaPaynnocI@john.keeping.me.uk>:
 |On Mon, Dec 21, 2020 at 05:26:19PM +0100, Steffen Nurpmeso wrote:
 |> I discovered today that cgit no longer delivers pages, and it must
 |> have been like that for some time.  The server looks show
 |> successful delivery, the cgit cache is populated and rotated just
 |> correctly, but all cgit delivers is that final error of main() as
 |> 
 |>   <div class='error'>Error processing page: Invalid argument (22)</div>
 |> 
 |> (surely a misconfiguration that this is not a real HTML page,
 |> i recall it took some time to figure out about about-filter, just
 |> "doing it" (<pre>cat(1)</pre>)).
 |> 
 |> If i set "cache-size=0" then the desired page is delivered.
 |> Note the cache itself is managed as usual with the default
 |> cache-size=1999.
 |> 
 |> The files in the cache are 0600, i thought maybe that was it, but
 |> the setting is actively reverted to this mask (i never looked at
 |> cgit code except grepping the error).  It has always been so, the
 |> oldest cache entry was
 |> 
 |>   -rw-------    1 lighttpd lighttpd      3023 Mar 18  2018 d2200000
 |> 
 |> I am pretty sure cgit delivered some weeks ago, the most notable
 |> difference is that AlpineLinux switched to Lighttpd 1.4.56 then
 |> .57, which seems to have brought tremendous changes under the
 |> hood, like HTTP/2 support and OCSP as well as support for all the
 |> different TLS libraries, whereas before it only was OpenSSL and
 |> compatibles, i think.  We have HTTP/2 not enabled yet.
 |> 
 |> Anything i can do about this?
 |
 |Have you looked at the log output?

Yes, sorry, terrible mess above. Monday and no end.

  - Logs show nothing.  I enabled
      debug.log-request-handling = "enable" 
    but that showed nothing.  But wait, there was
    server.breakagelog that was needed .. as below!

 |This error comes from cgit.c::cmd_main() as a result of
 |cache.c::cache_process() returning an error.  It looks like all of the

Yes.

 |error paths there will write a more detailed error message to stderr.

Unfortunately nothing .. but with breakaglog there is

  [cgit] error printing cache /var/lib/lighttpd/cgit/b1000000: Invalid argument (22)

But the file was generated normally:

  # ll /var/lib/lighttpd/cgit/b1000000
  -rw-------    1 lighttpd lighttpd     23417 Dec 21 20:22 /var/lib/lighttpd/cgit/b1000000

 |I don't use lighttpd so I don't know whether that output is captured,
 |but normally output written to stderr will end up in a log file.

Was server.breakagelog i had forgotten about.

 |>From a quick look at the code, given that the problem seems to be caused
 |by updating the web server, my guess is that you'll see the error:
 |
 | [cgit] error printing cache ...: Invalid argument (22)
 |
 |and this may be caused by sendfile(2) failing due to some difference in
 |how the web server is setting up the output file descriptor.  You may
 |want to rebuild CGit without HAVE_LINUX_SENDFILE and see if that works.

I did not know about 'cgi.x-sendfile = "enable"' yet, but setting
it does not matter from cgit's point of view.

 |(If it does, we should add better fallback handling for the case where
 |stdout is not a valid output for sendfile().)

Ok, i will hm do that mirroring the ArchLinux recipe and report
back.

Thanks!

 |John
 --End of <X+DiDgGaPaynnocI@john.keeping.me.uk>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

  reply	other threads:[~2020-12-21 19:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-21 16:26 Steffen Nurpmeso
2020-12-21 17:57 ` John Keeping
2020-12-21 19:31   ` Steffen Nurpmeso [this message]
2020-12-21 22:23     ` Steffen Nurpmeso
2020-12-21 23:24       ` Steffen Nurpmeso
2021-01-02 18:38 ` Jon DeVree
2021-01-15 18:01   ` Jon DeVree
2021-01-15 21:51     ` Konstantin Ryabitsev
2021-01-15 22:41       ` Jon DeVree
2020-12-22  6:12 gs-cgit-lists.zx2c4.com
2020-12-22 13:55 ` Steffen Nurpmeso
2020-12-22 15:09   ` Steffen Nurpmeso
2020-12-22 21:22     ` Steffen Nurpmeso
2020-12-29 17:04       ` Steffen Nurpmeso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201221193127.zbZeP%steffen@sdaoden.eu \
    --to=steffen@sdaoden.eu \
    --cc=cgit@lists.zx2c4.com \
    --cc=john@keeping.me.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).