Eric, Thanks for the 0.93.3 release. I''m now able to test my apps with unicorn. If I have an idle application, the master program restarts the workers every timeout seconds. Is this the expected behavior, and if so, is there a reason for it? Would you be opposed to changing it so that the master doesn''t restart workers that haven''t had any activity in the last timeout seconds? Jeremy
Jeremy Evans <jeremyevans0 at gmail.com> wrote:> Eric, > > Thanks for the 0.93.3 release. I''m now able to test my apps with unicorn. > > If I have an idle application, the master program restarts the workers > every timeout seconds. Is this the expected behavior, and if so, is > there a reason for it? Would you be opposed to changing it so that > the master doesn''t restart workers that haven''t had any activity in > the last timeout seconds?Idle as in no clients connected (and not long-poll/Comet idle)? Definitely not expected behavior... Can you try playing the following on OpenBSD and seeing if the ctimes match for before and after? require ''tempfile'' foo = Tempfile.new nil before = foo.stat foo.chmod 1 sleep 1 foo.chmod 0 after = foo.stat p [ before.ctime, after.ctime ] If they''re the same, can you also try syswrite(".") instead of chmod and see if that does anything? I wonder if OpenBSD is not implementing st_ctime changes properly, I understanding is that st_ctime should change for any FS-related operations, from the Linux stat(2) manpage: http://linux.die.net/man/2/stat The field st_ctime is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.). Likewise, the OpenBSD manpage: http://www.openbsd.org/cgi-bin/man.cgi?query=stat&apropos=0&sektion=2&manpath=OpenBSD+Current&arch=i386&format=html st_ctime Time when file status was last changed (inode data modification). Changed by the chmod(2), chown(2), link(2), rename(2), unlink(2), utimes(2), and write(2) system calls. Note that the OpenBSD manpage doesn''t explicitly say fchmod(2), just chmod(2), so if the above didn''t work, maybe the following does? require ''tempfile'' foo = Tempfile.new nil before = foo.stat File.chmod(1, foo.path) sleep 1 File.chmod(0, foo.path) after = foo.stat p [ before.ctime, after.ctime ] This might be a bug in OpenBSD, but I''d be willing to make a workaround -- Eric Wong
Jeremy Evans <jeremyevans0 at gmail.com> wrote:> On Sun, Oct 11, 2009 at 6:32 PM, Eric Wong <normalperson at yhbt.net> wrote: > > Jeremy Evans <jeremyevans0 at gmail.com> wrote: > > Can you try playing the following on OpenBSD and seeing if > > the ctimes match for before and after?<snip>> The times are different: > > [Sun Oct 11 19:08:42 -0700 2009, Sun Oct 11 19:08:43 -0700 2009]OK. Is this only on a certain app/library that might use IO.select in a different thread? Can you reproduce it on a dead simple "Hello World" app that you''re certain is single-threaded? It could be related to this bug someone off list hit the other day: http://net-ssh.lighthouseapp.com/projects/36253/tickets/1 (redmine.ruby-lang.org is dead right now :<) http://redmine.ruby-lang.org/issues/show/2039 http://redmine.ruby-lang.org/issues/show/1993 Can you ktrace(? (or any other) syscall tracer) the worker immediately after spawning and see what it''s doing up until the master kills it? The other possible culprit is that the accept_nonblock is blocking, somehow... -- Eric Wong
On Sun, Oct 11, 2009 at 7:46 PM, Jeremy Evans <jeremyevans0 at gmail.com> wrote:> On Sun, Oct 11, 2009 at 7:31 PM, Eric Wong <normalperson at yhbt.net> wrote: >> Jeremy Evans <jeremyevans0 at gmail.com> wrote: >>> On Sun, Oct 11, 2009 at 6:32 PM, Eric Wong <normalperson at yhbt.net> wrote: >>> > Jeremy Evans <jeremyevans0 at gmail.com> wrote: >>> > Can you try playing the following on OpenBSD and seeing if >>> > the ctimes match for before and after? >> <snip> >>> The times are different: >>> >>> ? [Sun Oct 11 19:08:42 -0700 2009, Sun Oct 11 19:08:43 -0700 2009] >> >> OK. >> >> Is this only on a certain app/library that might use IO.select in a >> different thread? ?Can you reproduce it on a dead simple "Hello World" >> app that you''re certain is single-threaded? ?It could be related to this >> bug someone off list hit the other day: > > This is completely my fault. ?I wasn''t using a config.ru file > previously, so when I first ran unicorn, it asked me to create one. ?I > added one that did: > > ?require ''start'' # start.rb being the file that started the application > > Near the end of start.rb: > > ?Rack::Handler.get(''mongrel'').run ... > > Things are working fine now that I''ve fixed my code. ?Sorry for the noise. > > Jeremy >Eric, This and earlier replies were meant for the list. Is it possible for the list''s reply-to address to be the list address itself? Jeremy
Jeremy Evans <jeremyevans0 at gmail.com> wrote:> On Sun, Oct 11, 2009 at 7:31 PM, Eric Wong <normalperson at yhbt.net> wrote: > > Jeremy Evans <jeremyevans0 at gmail.com> wrote: > >> On Sun, Oct 11, 2009 at 6:32 PM, Eric Wong <normalperson at yhbt.net> wrote: > >> > Jeremy Evans <jeremyevans0 at gmail.com> wrote:<snip>> This is completely my fault. I wasn''t using a config.ru file > previously, so when I first ran unicorn, it asked me to create one. I > added one that did: > > require ''start'' # start.rb being the file that started the application > > Near the end of start.rb: > > Rack::Handler.get(''mongrel'').run ... > > Things are working fine now that I''ve fixed my code. Sorry for the noise.No worries :) I hit a similar issue with older Sinatra, too. Btw, the convention here should be to Cc: the list even when replying to a person (I prefer the same conventions as git ML and LKML). -- Eric Wong
Jeremy Evans <jeremyevans0 at gmail.com> wrote:> Eric, > > This and earlier replies were meant for the list. Is it possible for > the list''s reply-to address to be the list address itself?Otoh, this list is much less traffic than the other mailing lists I follow. I''ll consider changing it in 24 hours unless there are objections... -- Eric Wong