On Mon, Oct 1, 2012 at 10:57 AM, Roberto De Ioris <[email protected]> wrote: > > Il giorno 01/ott/2012, alle ore 19:40, Ryan Showalter <[email protected]> ha > scritto: > >> Hello, >> >> One of my @cron decorated functions with target='mule' has not been >> executing the last few days and I think I've traced it down to an >> issue where mules don't like low-memory environments. >> >> Workers and spool jobs still function nominally, and if I remove the >> target parameter, things seem to work again. While debugging this >> issue, the issue disappeared when I reduced the number of >> workers/mules.. and then afterwards, the issue still did not appear >> when I brought the levels of mules/workers to their typical level. >> Only after I put some load on the server did the @cron mule begin to >> fail with the message below. >> >> Mon Sep 24 08:45:13 2012 - uWSGI mule 3 braying: my master died, i >> will follow him... >> OOOPS mule 3 (pid: 3869) crippled...trying respawn... >> spawned uWSGI mule 3 (pid: 4546) >> >> I'm wondering if this might somehow be avoided? >> > > The master is dying, this is pretty ugly, and spoolers as well as workers > should follow him pretty soon. > > Can you check if the master is really dead ? Is a traceback available when > the mule dies (or when the master dies, if it happens) in the logs ?
There is no indication in the logs that anything else is happening other than the mule dying. No traceback, no master dying.. only what I pasted previously. > > > -- > Roberto De Ioris > http://unbit.it > JID: [email protected] > > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
