Howdy,

I am doing a long-running operation in a PHP app and getting a 504 gateway time-out error from Nginx. Since I'm using Apache as my web server, I assume this is coming from the built-in reverse proxy. Looks like that conf file has a keepalive_timeout 65; line. Is there any way to modify this like we can modify other stacks? I'd like to bump this timeout up quite a bit. I'm seeing config files where this could potentially go (e.g. /Users/{myUserName}/.indigo/stacks/system-stack/nginx_reverse_proxy/conf/sites-enabled/), but not sure I can safely edit those files.

    ....I'm just going to self answer this like an SO post for future people. Found the answer minutes after posting. 🤦‍♂️

    Quote:

    You can actually override the config for the system stack services, in a similar manner to the stack's services. You just prefix those services with system/ ie inside your .indigostack bundle, you need a file structure like so:

system/nginx_reverse_proxy/conf/sites-enabled/custom.conf

...or you can override an existing conf using that file structure as a guide.

    (Suggestion: Add this to the docs?)

    Thanks for posting the solution above 🙂

    Deadpikle I am doing a long-running operation in a PHP app

    Just a heads-up that you can bypass the reverse proxy if you want to, by referencing your app directly by its port. This is the primary reason for allowing non-auto port numbers — so you can know for sure what it will always be available at. Not sure if this is appropriate in your use-case though.

    I should clarify that the ability to override the system stack's config does work as described in your solution above, but carries one significant limitation at present, hence me not putting it in the docs at this point. The limitation is this: only the last-started stack's system overrides will be used.

    So for example, say I have two stacks, where only stack A provides system stack overrides; if I start up stack A, the system stack is rebuilt using the overrides in stack A — all good at this point. If I then start stack B, the system stack is rebuilt using any overrides in stack B, of which there are none. At this point stack A's overrides have been removed.

    Two things come to mind:

    a) I do think at some point I should add code so the system stack compiles the overrides found in all currently-starting/started stacks. Although then there's the question of precedence. The best way to handle this whole topic is a little undefined in my mind at present — tbh I was rather hoping nobody would need to override the system stack, although I personally do need to (lol). So I'm definitely interested in others' thoughts.

    b) I wonder if the default keepalive_timeout could/should be made arbitrarily large eg 5 minutes. What do you think?

    tldr; if your system-level overrides disappear, restart the stack that defines them and they will be recompiled into the system stack.

        Indigo

        I wonder if the default keepalive_timeout could/should be made arbitrarily large eg 5 minutes. What do you think?

        Personally, and perhaps this is just me, I would expect any timeouts, file max upload sizes, etc. to be controlled by the stacks that I personally have set up (and that have docs on how to override), not the system stack. So I would probably say that the keepalive timeout and similar should be made a lot larger than they are currently with perhaps some UI thing somewhere or something in the docs on how to get around that if one needs to do so.

          9 days later

          I resonate with your thinking, but the issue is that the system stack is where such config resides, and if you override it per-stack then the system stack may not operate how you want it to for ALL your stacks. The system stack really does need to carry a generic config suitable for all stacks.

          @Deadpikle can I ask what you ended up increasing your keepalive_timeout to?

          Powered by: FreeFlarum.
          (remove this footer)