[rt-users] Applying configuration changes?

[Alex Hall]

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 at 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 at bestpractical.com
>> <mailto:jbrandt at 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 at autodist.com <mailto:ahall at autodist.com>
>>>> <mailto:ahall at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20160830/30f0c966/attachment.htm>