Javascript Errors - looks like files are truncated

(Dorthu) #1

Hello! I have a discourse instance running at configured as described here to run alongside another site on the same box. Yesterday I was told that the site wasn’t loading, and was baffled to find that it indeed produces javascript errors when visited:

(The full file lives here and is indeed truncated)

Examining the files that it complains about, it looks like they’re truncated:

I have tried:

  • Rebuilding
  • clobbering and precompiling assets
  • revisiting nginx configs/restarting nginx
  • Looking at the files in assets/public/ - they don’t appear truncated here.
  • Examining log files - production_errors.log is empty, production.log seems to be fine, unicorn logs appear okay as well.

My branch is up to date with origin/tests-passed. My instance is self-hosted on a Linode following the instructions here. I don’t have any plugins installed (except docker manager, which came with the package).

I’m at a loss of what the next steps to debug this are - any ideas?

(YOU) #2

I can see until in your link

 //# sourceMappingURL=/assets/

May be your browser extensions interrupting those?

(Dorthu) #3

I’m thinking this is an issue with the socket/nginx. I tried a wget on one of the files that is truncated, to find:

dorthu@home::~$ wget
--2015-10-25 11:33:36--
Resolving, 2600:3c03::f03c:91ff:fe67:cf34
Connecting to||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 943348 (921K) [application/javascript]
Saving to: 'vendor-d726f166eae32585d948cc4b83590d33.js.1'

vendor-d726f166eae32585d948cc4b83590d33.js.   8%[======>                                                                                    ]  76.96K  --.-KB/s   in 0.1s

2015-10-25 11:33:36 (758 KB/s) - Connection closed at byte 78805. Retrying.

--2015-10-25 11:33:37--  (try: 2)
Connecting to||:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 943348 (921K), 864543 (844K) remaining [application/javascript]
Saving to: 'vendor-d726f166eae32585d948cc4b83590d33.js.1'

vendor-d726f166eae32585d948cc4b83590d33.js.  16%[+++++++=======>                                                                            ] 153.88K  --.-KB/s   in 0.08s

2015-10-25 11:33:37 (909 KB/s) - Connection closed at byte 157577. Retrying.

--2015-10-25 11:33:39--  (try: 3)
Connecting to||:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 943348 (921K), 785771 (767K) remaining [application/javascript]
Saving to: 'vendor-d726f166eae32585d948cc4b83590d33.js.1'

vendor-d726f166eae32585d948cc4b83590d33.js.  25%[+++++++++++++++======>                                                                     ] 230.81K  --.-KB/s   in 0.09s

2015-10-25 11:33:39 (870 KB/s) - Connection closed at byte 236348. Retrying.

On the server I see this in the nginx logs: - - [25/Oct/2015:11:33:36 -0400] "GET /assets/vendor-d726f166eae32585d948cc4b83590d33.js HTTP/1.1" 200 78805 "-" "Wget/1.16.1 (darwin14.0.0)" - - [25/Oct/2015:11:33:37 -0400] "GET /assets/vendor-d726f166eae32585d948cc4b83590d33.js HTTP/1.1" 206 78772 "-" "Wget/1.16.1 (darwin14.0.0)" - - [25/Oct/2015:11:33:39 -0400] "GET /assets/vendor-d726f166eae32585d948cc4b83590d33.js HTTP/1.1" 206 78771 "-" "Wget/1.16.1 (darwin14.0.0)"

I tried removing the web.socketed.template and exposing the discourse through port 8001, and lo and behold it comes right up.

Here’s my nginx config file (straight from the above linked tutorial):

server {
    listen 80; listen [::]:80;

    location / {
        proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
        proxy_set_header Host $http_host;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

And I’m not gonna paste by app.yml here, but the relevant bit is:

  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/sshd.template.yml"
  - "templates/web.ratelimited.template.yml"
  - "templates/web.socketed.template.yml"

(Dorthu) #4

Got some more time to look at this, and I’ve switching it to a different state - now the site is not using the suggested web.socketed.template and is instead listening on localhost:8001

  - "8001:80"   # fwd host port 8001 to container port 80 (http)

and nginx is forwarding to localhost:8001 as per:

server {
    listen 80;
    listen [::]:80;


    location / {

and the javascript still produces errors.

But bizarrely, loading works fine. I’m stumped, but will continue to bump this thread with anything I find. Any thoughts are appreciated.

(Kane York) #5

What options are in nginx’s http block?

(Dorthu) #6

I think it’s stock:

http {

        # Basic Settings

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        # SSL Settings

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        # Logging Settings

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        # Gzip Settings

        gzip on;
        gzip_disable "msie6";

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        # Virtual Host Configs

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;

(Dorthu) #7

I tracked this down to a permissions issue in /var/lib/nginx/proxy - although I am now routing with a local port through nginx, instead of the recommended socket method (which was not resolved by fixing permissions, or anything I tried). Thanks for the feedback.