Federated Timeline not refreshing


#1

Federated Timeline doesn’t load new posts, logged out or logged in. It’ll give a one-time “…” button which will refresh it, and after that nothing will load at all until you refresh the page completely.
I noticed it on Mastodon 2.6.2 and updating to 2.6.5 didn’t help.

Looks like the streaming server is erroring out

Could anyone please help me out, because I have no idea what’s causing it.


#2

Do you have WEB_DOMAIN and LOCAL_DOMAIN as the same?


#3

We’ll need more information from the streaming server log file to understand what the error might be.


#4

Yes, I do.

Where do I find it? The log folder is empty.

Welp. Somehow everything on my instance works, except the federated tl, despite the streaming server not running.


#5

I did some digging and found out that I’m using a slightly different nginx config from the one on GitHub.

map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

server {
  listen 80;
  listen [::]:80;
  server_name gameliberty.club;
  root /home/mastodon/live/public;
  # Useful for Let's Encrypt
  location /.well-known/acme-challenge/ { allow all; }
  location / { return 301 https://$host$request_uri; }
}

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name gameliberty.club;

  ssl_protocols TLSv1.2;
  ssl_ciphers HIGH:!MEDIUM:!LOW:!aNULL:!NULL:!SHA;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;

  ssl_certificate     /etc/letsencrypt/live/gameliberty.club/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/gameliberty.club/privkey.pem;

  keepalive_timeout    70;
  sendfile             on;
  client_max_body_size 80m;

  root /home/mastodon/live/public;

  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;

  add_header Strict-Transport-Security "max-age=31536000";

  location / {
    try_files $uri @proxy;
  }

  location ~ ^/(emoji|packs|system/accounts/avatars|system/media_attachments/files) {
    add_header Cache-Control "public, max-age=31536000, immutable";
    try_files $uri @proxy;
  }
  
  location /sw.js {
    add_header Cache-Control "public, max-age=0";
    try_files $uri @proxy;
  }

  location @proxy {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";
    proxy_pass_header Server;

    proxy_pass http://127.0.0.1:3000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  location /api/v1/streaming {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";

    proxy_pass http://127.0.0.1:4000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;


    tcp_nodelay on;
  }

  error_page 500 501 502 503 504 /500.html;
}

When I tried using the one from GitHub, the streaming server still doesn’t turn on, but the instance stops working completely.

Here is error what nginx is logging:
2018/12/09 07:53:12 [error] 18678#18678: *1136000 connect() failed (111: Connection refused) while connecting to upstream, client: x.x.x.x, server: gameliberty.club, request: "GET /api/v1/streaming/?stream=public HTTP/1.1", upstream: "http://127.0.0.1:4000/api/v1/streaming/?stream=public", host: "gameliberty.club"


#6

try to copy your files from /public folder to /var/www/html/ or make sure your user serving nginx have permissions on /home/mastodon/live/public


#7

When I had this problem on 2.6.2 it was due to sidekiq queues getting massively stuck with failed jobs. Check your sidekiq for lots of enqueued jobs.


#8

Owner and group has read, write and execute permissions on /home/mastodon/live/public. Others have read and execute permissions.
Top says that the user running nginx is www-data.

I have 150 failed sidekiq jobs on repeat, because 2 instances I federated with no longer exist, but I doubt that would cause the streaming server to not start.


#9

I just noticed that yarn spat out an error when I was updating Mastodon.
https://pastebin.com/s2BaCnMR


#10

I solved it. For some reason I didn’t have npm installed, so I just installed it and it works.


#11