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 <jbra...@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 <jbra...@bestpractical.com >> <mailto:jbra...@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 >>>> ah...@autodist.com <mailto:ah...@autodist.com> >>>> <mailto:ah...@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
--------- RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training * Boston - October 24-26 * Los Angeles - Q1 2017