Hello list,
Until I can find out why FCGI processes don’t work, I’m trying to run RT on
its own server with:
sudo /usr/share/request-tracker4/libexec/rt-server --port 8485
but I get an error about SQLite3 not working. The thing is, I have it set
to MySQL, not SQLite, so I don’t know why it’s not using MySQL. I made a
change to /etc/request-tracker4/RT_SiteConfig.pm, and the same to
RT_SiteConfig.d/51-DBConfig, but it didn’t help. I tried
sudo /etc/init.d/request-tracker4 restart
to get the change to register, but had no luck. What do I have to do to get
RT to see configuration changes? This seems like a simple thing, but I
can’t find it online, and the restart doesn’t seem to have helped. If
there’s something obvious I’ve missed in my DB setup that would cause it to
use the wrong backend, I’d love to know that as well. RT4.2.8 on Debian 8.
Thanks.
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com
Did you specify Mysql when you ran the configure script (during
installation)? See step 2 of the README:
https://docs.bestpractical.com/rt/4.4.1/README.htmlOn Tue, 30 Aug 2016 at 06:28 Alex Hall ahall@autodist.com wrote:
Hello list,
Until I can find out why FCGI processes don’t work, I’m trying to run RT
on its own server with:
sudo /usr/share/request-tracker4/libexec/rt-server --port 8485
but I get an error about SQLite3 not working. The thing is, I have it set
to MySQL, not SQLite, so I don’t know why it’s not using MySQL. I made a
change to /etc/request-tracker4/RT_SiteConfig.pm, and the same to
RT_SiteConfig.d/51-DBConfig, but it didn’t help. I tried
sudo /etc/init.d/request-tracker4 restart
to get the change to register, but had no luck. What do I have to do to
get RT to see configuration changes? This seems like a simple thing, but I
can’t find it online, and the restart doesn’t seem to have helped. If
there’s something obvious I’ve missed in my DB setup that would cause it to
use the wrong backend, I’d love to know that as well. RT4.2.8 on Debian 8.
Thanks.
–
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com
RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training
- Boston - October 24-26
- Los Angeles - Q1 2017
Restarting the server should reload the configuration. To confirm what
configuration RT has loaded, you can check the System Configuration page
at Admin > Tools > System Configuration. There you can check
DatabaseType, DatabaseHost, and other Database configuration. If it’s
not what you expect, it could be RT is loading some configuration from
some other location. You can see the config files in the “Loaded config
files” section on that same page.
You set these in RT_Config.pm by selecting different options when
running the initial configure script. After that, you can override in
RT_SiteConfig.pm.On 8/29/16 2:27 PM, Alex Hall wrote:
Hello list,
Until I can find out why FCGI processes don’t work, I’m trying to run RT
on its own server with:
sudo /usr/share/request-tracker4/libexec/rt-server --port 8485
but I get an error about SQLite3 not working. The thing is, I have it
set to MySQL, not SQLite, so I don’t know why it’s not using MySQL. I
made a change to /etc/request-tracker4/RT_SiteConfig.pm, and the same to
RT_SiteConfig.d/51-DBConfig, but it didn’t help. I tried
sudo /etc/init.d/request-tracker4 restart
to get the change to register, but had no luck. What do I have to do to
get RT to see configuration changes? This seems like a simple thing, but
I can’t find it online, and the restart doesn’t seem to have helped. If
there’s something obvious I’ve missed in my DB setup that would cause it
to use the wrong backend, I’d love to know that as well. RT4.2.8 on
Debian 8. Thanks.
–
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com mailto:ahall@autodist.com
RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training
- Boston - October 24-26
- Los Angeles - Q1 2017
So doing
/etc/init.d/nginx restart
is enough to reload RT’s configuration as well? Great, that makes things easier. It seems odd, since I thought Nginx (or whatever your server) was separate from RT and needed the middleware of a FastCGI or similar process to let the two talk. I’m glad I was wrong. 
During the initial setup, I thought I specified the right database engine, but I must have done something wrong. I’ve set it in the config file and it should be working now.
Last I tried, it was still complaining about the SQLite3 not loading, but perhaps I didn’t restart the server after that latest change. I’m away for a couple days, but when I get back to my desk I’ll try it all again.> On Aug 30, 2016, at 08:45, Jim Brandt jbrandt@bestpractical.com wrote:
Restarting the server should reload the configuration. To confirm what configuration RT has loaded, you can check the System Configuration page at Admin > Tools > System Configuration. There you can check DatabaseType, DatabaseHost, and other Database configuration. If it’s not what you expect, it could be RT is loading some configuration from some other location. You can see the config files in the “Loaded config files” section on that same page.
You set these in RT_Config.pm by selecting different options when running the initial configure script. After that, you can override in RT_SiteConfig.pm.
On 8/29/16 2:27 PM, Alex Hall wrote:
Hello list,
Until I can find out why FCGI processes don’t work, I’m trying to run RT
on its own server with:
sudo /usr/share/request-tracker4/libexec/rt-server --port 8485
but I get an error about SQLite3 not working. The thing is, I have it
set to MySQL, not SQLite, so I don’t know why it’s not using MySQL. I
made a change to /etc/request-tracker4/RT_SiteConfig.pm, and the same to
RT_SiteConfig.d/51-DBConfig, but it didn’t help. I tried
sudo /etc/init.d/request-tracker4 restart
to get the change to register, but had no luck. What do I have to do to
get RT to see configuration changes? This seems like a simple thing, but
I can’t find it online, and the restart doesn’t seem to have helped. If
there’s something obvious I’ve missed in my DB setup that would cause it
to use the wrong backend, I’d love to know that as well. RT4.2.8 on
Debian 8. Thanks.
–
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com mailto:ahall@autodist.com
RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training
- Boston - October 24-26
- Los Angeles - Q1 2017
RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training
- Boston - October 24-26
- Los Angeles - Q1 2017
So doing
/etc/init.d/nginx restart
is enough to reload RT’s configuration as well? Great, that makes things
easier. It seems odd, since I thought Nginx (or whatever your server)
was separate from RT and needed the middleware of a FastCGI or similar
process to let the two talk. I’m glad I was wrong.
Sorry, I was too vague in saying “the server”. In a FCGI and nginx
deployment, nginx doesn’t manage FCGI directly, so you’ll need to
restart the FCGI processes. So your understanding was correct for the
nginx configuration. With Apache and FCGI, Apache manages the FCGI
processes, so restarting Apache does both.
Okay, that makes more sense. Now I’m back to my FCGI problem: the process spawns, but netstat shows nothing on the address:port I assign when using the command. I can’t kill or restart it because it doesn’t seem to exist, though I get a success message and can’t spawn a new process on that port until I restart Nginx. Confusing! Yes, this is on a fresh Debian server with nothing but RT, Nginx, Fast-CGI, and supporting libraries installed.> On Aug 30, 2016, at 09:38, Jim Brandt jbrandt@bestpractical.com wrote:
On 8/30/16 9:22 AM, Alex Hall wrote:
So doing
/etc/init.d/nginx restart
is enough to reload RT’s configuration as well? Great, that makes things
easier. It seems odd, since I thought Nginx (or whatever your server)
was separate from RT and needed the middleware of a FastCGI or similar
process to let the two talk. I’m glad I was wrong.
Sorry, I was too vague in saying “the server”. In a FCGI and nginx deployment, nginx doesn’t manage FCGI directly, so you’ll need to restart the FCGI processes. So your understanding was correct for the nginx configuration. With Apache and FCGI, Apache manages the FCGI processes, so restarting Apache does both.
During the initial setup, I thought I specified the right database
engine, but I must have done something wrong. I’ve set it in the config
file and it should be working now.
Last I tried, it was still complaining about the SQLite3 not loading,
but perhaps I didn’t restart the server after that latest change. I’m
away for a couple days, but when I get back to my desk I’ll try it all
again.
Sent from my iPhone
On Aug 30, 2016, at 08:45, Jim Brandt <jbrandt@bestpractical.com mailto:jbrandt@bestpractical.com> wrote:
Restarting the server should reload the configuration. To confirm what
configuration RT has loaded, you can check the System Configuration
page at Admin > Tools > System Configuration. There you can check
DatabaseType, DatabaseHost, and other Database configuration. If it’s
not what you expect, it could be RT is loading some configuration from
some other location. You can see the config files in the “Loaded
config files” section on that same page.
You set these in RT_Config.pm by selecting different options when
running the initial configure script. After that, you can override in
RT_SiteConfig.pm.
On 8/29/16 2:27 PM, Alex Hall wrote:
Hello list,
Until I can find out why FCGI processes don’t work, I’m trying to run RT
on its own server with:
sudo /usr/share/request-tracker4/libexec/rt-server --port 8485
but I get an error about SQLite3 not working. The thing is, I have it
set to MySQL, not SQLite, so I don’t know why it’s not using MySQL. I
made a change to /etc/request-tracker4/RT_SiteConfig.pm, and the same to
RT_SiteConfig.d/51-DBConfig, but it didn’t help. I tried
sudo /etc/init.d/request-tracker4 restart
to get the change to register, but had no luck. What do I have to do to
get RT to see configuration changes? This seems like a simple thing, but
I can’t find it online, and the restart doesn’t seem to have helped. If
there’s something obvious I’ve missed in my DB setup that would cause it
to use the wrong backend, I’d love to know that as well. RT4.2.8 on
Debian 8. Thanks.
–
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com mailto:ahall@autodist.com
mailto:ahall@autodist.com
RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training
- Boston - October 24-26
- Los Angeles - Q1 2017
RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training
- Boston - October 24-26
- Los Angeles - Q1 2017
Maybe post the command you are running to spawn the FCGI processes?
I believe Apache + mod_fcgid is the most common deployment method,
likely by quite a large margin, so more people can probably help with
that configuration. But posting the command may find some nginx users on
the list.On 8/30/16 5:34 PM, Alex Hall wrote:
Okay, that makes more sense. Now I’m back to my FCGI problem: the
process spawns, but netstat shows nothing on the address:port I assign
when using the command. I can’t kill or restart it because it doesn’t
seem to exist, though I get a success message and can’t spawn a new
process on that port until I restart Nginx. Confusing! Yes, this is on a
fresh Debian server with nothing but RT, Nginx, Fast-CGI, and supporting
libraries installed.
Sent from my iPhone
On Aug 30, 2016, at 09:38, Jim Brandt <jbrandt@bestpractical.com mailto:jbrandt@bestpractical.com> wrote:
On 8/30/16 9:22 AM, Alex Hall wrote:
So doing
/etc/init.d/nginx restart
is enough to reload RT’s configuration as well? Great, that makes things
easier. It seems odd, since I thought Nginx (or whatever your server)
was separate from RT and needed the middleware of a FastCGI or similar
process to let the two talk. I’m glad I was wrong.
Sorry, I was too vague in saying “the server”. In a FCGI and nginx
deployment, nginx doesn’t manage FCGI directly, so you’ll need to
restart the FCGI processes. So your understanding was correct for the
nginx configuration. With Apache and FCGI, Apache manages the FCGI
processes, so restarting Apache does both.
During the initial setup, I thought I specified the right database
engine, but I must have done something wrong. I’ve set it in the config
file and it should be working now.
Last I tried, it was still complaining about the SQLite3 not loading,
but perhaps I didn’t restart the server after that latest change. I’m
away for a couple days, but when I get back to my desk I’ll try it all
again.
Sent from my iPhone
On Aug 30, 2016, at 08:45, Jim Brandt <jbrandt@bestpractical.com mailto:jbrandt@bestpractical.com mailto:jbrandt@bestpractical.com> wrote:
Restarting the server should reload the configuration. To confirm what
configuration RT has loaded, you can check the System Configuration
page at Admin > Tools > System Configuration. There you can check
DatabaseType, DatabaseHost, and other Database configuration. If it’s
not what you expect, it could be RT is loading some configuration from
some other location. You can see the config files in the “Loaded
config files” section on that same page.
You set these in RT_Config.pm by selecting different options when
running the initial configure script. After that, you can override in
RT_SiteConfig.pm.
On 8/29/16 2:27 PM, Alex Hall wrote:
Hello list,
Until I can find out why FCGI processes don’t work, I’m trying to
run RT
on its own server with:
sudo /usr/share/request-tracker4/libexec/rt-server --port 8485
but I get an error about SQLite3 not working. The thing is, I have it
set to MySQL, not SQLite, so I don’t know why it’s not using MySQL. I
made a change to /etc/request-tracker4/RT_SiteConfig.pm, and the
same to
RT_SiteConfig.d/51-DBConfig, but it didn’t help. I tried
sudo /etc/init.d/request-tracker4 restart
to get the change to register, but had no luck. What do I have to do to
get RT to see configuration changes? This seems like a simple
thing, but
I can’t find it online, and the restart doesn’t seem to have helped. If
there’s something obvious I’ve missed in my DB setup that would
cause it
to use the wrong backend, I’d love to know that as well. RT4.2.8 on
Debian 8. Thanks.
–
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com mailto:ahall@autodist.com
mailto:ahall@autodist.com
mailto:ahall@autodist.com
RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training
- Boston - October 24-26
- Los Angeles - Q1 2017
RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training
- Boston - October 24-26
- Los Angeles - Q1 2017
Sure. The command is one I found from a guide to Nginx and RT, though I don’t have the link at the moment. It’s simply:
sudo spawn-fcgi -a 127.0.0.1 -p 8485 -u www-data -g www-data /usr/share/request-tracker4/libexec/rt-server.fcgi
It says the server is running, but then I see nothing bound to 127.0.0.1:8485 in netstat.> On Aug 31, 2016, at 08:31, Jim Brandt jbrandt@bestpractical.com wrote:
Maybe post the command you are running to spawn the FCGI processes?
I believe Apache + mod_fcgid is the most common deployment method, likely by quite a large margin, so more people can probably help with that configuration. But posting the command may find some nginx users on the list.
On 8/30/16 5:34 PM, Alex Hall wrote:
Okay, that makes more sense. Now I’m back to my FCGI problem: the
process spawns, but netstat shows nothing on the address:port I assign
when using the command. I can’t kill or restart it because it doesn’t
seem to exist, though I get a success message and can’t spawn a new
process on that port until I restart Nginx. Confusing! Yes, this is on a
fresh Debian server with nothing but RT, Nginx, Fast-CGI, and supporting
libraries installed.
Sent from my iPhone
On Aug 30, 2016, at 09:38, Jim Brandt <jbrandt@bestpractical.com mailto:jbrandt@bestpractical.com> wrote:
On 8/30/16 9:22 AM, Alex Hall wrote:
So doing
/etc/init.d/nginx restart
is enough to reload RT’s configuration as well? Great, that makes things
easier. It seems odd, since I thought Nginx (or whatever your server)
was separate from RT and needed the middleware of a FastCGI or similar
process to let the two talk. I’m glad I was wrong.
Sorry, I was too vague in saying “the server”. In a FCGI and nginx
deployment, nginx doesn’t manage FCGI directly, so you’ll need to
restart the FCGI processes. So your understanding was correct for the
nginx configuration. With Apache and FCGI, Apache manages the FCGI
processes, so restarting Apache does both.
During the initial setup, I thought I specified the right database
engine, but I must have done something wrong. I’ve set it in the config
file and it should be working now.
Last I tried, it was still complaining about the SQLite3 not loading,
but perhaps I didn’t restart the server after that latest change. I’m
away for a couple days, but when I get back to my desk I’ll try it all
again.
Sent from my iPhone
On Aug 30, 2016, at 08:45, Jim Brandt <jbrandt@bestpractical.com mailto:jbrandt@bestpractical.com mailto:jbrandt@bestpractical.com> wrote:
Restarting the server should reload the configuration. To confirm what
configuration RT has loaded, you can check the System Configuration
page at Admin > Tools > System Configuration. There you can check
DatabaseType, DatabaseHost, and other Database configuration. If it’s
not what you expect, it could be RT is loading some configuration from
some other location. You can see the config files in the “Loaded
config files” section on that same page.
You set these in RT_Config.pm by selecting different options when
running the initial configure script. After that, you can override in
RT_SiteConfig.pm.
On 8/29/16 2:27 PM, Alex Hall wrote:
Hello list,
Until I can find out why FCGI processes don’t work, I’m trying to
run RT
on its own server with:
sudo /usr/share/request-tracker4/libexec/rt-server --port 8485
but I get an error about SQLite3 not working. The thing is, I have it
set to MySQL, not SQLite, so I don’t know why it’s not using MySQL. I
made a change to /etc/request-tracker4/RT_SiteConfig.pm, and the
same to
RT_SiteConfig.d/51-DBConfig, but it didn’t help. I tried
sudo /etc/init.d/request-tracker4 restart
to get the change to register, but had no luck. What do I have to do to
get RT to see configuration changes? This seems like a simple
thing, but
I can’t find it online, and the restart doesn’t seem to have helped. If
there’s something obvious I’ve missed in my DB setup that would
cause it
to use the wrong backend, I’d love to know that as well. RT4.2.8 on
Debian 8. Thanks.
–
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com mailto:ahall@autodist.com
mailto:ahall@autodist.com
mailto:ahall@autodist.com
RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training
- Boston - October 24-26
- Los Angeles - Q1 2017
RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training
- Boston - October 24-26
- Los Angeles - Q1 2017