Missing file(discourse.conf) when launching after lets encrypt update?

All I did was add in the extra two templates and try to relaunch the app and now I’m having this issue. The other templates seem to be set up pointing to this exact location. So I guess it’s being removed somehow.

This is the lets encrypt instruction list I followed.

Could anyone possibly point me in the right direction please?

Std out and error:

59:M 05 Mar 16:22:52.181 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
    159:M 05 Mar 16:22:52.181 # Server started, Redis version 3.0.6
    159:M 05 Mar 16:22:52.182 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
    159:M 05 Mar 16:22:52.182 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
    159:M 05 Mar 16:22:52.188 * DB loaded from disk: 0.006 seconds
    159:M 05 Mar 16:22:52.189 * The server is now ready to accept connections on port 6379
    I, [2018-03-05T16:23:02.181963 #13]  INFO -- :
    I, [2018-03-05T16:23:02.182422 #13]  INFO -- : Terminating async processes
    I, [2018-03-05T16:23:02.182463 #13]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/9.5/bin/postmaster -D /etc/postgresql/9.5/main pid: 44
    I, [2018-03-05T16:23:02.182502 #13]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 159
    2018-03-05 16:23:02.182 UTC [44] LOG:  received fast shutdown request
    2018-03-05 16:23:02.182 UTC [44] LOG:  aborting any active transactions
    2018-03-05 16:23:02.184 UTC [51] LOG:  autovacuum launcher shutting down
    2018-03-05 16:23:02.186 UTC [48] LOG:  shutting down
    159:signal-handler (1520266982) Received SIGTERM scheduling shutdown...
    2018-03-05 16:23:02.191 UTC [48] LOG:  database system is shut down
    159:M 05 Mar 16:23:02.203 # User requested shutdown...
    159:M 05 Mar 16:23:02.204 * Saving the final RDB snapshot before exiting.
    159:M 05 Mar 16:23:02.213 * DB saved on disk
    159:M 05 Mar 16:23:02.213 # Redis is now ready to exit, bye bye...


    FAILED
    --------------------
    Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/nginx/conf.d/discourse.conf
    Location of failure: /pups/lib/pups/replace_command.rb:8:in `read'
    replace failed with the params {"filename"=>"/etc/nginx/conf.d/discourse.conf", "from"=>"/server.+{/", "to"=>"limit_req_zone $binary_remote_addr zone=flood:10m rate=$reqs_per_secondr/s;\nlimit_req_zone $binary_remote_addr zone=bot:10m rate=$reqs_per_minuter/m;\nlimit_req_status 429;\nlimit_conn_zone $binary_remote_addr zone=connperip:10m;\nlimit_conn_status 429;\nserver {\n"}
    f2c07371dd5260ed32f521672ebfd8958950311878495bac43a2f870669f464c
    ** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one

Did you to it by hand, or did you take advantage of this:

1 Like

by hand :’(

BUT! I might have messed up the order of the templates when I uncommented to ssl related ones. Anyways, I rebuilt and restarted - got things up and running.

The problem I am now having is that it redirects to an https url fine… but then that response times out of gives me an

ERR_EMPTY_RESPONSE # in the google web browser(mobile - 4g).

it just timeouts out on a normal pc though. I have checked the nginx access(and error) and access.letsencrypt.log logs and the redirect is succesful but then nothing after that. No logs in Rails come up.
Maybe this is another question and should open a new topic. I don’t want to muddle things for other people reading this.

Just to update - this was fixed by adding a missing rule on the fire wall for https traffic on port 443.

4 Likes

This topic was automatically closed after 25 hours. New replies are no longer allowed.