Project

General

Profile

[Solved] Lighttpd 1.4.43/44 dies - missing cleanup in webdav

Added by nickrickard almost 8 years ago

Hi,

I'm running Debian testing/stretch which is up to date. I was running lighttpd (and lighttpd-mod-webdav) 1.4.39 but, through standard Debian repos, that recently updated to 1.4.43+git20161216-1. It ran fine for all general webserver stuff, but when I ran the Android app FolderSync on my phone which syncs files with my server via webdav (I've run FolderSync for ages and I don't think has changed) it causes lighttpd to issue the following in the log about 20 times before dying. There is no dying note, ie not a "server stopped" in the log.

2017-01-02 15:12:32: (connections.c.273) missing cleanup in webdav

(messages average five seconds apart but varies 1sec to >15sec)

I tried 1.4.44-0.1 (from https://debian.lighttpd.net/lighttpd1.4/pool/main/l/lighttpd/) but that seems to have the same crash.

At present I've reverted to 1.4.35 (from debian stable, was the easiest to revert to) and that's fine.

Has anyone experienced anything similar, please?

Nick.


Replies (6)

RE: Lighttpd 1.4.43/44 dies - missing cleanup in webdav - Added by gstrauss almost 8 years ago

Thanks for the report.

This is a bug, but should not be causing any crash.
The cleanup actually runs, but neglected to set a pointer to NULL to indicate that the cleanup had run.
The error trace in connections.c reports that and then sets the pointer to NULL.
(connections.c does not attempt to clean the context up for mod_webdav since connections.c does not know how to do so)

I would be interested in finding out more about what is happening with lighttpd afterwards. If you have a core file or any other information, please update here. I'll run some tests, too.

RE: Lighttpd 1.4.43/44 dies - missing cleanup in webdav - Added by gstrauss almost 8 years ago

ick. The bug may eventually cause a crash in lighttpd 1.4.44 (but not lighttpd 1.4.43) since the change in connections.c that moved the handler cleanup detection to connection shutdown.
The fix:

--- a/src/mod_webdav.c
+++ b/src/mod_webdav.c
@@ -2758,7 +2758,10 @@ PHYSICALPATH_FUNC(mod_webdav_physical_handler) {
 static handler_t mod_webdav_connection_reset(server *srv, connection *con, void *p_d) {
        plugin_data *p = p_d;
        handler_ctx *hctx = con->plugin_ctx[p->id];
-       if (hctx) free(hctx);
+       if (hctx) {
+               free(hctx);
+               con->plugin_ctx[p->id] = NULL;
+       }

        UNUSED(srv);
        return HANDLER_GO_ON;

RE: Lighttpd 1.4.43/44 dies - missing cleanup in webdav - Added by gstrauss almost 8 years ago

@nickrickard a workaround might be to disable keep-alive for the webdav paths, e.g. if /webdav/ is the URL path to your WebDAV location

$HTTP["url"] =~ "^/webdav/" {
    server.max-keep-alive-requests = 0
}

If you have a chance, would you test with lighttpd 1.4.44 and report back if this workaround helps? Thanks.

RE: Lighttpd 1.4.43/44 dies - missing cleanup in webdav - Added by nickrickard almost 8 years ago

@gstrauss

Many thanks. The server.max-keep-alive-requests = 0 workaround seems to be okay with 1.4.44-0.1. I still get the stream of "missing cleanup in webdav" messages in the log whilst FolderSync is running, but lighttpd doesn't crash (to date), which is the key thing.

I'm afraid I've got a fairly un-development setup and no experience of capturing crashes. If you can post instructions and/or link to a guide I can try to unset server.max-keep-alive-requests parameter and get you a dump of lighttpd when it does crash.

RE: Lighttpd 1.4.43/44 dies - missing cleanup in webdav - Added by gstrauss almost 8 years ago

Thanks @nickrickard. I was able to reproduce the crash and fixed it with the patch above.
lighttpd 1.4.45 has been released with this fix.

Hopefully, Debian lighttpd maintainers will quickly pick up the new release.

RE: Lighttpd 1.4.43/44 dies - missing cleanup in webdav - Added by nickrickard almost 8 years ago

@gstrauss - thanks, I saw it had been addressed in the 1.4.45 changelog. Looking forward to getting it pulled through into Debian soon.

    (1-6/6)