It could also be some sort of print statement in the code. sys.stdout and sys.stderr don't exist under mod_wsgi, but they do in gearbox.
On Tue, Jun 16, 2015 at 12:00 PM Paul Kraus <[email protected]> wrote: > Actually here are the order of events. > Form accepts file upload, file is parsed and written to a database table > where error checking is done against the data to make sure its cleaned up > and able to be sent to our legacy system. The user is then presented with a > view of the data and any information they need to decide what changes > should be bad to bad data. If everything is good they click import, it > reads the records from the table, and using odbc writes them to the legacy > system. > > So its happening after all of the file stuff. > > Paul Kraus > IT Director / Project Management Director > (216) 916.9801 Direct Dial > (216) 267.6176 Fax > www.pelsupply.com > > On Tue, Jun 16, 2015 at 11:35 AM, Paul Kraus <[email protected]> wrote: > >> It does, and that's excellent. Would it keep the same file name, what >> would be the default location of the file? >> >> Paul Kraus >> IT Director / Project Management Director >> (216) 916.9801 Direct Dial >> (216) 267.6176 Fax >> www.pelsupply.com >> >> On Tue, Jun 16, 2015 at 11:34 AM, lebouquetin <[email protected]> >> wrote: >> >>> If your form uses a <input type="file"> for choosing a file, then the >>> uploaded file is written to a temporary directory and what Michael said is >>> that you might get an error because apache user is not allowed. Right >>> access is a classical case of errors when wsgi-ing your app while running >>> it with gearbox serve (which, I assume you run as root) >>> >>> Damien >>> >>> >>> Le mardi 16 juin 2015 16:57:53 UTC+2, Paul Kraus a écrit : >>>> >>>> I thought it might be something different between my virtualenv on my >>>> dev box and the virtualenv being using by modwsgi on the production server. >>>> So i loaded the app up using gearbox serve -c development.ini with the same >>>> virtualenv as the production server, and no issues. So it only seems to >>>> blow up when using apache2/modwsgi. >>>> >>>> Very frustrating. >>>> >>>> On Tuesday, June 16, 2015 at 10:39:53 AM UTC-4, Paul Kraus wrote: >>>>> >>>>> I don't actually read or write the file from the file system. It's >>>>> imported via a form and then processed. I examined the app log and that's >>>>> what i received below but i just now tested it again and examined the >>>>> apache error log and this happens at the exact same moment ... >>>>> >>>>> [core:notice] [pid 45371:tid 139899616245632] AH00094: Command line: >>>>> '/usr/sbin/apache2' >>>>> [core:notice] [pid 45371:tid 139899616245632] AH00051: child pid 45375 >>>>> exit signal Segmentation fault (11), possible coredump in /etc/apache2 >>>>> [core:notice] [pid 45371:tid 139899616245632] AH00051: child pid 55064 >>>>> exit signal Segmentation fault (11), possible coredump in /etc/apache2 >>>>> >>>>> >>>>> On Tuesday, June 16, 2015 at 10:21:57 AM UTC-4, Paul Kraus wrote: >>>>>> >>>>>> I have an internal web application that imports some records via csv >>>>>> and then imports them into our legacy systems database using ODBC. The >>>>>> click the import button it goes to just a normal @expose() method that >>>>>> does >>>>>> the import and when finished redirects to a results page. No multithread >>>>>> or >>>>>> async stuff going on. In development it just works without issues. On our >>>>>> production server it dies with an error 500 and watching the logs this is >>>>>> the error produced... >>>>>> >>>>>> >>>>>> [core:error] [pid 45376:tid 139899256612608] [client 10.0.7.1:50186] >>>>>> End of script output before headers: app.wsgi >>>>>> >>>>>> Kind of getting twisted around the axle here so any help would be >>>>>> greatly appreciated. >>>>>> >>>>>> >>>>>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "TurboGears" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/turbogears/VHKKc0iN1F4/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/turbogears. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- > You received this message because you are subscribed to the Google Groups > "TurboGears" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/turbogears. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/turbogears. For more options, visit https://groups.google.com/d/optout.
