If memory serves, just set the HEART_BEAT_TIMEOUT to a non-zero value. The -R is a private API, so it shouldn't be used in this manner. :)
On 19 Nov 2010, at 12:30, Jeroen Janssen wrote: > Hi, > > On Windows and RHEL5 couchdb currently seems to run without the 'heart' > command. > I'm trying to understand how to turn this on. > > I was hoping it was an option in the init.d script configuration and I > found the "RECURSED" option (-R) that seems to use HEART_COMMAND and > HEART_BEAT_TIMEOUT. > > However when I add -R to the COUCHDB_OPTIONS in /etc/sysconfig/couchdb > then the init script seems to hang in "Starting couchdb". > > Do the current scripts in couchdb repository support running with > 'heart' and how do I correctly turn this on? > > Thanks in advance, > > Jeroen > > On Thu, Nov 18, 2010 at 12:28 PM, Robert Newson <[email protected]> > wrote: >> I know that the Windows version does not run 'heart' which is the bit >> that restarts beam if it crashes. If that's true in RHEL too, then the >> crashes can be explained fairly simply. >> >> B. >> >> On Thu, Nov 18, 2010 at 10:15 AM, Sebastian Cohnen >> <[email protected]> wrote: >>> short reply, inline: >>> >>> On 18.11.2010, at 10:49, Jeroen Janssen wrote: >>> >>>> Hello, >>>> >>>> I am currently investigating the migration of data to couchdb and am >>>> experiencing couchdb crashes that are not visible in the couchdb.log >>>> file. >>>> These couchdb crashes have occured on Windows (couchdb 1.0.1, erlang >>>> 14A) and RHEL5 (couchdb 1.0.1, erlang R12B). >>>> >>>> I understand it could be a bit difficult to answer, but I was >>>> wondering what kind of errors would result in couchdb not logging an >>>> error in its logfile? >>> >>> out of memory errors are one example. couch (actually beam.smp) will crash >>> and couch will be restarted. I've seen this in production when replicating >>> or compacting databases with documents having lots of revisions (not sure >>> if this will help you though). >>> >>>> >>>> For the moment I am trying to run with debug logging and hope that I >>>> can get some better logging to show you (the problem seems to be >>>> reasonable reproduceable, although it takes a while to get to it). >>>> >>>> The problem I have might have to due with me 'frequently' calling >>>> compaction on the database while also new documents are inserted. >>>> I do the compaction because there is a problem with appending to 4G+ >>>> files on the Windows platform (in Erlang). >>>> As part of the migration process, I will compact the database after a >>>> certain amount of new documents have been added since last compaction. >>>> This is to ensure that I can get to a situation where all current data >>>> is actually inside couchdb (which unfortunately I have not reached >>>> yet) >>>> >>>> I initially thought the problem was maybe due to Erlang on Windows, >>>> but since I have also had the issue on a RHEL5 machine, I am posting >>>> here to see if it could be something in couchdb itself. >>>> >>>> Let me know if I can do something specific to get more (usefull) logging. >>>> Unfortunately, due to the data that's inside the database I can not >>>> send the actual database files for analysis, but I will try if I can >>>> create a testscript that mimics the migration of my data to couchdb. >>>> >>>> Best regards, >>>> >>>> Jeroen Janssen >>> >>> >>
