You are still getting processes and threads confused. If a thread dies due to a signal, such as a segmentation violation, the process dies. This is the way it works. We could ignore the signal, but that is like ignoring that fact that one of your pistons is blown and continuing to drive - you may get further down the road, but it wont be pretty and eventually your engine will explode.
If Chad needs support, he will have to contact Macromedia support. I post on the list to help out and make suggestions. There are several good KB articles on the Macromedia support web site that talk about diagnosing server crashes. As I said in my first message, the problem is most likely due to improper locking of session, application or server scope CFML variables. Chad should turn on full lock checking in the Administrator, then run through his application looking for problems. -- Tom Jordahl -----Original Message----- From: Mark Leonard [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 4:17 PM To: CF-Linux Subject: RE: cfserver getting sig 11. > I think you are getting confused about threads and children. > In Linux, threads are sort-of processes. They have a pid (and > show up in ps, yuk!), but they are not really separate processes. > They share the same address space. Hold on a second. What Chad has found is the following: if one thread dies, it causes the daemon to die. Having done a fair bit of thread programming myself, this does not make sense. A thread (child) should have enough intelligence in order to detect a problem WITHOUT causing or signalling the daemon (parent) to die. Concurrency issues don't exist in the case of tracking threads - only the treads themselves ever need to report (write) their status, and the daemon (parent) is the only entity that should ever need to see (read) the status of the threads. Anyway, this is getting way off topic. The problem of sig11/sig6 restarts still remains. If Chad has not yet provided sufficient information for you to diagnose the problem, then let us know. > You will probably not be able to diagnose your problems 'from > below' as you are trying to do. You will probably need to > examine your ColdFusion CFML application. We have over 12,800 CFML files on this particular server. Many of which are provided directly by our clients. This machine hosts over 200 clients. In order to avoid the locking issues that ColdFusion seems to have, we have enabled single-threaded sessions. If the problem truly is bad CFML, why is the daemon not reporting the suspect file? Furthermore, how and WHY would bad markup cause a daemon to die? I look forward to your reply. ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm ------------------------------------------------------------------------------ Archives: http://www.mail-archive.com/cf-linux%40houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_linux or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
