Hi Daniel,

Thanks for the reply. Here is some more information that I have gathered on this problem.

>> This code is executed 1000's of times in a loop per daemon iteration. The
>> command is successful around 95% of the time, but on occasion hangs
>> indefinitely. Looking at the process status I see these 2 processes:

> What protocols are you using when this happens? Anything in particular you've
> found that unite the "hanging" processes and separate them from the ones that
> don't hang?

I'm just using HTTP and there are no real identifying factors for a hanging curl process as far as what arguments are passed in.

>> This process will hang indefinitely until I kill it and is always utilizing
>> 98% CPU. This behavior, right off the bat, is strange since I am using the
>> -m flag with 120 seconds. It will continue to hang for hours and hours.

> Are you using a curl from the FreeBSD ports package or have you built it on
> your own? IIRC, the FreeBSD ports version disables some parts of the timeout
> code in curl (and I've never figured out why).

I'm using the FreeBSD ports package.

>> Once I 'kill -9' the process, my program will either segfault or continue to
>> run (depending on what side of the bed it woke up on that day)

> A process cannot survive a kill -9, so I assume you meant a plain "kill" or
> something here.

What I meant here was that I sent a -9 signal to the curl process hoping that MY program would skip this result and continue on it's merry way. No luck with that. I have found however a SIGQUIT (kill -3) gave me the desired continuance.

>> Although it probably won't help in assessing the cause of cURL hanging, I
>> was able to grab a stack trace during a bad hair day:

> You could do two interesting things:
>
> 1 - strace (or whatever the FreeBSD equivalent is called) the live process and
> see what it is doing when it is stuck like this.
>
> 2 - build a debug version (probably using static libcurl) and attach gdb to
> the live process (using gdb -p) and figure out exactly what code it is
> executing and why

I found a FreeBSD port for strace. Here's what I found when I ran it on the hanging curl process: (Darn, I lost the actual error message right now)

The error was something along the lines of:

EMFILE (Too many open files)

This error is in an endless loop. I tried adding file checks and deletions because I thought the temp directory might have been getting filled up, but after a couple of days I'm again getting the error. The temp dir only has around 5 files in it.

For now, I'm going to just add the functionality of the remote script that I'm calling with curl directly into my C program (skipping the curl calls), because we kinda threw the program right into production and it keeps dying on us.

Any ideas from this error, or should I wait until I can paste it verbatim (I had it this morning, but lost it in my paging buffer)?

Thanks again,
Chris