Opened 11 years ago

Closed 11 years ago

#9698 closed (invalid)

memcached causes flup fastcgi to crash

Reported by: Whitney Young <wbyoung@…> Owned by: nobody
Component: Uncategorized Version: 1.0
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


My threaded flup fastcgi instance continues to go down using the latest version of django. The errors I get to stderr are:

[FATAL@1227645879.971403] mcm_fetch_cmd():1181: memcache(4) protocol error: Operation now in progress: server sent data for key not in request
[WARN@1227645881.777358] mcm_server_readable():2587: timeout: Operation now in progress: select(2) call timed out for read(2)able fds
[INFO@1227645881.777465] mcm_get_line():1597
[FATAL@1227645881.777481] mcm_server_send_cmd():2711: failed to send command to the memcache server: Operation now in progress: Operation now in progress

And in lighttpd, the generic:

2008-11-25 21:39:57: (mod_fastcgi.c.1743) connect failed: Connection refused on unix:site.sock 
2008-11-25 21:39:57: (mod_fastcgi.c.2912) backend died; we'll disable it for 5 seconds and send the request to another backend instead: reconnects: 0 load: 1 
2008-11-25 21:40:00: (mod_fastcgi.c.3524) all handlers for  /site.fcgi/url/ on /site.fcgi are down. 
2008-11-25 21:40:03: (mod_fastcgi.c.2725) fcgi-server re-enabled: unix:site.sock


  • flup 1.0-1
  • cmemcache 0.95
  • django 1.0.2
  • lighttpd 1.4.19

I've 'fixed' this issue by just restarting my fastcgi instance when it goes down, but any insight (or fixes) would be great.

Change History (2)

comment:1 Changed 11 years ago by Whitney Young <wbyoung@…>

Oh, sorry more information...

memcached doesn't actually crash. It stays running. Just the flup fcgi process crashes.

comment:2 Changed 11 years ago by Malcolm Tredinnick

Resolution: invalid
Status: newclosed

I don't see the Django bug here. You might want to ask on django-users to see if anybody else has seen a similar problem. But there's nothing we can really do at the Django level to repeat or fix this problem, since it seems to be involving external processes. If further details reveal some particular implementation detail of Django that is causing this, then please reopen with those details, but we cannot be asked to investigate every crash for every configuration and treat it as a Django bug just because Django is one of the involved components.

This needs a lot more information before it can be confirmed as a bug. Closing for now, but do reopen if there are more details that poitn precisely to some operation in Django that's causing the error reliably.

Note: See TracTickets for help on using tickets.
Back to Top