mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Markus Wichmann <nullplan@gmx.net>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Hung processes with althttpd web server
Date: Thu, 5 Oct 2023 08:39:03 -0400	[thread overview]
Message-ID: <20231005123858.GH4163@brightrain.aerifal.cx> (raw)
In-Reply-To: <ZR4vhfR8T1Bgh3GX@voyager>

On Thu, Oct 05, 2023 at 05:37:41AM +0200, Markus Wichmann wrote:
> Am Wed, Oct 04, 2023 at 09:41:41PM -0400 schrieb Carl Chave:
> > Hello, I'm running the althttpd web server on Alpine Linux using a Ramnode VPS.
> >
> > I've been having issues for quite a while with "hung" processes. There
> > is a long lived parent process and then a short lived forked process
> > for each http request. What I've been seeing is that the forked
> > processes will sometimes get stuck:
> >
> > sod01:/srv/www/log$ sudo strace -p 11329
> > strace: Process 11329 attached
> > futex(0x7f5bdcd77900, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> >
> 
> I often see this system call hung when signal handlers are doing
> signal-unsafe things. Looking at the source code, that is exactly what
> happens if the process catches a signal at the wrong time. Try removing
> all calls to signal(); that should do what the designers intended
> better (namely quit the process). If you want to log when a process dies
> of unnatural causes, that's something the parent process can do.
> 
> The signal handler will call MakeLogEntry(), and that will do
> signal-unsafe things such as call free(), localtime(), or fopen(). If
> the main process is currently using malloc() when that happens, you will
> get precisely this hang.
> 
> 
> > Please see this forum thread for additional information:
> > https://sqlite.org/althttpd/forumpost/4dc31619341ce947
> >
> 
> Seems like they haven't yet found the trail of the signal handler.

OK, this is almost surely the source of the problem. It would still be
interesting to know which lock is being hit here, since for the most
part, locks are skipped in single-threaded processes. But even if the
lock were skipped, the invalid calls to async-signal-unsafe functions
from async-signal context would be corrupting the state those locks
were meant to protect. That's probably what's happening on glibc
(meaning this code only appears to work there, but it likely behaving
dangerously).

Rich

  reply	other threads:[~2023-10-05 12:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05  1:41 Carl Chave
2023-10-05  2:15 ` Rich Felker
2023-10-05  2:43   ` Carl Chave
2023-10-05 13:39     ` Szabolcs Nagy
2023-10-05 18:26       ` Carl Chave
2023-10-05 18:48         ` Markus Wichmann
2023-10-05 19:06           ` Carl Chave
2023-10-05  3:37 ` Markus Wichmann
2023-10-05 12:39   ` Rich Felker [this message]
2023-10-05 18:34     ` Markus Wichmann
2023-10-05 18:52   ` Carl Chave

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=20231005123858.GH4163@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    --cc=nullplan@gmx.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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).