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 >> >> >
