Because Dave spent a presumably absurd amount of time injecting diagnostic logging statements into supervisor, the "crash on reload" bug has been fixed in SVN.
On deck: give options.py a brain transplant to fix the stdXXX_logfile Python format string expansion issue. - C Dave Peticolas wrote: > Chris McDonough wrote: >> Hi Dave, >> >> Wrt expanding "program_name", you've run into a bug, apologies. As >> you notice,d the only value that "stdout_logfile" accepts in 3.0a6 is >> "here", despite the docs' claims to the contrary. In a subsequent >> release we'll fix it (you can track it at >> http://plope.com/software/collector/268). > > Cool, thanks! > > >> Wrt to supervisor crashing, I *think* I've replicated the problem. >> Can you verify that I'm seeing the same thing? For me it happens when: >> >> a) You've got supervisord in the background (e.g. started without the -n >> flag, and without daemonize=False in the config file; it seems to >> not happen when supervisord is in the foreground). >> >> b) You type "reload" at the supervisorctl prompt twice (or sometimes >> three times). Supervisord dies and supervisorctl can't talk to it >> anymore. > > I'm pretty sure it's the same one. I was running supervisorctl in > non-interactive mode to reload repeatedly, but I just tried it in > an interactive shell and got the same thing. > > I believe the problem is that in one of the subsequent reloads, > daemonize is actually closing the logging object's file descriptor > when it does its close/reopen dance. > > Looking at daemonize, there also seems to be potential race conditions > in that both the parent and the child are potentially using the logging > object at about the same time. > > >> Thanks a lot for the bug reports! > > No problem, thanks for supervisord! > > >> - C >> >> >> >> Dave Peticolas wrote: >>> Hello there, I just started trying out supervisord. It looks quite >>> nifty, but I've run into a couple issues. I'm attaching a config file >>> and a test program. >>> >>> If I use the config file as is, I get the traceback below, >>> which I have snipped and sanitized. >>> >>> Looking at the traceback, it doesn't appear to be possible >>> to use substitution keys like 'program_name' as indicated >>> in the docs, except for 'here'. >>> >>> If I comment out stdout_logfile, then the supervisor will >>> start ok. Then, if I use supervisorctl to reload the process, >>> it works ok the first time. But if I reload it again, the >>> supervisor crashes. A little poking around with some logging >>> statements seems to indicate that during the second time around, >>> the logging object is using file descriptor 2 and this gets closed >>> during daemonize(). >>> >>> thanks, >>> dave >>> >>> Traceback (most recent call last): >>> <snip> >>> File "/blah/blah/supervisor/datatypes.py", line 228, in >>> existing_dirpath >>> nv = v % {'here':here} >>> KeyError: 'program_name' >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Supervisor-users mailing list >>> [email protected] >>> http://lists.supervisord.org/mailman/listinfo/supervisor-users >> > _______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
