RT4.0.1 post-upgrade rt-server.fcgi won't start

RT Users
1

Followed the instructions in README: did configure, make upgrade, updated schema, now rt-server.fcgi+lighttpd is broken.

Lighttpd error log only says:

2011-06-23 15:09:24: (log.c.166) server started

2011-06-23 15:09:24: (mod_fastcgi.c.1104) the fastcgi-backend /opt/rt4/sbin/rt-server.fcgi failed to start:

2011-06-23 15:09:24: (mod_fastcgi.c.1108) child exited with status 255 /opt/rt4/sbin/rt-server.fcgi

2011-06-23 15:09:24: (mod_fastcgi.c.1111) If you’re trying to run your app as a FastCGI backend, make sure you’re using the FastCGI-enabled version.

If this is PHP on Gentoo, add ‘fastcgi’ to the USE flags.

2011-06-23 15:09:24: (mod_fastcgi.c.1399) [ERROR]: spawning fcgi failed.

2011-06-23 15:09:24: (server.c.938) Configuration of plugins failed. Going down.

I can verify that manually executing rt-server.fcgi fails, as in:

[root@rt ~]# /opt/rt4/sbin/rt-server --port 9000

Plack::Handler::Starlet: Accepting connections at http://0:9000/

versus:

[root@rt ~]# /opt/rt4/sbin/rt-server.fcgi --port 9000

WARNING: RT couldn’t start up a web server on port 9000.

This is often the case if the port is already in use or you’re running /opt/rt4/sbin/rt-server.fcgi

as someone other than your system’s “root” user. You may also specify a

temporary port with: /opt/rt4/sbin/rt-server.fcgi --port

Please check your system configuration or choose another port

(And yes, I made sure nothing else was listening on port 9000. The .fcgi version won’t start on any port.)

Also confirmed I used the same ./configure line for both 4.0.0 and 4.0.1,

( from config.status, of either: )

ac_cs_config=“‘–enable-graphviz’ ‘–enable-gd’ ‘–enable-gpg’ ‘–with-web-handler=fastcgi’ ‘–with-db-type=Pg’”

Nothing changed in my lighttpd setup, nor in my Pg setup… help? What debugging should I be enabling to help narrow this down?

(Luckily, in the meantime, I just revert to using rt-server again.)

-Adam Thompson

mailto:athompso@athompso.net athompso@athompso.net

(204) 291-7950 - direct

(204) 489-6515 - fax

2

Followed the instructions in README: did configure, make upgrade,
updated schema, now rt-server.fcgi+lighttpd is broken.

Lighttpd error log only says:

What does the RT error log say? What does your lighttpd configuration
look like?

I can verify that manually executing rt-server.fcgi fails, as in:

This also happens with RT 4.0.0; for questionable reasons,
rt-server.fcgi ignores the --port option entirely, and thus produces a
spurious warning about the port being already in use. This should be
fixed in 4.0.2, and rt-server.fcgi should become usable as an external
fcgi process. Until then, it will only function if its STDOUT is
attached to a pipe.

  • Alex
3

Well, as I said, nothing really changed. CentOS 5.6 with lighttpd from
RPMForge. The following config block was appended to
/etc/lighttpd/conf.d/fastcgi.conf:

alias.url = (
        "/NoAuth/images/" => "/opt/rt4/share/html/NoAuth/images/",
)
$HTTP["url"] !~ "^/NoAuth/images/" {
        fastcgi.server = (
                "/" => (
                        "rt" => (
                                "port"        => "9000",
                                "bin-path"    =>

“/opt/rt4/sbin/rt-server.fcgi”,
“check-local” => “disable”,
“fix-root-scriptname” => “enable”,
)
)
)
}

What RT error log? I included everything lighttpd logged, and RT didn’t
log anything except what I showed, not to stderr, nor syslog, nor any
file. (Hence my question about what would be useful to turn on for
debugging here…)

I turned LogToScreen and LogToSyslog both up to “debug”, but still nothing
shows up anywhere… it’s as though something is failing around exec(2)
rather than inside the RT fcgi daemon, but everything looks ok, and as
I’ve reiterated, it worked fine under 4.0.0.

Thanks,
-Adam Thompson
athompso@athompso.net
(204) 291-7950 - direct
(204) 489-6515 - fax

4

What RT error log? I included everything lighttpd logged, and RT didn’t
log anything except what I showed, not to stderr, nor syslog, nor any
file. (Hence my question about what would be useful to turn on for
debugging here…)

Turning LogToFile or LogToSyslog to debug is the right knob. That
they’re not getting anything written to them implies that the
configuration file is failing to be read. Are the permissions
on /opt/rt4/etc/RT_Config.pm and /opt/rt4/etc/RT_SiteConfig.pm what you
expect? Are the permission on /opt/rt4/var/mason_data correct?

If you’re running rt-server as root, like you demonstrate, you’re likely
creating directories and files owned by root, which the fastcgi process
under lighttpd, running as www-data, won’t be able to cope with.

I turned LogToScreen and LogToSyslog both up to “debug”, but still nothing
shows up anywhere… it’s as though something is failing around exec(2)
rather than inside the RT fcgi daemon, but everything looks ok, and as
I’ve reiterated, it worked fine under 4.0.0.

I can’t replicate this. Unfortunately, due to
Bug #499: FastCGI stderr output doesn't go to error log - Lighttpd - lighty labs , it’s hard to get debugging
information out of a fastcgi process before it’s read the config file,
so you may have to resort to:

strace -ff -o lighttpd.strace
/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf

…and examining the files for the fcgi children that are spawned.

  • Alex
5

Turning LogToFile or LogToSyslog to debug is the right knob. That
they’re
not getting anything written to them implies that the configuration file
is
failing to be read. Are the permissions on /opt/rt4/etc/RT_Config.pm
and /opt/rt4/etc/RT_SiteConfig.pm what you expect? Are the
permission on /opt/rt4/var/mason_data correct?

Good guess! (I know it’s not a guess, you know what I mean…)

The problem was that ./configure had guessed my webserver userid as
“apache”, when it’s now “lighttpd” instead. So when I did “make upgrade”,
one of the commands that was executed was “chgrp -R apache /opt/rt4/etc”.
I forgot I had manually changed ownerships after switching from apache to
lighttpd.

Easy fix: “chown -R --from=:apache :lighttpd /opt/”

Thanks for the pointers, seems to be working OK now.

-Adam Thompson
athompso@athompso.net
(204) 291-7950 - direct
(204) 489-6515 - fax

6

The problem was that ./configure had guessed my webserver userid as
“apache”, when it’s now “lighttpd” instead. So when I did “make upgrade”,
one of the commands that was executed was “chgrp -R apache /opt/rt4/etc”.
I forgot I had manually changed ownerships after switching from apache to
lighttpd.

Easy fix: “chown -R --from=:apache :lighttpd /opt/”

For future reference, the --with-web-user=USER and
–with-web-group=GROUP options to ./configure would cause
upgrade/install to do the right thing.

Thomas