Post action and fastcgi 'Broken pipe' problem.

[giv@…]

Trac 0.10 started at lighttpd server (1.4.12) as fastcgi.

Here is error log:

Unhandled exception in thread started by <bound method Connection.run of <trac.web._fcgi.Connection object at 0x83f504c>>
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/site-packages/trac/web/_fcgi.py", line 654, in run
    self.process_input()
  File "/usr/local/lib/python2.4/site-packages/trac/web/_fcgi.py", line 690, in process_input
    self._do_params(rec)
  File "/usr/local/lib/python2.4/site-packages/trac/web/_fcgi.py", line 789, in _do_params
    self._start_request(req)
  File "/usr/local/lib/python2.4/site-packages/trac/web/_fcgi.py", line 773, in _start_request
    req.run()
  File "/usr/local/lib/python2.4/site-packages/trac/web/_fcgi.py", line 582, in run
    self._flush()
  File "/usr/local/lib/python2.4/site-packages/trac/web/_fcgi.py", line 589, in _flush
    self.stdout.close()
  File "/usr/local/lib/python2.4/site-packages/trac/web/_fcgi.py", line 348, in close
    self._conn.writeRecord(rec)
  File "/usr/local/lib/python2.4/site-packages/trac/web/_fcgi.py", line 705, in writeRecord
    rec.write(self._sock)
  File "/usr/local/lib/python2.4/site-packages/trac/web/_fcgi.py", line 542, in write
    self._sendall(sock, header)
  File "/usr/local/lib/python2.4/site-packages/trac/web/_fcgi.py", line 519, in _sendall
    sent = sock.send(data)
socket.error: (32, 'Broken pipe')

And fastcgi server settigs:

        fastcgi.server             = ( "/" =>
                                   ("trac" =>
                                     ("socket"          => "/tmp/trac-fastcgi.sock",
                                      "bin-path"        => "/usr/local/share/trac/cgi-bin/trac.fcgi",
                                      "check-local"     => "disable",
                                      "disable-time"    => 1,
                                      "min-procs"       => 1,
                                      "max-procs"       => 1,
                                      "bin-environment" =>
                                          ("TRAC_ENV" => "/home/dev/trac")
                                     )
                                   )
                                 )

[giv@…]

Yep! This error is the result of ticket or wiki page submiting.

[Christian Boos]

(fixing description, it should have been {{{ ... }}} not {{ ... }})

[sineer@…]

I got the same problem running lighttpd-1.4.13 on debian etch.

The same error output is shown when I Login (usind the Trac DBAuth plugin that contacts a remote SQL server).

It doesn't occur however on the trac site where my auth SQL db is located…

On one site the login works even too I get this error msg. On the other site I cannot get the authentification to work :(

[nightinthecity@…]

same here

Unhandled exception in thread started by <bound method Connection.run of <trac.web._fcgi.Connection object at 0x412fd26c>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/_fcgi.py", line 654, in run
    self.process_input()
  File "/usr/lib/python2.3/site-packages/trac/web/_fcgi.py", line 690, in process_input
    self._do_params(rec)
  File "/usr/lib/python2.3/site-packages/trac/web/_fcgi.py", line 789, in _do_params
    self._start_request(req)
  File "/usr/lib/python2.3/site-packages/trac/web/_fcgi.py", line 773, in _start_request
    req.run()
  File "/usr/lib/python2.3/site-packages/trac/web/_fcgi.py", line 582, in run
    self._flush()
  File "/usr/lib/python2.3/site-packages/trac/web/_fcgi.py", line 589, in _flush
    self.stdout.close()
  File "/usr/lib/python2.3/site-packages/trac/web/_fcgi.py", line 348, in close
    self._conn.writeRecord(rec)
  File "/usr/lib/python2.3/site-packages/trac/web/_fcgi.py", line 705, in writeRecord
    rec.write(self._sock)
  File "/usr/lib/python2.3/site-packages/trac/web/_fcgi.py", line 542, in write
    self._sendall(sock, header)
  File "/usr/lib/python2.3/site-packages/trac/web/_fcgi.py", line 519, in _sendall
    sent = sock.send(data)
socket.error: (32, 'Broken pipe')

lighttpd-1.4.3 (ssl) - a light and fast webserver Build-Date: Sep 1 2005 17:43:12 with trac-0.10

$HTTP["host"] =~ "localhost" {
  server.document-root = "/var/www3"
  fastcgi.server = ( "/trac" =>
    ( "trac" =>
      ( "socket" => "/tmp/fcgi.socket",
        "check-local" => "disable",
        "min-procs" => 1,
        "max-procs" => 1,
        "bin-path"  => "/usr/share/trac/cgi-bin/trac.fcgi",
        "bin-environment" => ( "TZ" => "EST5EDT","TRAC_ENV"=>"/var/www3",
                               "TRAC_ENV_PARENT_DIR" => "/var/www3" )
      )
    )
  )
  alias.url = ( "/trac/chrome/common" => "/usr/share/trac/htdocs" )
  auth.debug = 2
  server.errorlog = "/tmp/error.log"

  $HTTP["url"] =~ "^/trac/login" {
  auth.backend = "htpasswd"
  auth.backend.htpasswd.userfile = "/var/www3/trac.passwd"
  auth.require = ("/trac/login" => (
     "method"  => "basic",
     "realm"   => "admin",
     "require" => "valid-user"
  ))
 }
}

wonder if i should downgrade trac or lighttpd (seems a fastcgi error). any resolution?

[wkornewald]

Just for the log: Related to #3957 and #3369

[Christian Boos]

I would be interested to know if 0.10.4 helps here.

[anonymous]

Replying to cboos:

I would be interested to know if 0.10.4 helps here.

It doesn't appear to help me — running 0.10.4 on lighttpd using FCGI, on Ubuntu Dapper. Incidentally, it only started happening after I turned on e-mail notification for tickets (using smtp_always_bcc, if that's important).

[mpalmer@…]

Replying to anonymous:

Replying to cboos:

I would be interested to know if 0.10.4 helps here.

It doesn't appear to help me — running 0.10.4 on lighttpd using FCGI, on Ubuntu Dapper. Incidentally, it only started happening after I turned on e-mail notification for tickets (using smtp_always_bcc, if that's important).

False alarm on that one — I've turned off e-mail notifications again and it's still bombing out. I don't recall it ever having problems before, though, which is very weird.

[mpalmer@…]

Reviewing the related tickets (#3957 and #3369), there's a few things that people have suggested that aren't the case for me:

• It isn't a MySQL connection error (#3957), because I'm not using MySQL (SQLite in my case for the Trac data, and htpasswd for the auth store);
• It's not any sort of excessive timeout (#3369), because I get the page displayed properly (and the traceback) pretty much immediately (less than a second);
• I'm not seeing any errors in my browser — everything works fine there, it's just the tracebacks in the log and a lack of e-mail being sent (when I've got that turned on, although the tracebacks are universal).

I can confirm that the backtrace only occurs for POST requests (I can click around the Trac instance for as long as I want without a problem, but I get a traceback on every POST). That seems like it should be a big clue, but I've no idea what it signifies…

[osimons <simon-code@…>]

Not sure it is any help, but I have two things you can try:

1. Set the base_url option - see TracIni for details.
2. Try setting environment variable HTTPS to 1 - as per suggestion at TracModPython. This setting is not really mod_python specific as it is read by the WSGI code that is shared between all frontends.

[anonymous]

Replying to osimons <simon-code@bvnetwork.no>:

Not sure it is any help, but I have two things you can try:

1. Set the base_url option - see TracIni for details.
2. Try setting environment variable HTTPS to 1 - as per suggestion at TracModPython. This setting is not really mod_python specific as it is read by the WSGI code that is shared between all frontends.

Thanks for the suggestions, but unfortunately I've already got base_url set, I'm not running Trac under HTTPS at all, and setting HTTPS to 1 didn't change anything…

[mpalmer@…]

Oooh, here's an interesting data point: if I go to edit a wiki page and just click 'Submit Changes' without changing anything, it produces the "Page Not Modified" internal error, but more importantly, it doesn't produce a backtrace.

[Tim Hatch]

I'd just like to note that I get these too on my server using lighty+fastcgi (0.11-dev). It seems to happen on any redirect (after post), and I just noticed them with tracd (0.11-dev) on a chrome 404.

The client has been Firefox 2.0.0.12 on Gentoo Linux or FreeBSD. I can also reproduce by refreshing a page several times in quick succession… which makes me think this is the behavior of Firefox when it doesn't care what data is in the body of the response. I can trigger both "Broken pipe" (32) and "Connection reset by peer" (54) by refreshing.

[osimons]

#7271 closed as duplicate. It contains a suggested patch to ignore these errors in comment:ticket7271:2. Anyone able to test the patch?

[Christian Boos]

Tim, does that still happen with recent versions?

[Christian Boos]

For the 'Broken pipe' in _fcgi.py line 519, see #3957 (that ticket is not restricted to the possible cause of a timeout with MySQL).