# System exit by fcgi during multiple database transactions

**URL:** <https://www.ruby-forum.com/t/system-exit-by-fcgi-during-multiple-database-transactions/135757>\
**Category:** Rails\
**Created:** [April 24, 2008, 6:31pm UTC](https://www.ruby-forum.com/t/system-exit-by-fcgi-during-multiple-database-transactions/135757 "2008-04-24T18:31:20Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![peterbe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/bc79bd/32.png) [@peterbe](https://www.ruby-forum.com/u/peterbe)\
**Post date:** [April 24, 2008, 6:31pm UTC](https://www.ruby-forum.com/t/system-exit-by-fcgi-during-multiple-database-transactions/135757/1 "2008-04-24T18:31:20Z")

</div>

I have a RoR application where user can upload a CSV; each row has  
fields which  
are written to several dbase tables.

My problem is with large CSVs which require several thousand inserts.

Under WebBrick, the operation completes without error.

Under fcgi, the fcgi issues a System:exit at seemingly random points  
(not associated  
with any particular database operation). If I reduce the size of the  
CSV, it completes  
without error.

All my database operations use SQL so there is no object  
instantiation. I did this  
thinking that memory might be the issue.

Has anyone seen this before? How did you fix the problem?

Thanks in advance,  
Peter

---

<div class="post-metadata">

**Author:** ![peterbe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/bc79bd/32.png) [@peterbe](https://www.ruby-forum.com/u/peterbe)\
**Post date:** [April 24, 2008, 6:39pm UTC](https://www.ruby-forum.com/t/system-exit-by-fcgi-during-multiple-database-transactions/135757/2 "2008-04-24T18:39:34Z")

</div>

On 24 Apr 2008, at 17:30, peterbe wrote:

> (not associated  
> with any particular database operation). If I reduce the size of the  
> CSV, it completes  
> without error.
> 
> All my database operations use SQL so there is no object  
> instantiation. I did this  
> thinking that memory might be the issue.
> 
> Has anyone seen this before? How did you fix the problem?

We used to have fastcgi listeners dieing randomly every now and again.  
In the end we switched away from fast cgi 🙂

Fred
