Flood hangs after logging in, but "works" when quitting rtorrent?

[NoLooseEnds]

Your Environment

• Version used:
  • Version (stable release) Latest version pulled from git
• Environment name and version:
  • Node.js version 8.14.0
  • npm version 6.4.1
  • Web browser Chrome 71.0.3578.98 (Official Build) (64-bit)
• Operating System and version: Alpine Linux (Docker)

Summary

Flood hangs after logging in, but as soon as rtorrent quits it loads up and get the data?

The weird thing is that Flood "has the data" when it loads after quiting rtorrent (and flood, since they are in the same dockerfile)

See video:

Expected Behavior

Flood loading up the interface as normal.

Config files

docker-compose.yml:

services:
  openvpn-client:
    container_name: openvpn-client
    image: dperson/openvpn-client
    restart: unless-stopped
    # cap_add, security_opt, and volume required for the image to function
    cap_add:
      - net_admin
    environment:
      TZ: '${TZ}'
      FIREWALL: ''
      ROUTE: '10.0.0.0/24'
    networks:
      - system_default
    ports:
      - "49184:49184" #rtorrent
    read_only: true
    tmpfs:
      - /run
      - /tmp
    security_opt:
      - label:disable
    stdin_open: true
    tty: true
    volumes:
      - /dev/net:/dev/net:z
      - ./openvpn:/vpn
    labels:
      - "traefik.port=3000"
      - "traefik.frontend.rule=PathPrefixStrip:/flood"

  rtorrent:
    container_name: rtorrent
    build: rtorrent-flood
    #image: wonderfall/rtorrent-flood
    tty: true
    restart: on-failure
    network_mode: "service:openvpn-client"
    volumes:
      - ./rtorrent-flood/config:/config
      - ./rtorrent-flood/data:/data
      - ./rtorrent-flood/flood-db:/flood-db

networks:
  system_default:
    external: true

config.js:

const CONFIG = {
  baseURI: process.env.FLOOD_BASE_URI || '/flood',
  dbCleanInterval: 1000 * 60 * 60,
  dbPath: '/flood-db/',
  floodServerHost: '0.0.0.0',
  floodServerPort: 3000,
  maxHistoryStates: 30,
  pollInterval: 1000 * 5,
  secret: process.env.FLOOD_SECRET || 'xxx',
  scgi: {
    host: 'localhost',
    port: 5000,
    socket: true,
    socketPath: '/tmp/rtorrent.sock'
  }
};

module.exports = CONFIG;

.rtorrent.rc

scgi_local = /tmp/rtorrent.sock

encoding_list = UTF-8
port_range = 49184-49184
port_random = no
check_hash = no
directory = /data/torrents
session = /data/.session
encryption = allow_incoming, try_outgoing, enable_retry
trackers.use_udp.set = yes
dht.mode.set = off
protocol.pex.set = no

min_peers = 1
max_peers = 100
min_peers_seed = 1
max_peers_seed = 50
max_uploads = 15

network.xmlrpc.size_limit.set = 10000000

schedule = watch_directory,1,1,"load.start=/data/.watch/*.torrent"
schedule = untied_directory,5,5,"stop_untied=/data/.watch/*.torrent"
schedule = scgi_permission,0,0,"execute.nothrow=chmod,\"g+w,o=\",/tmp/rtorrent.sock"
schedule = insufficient_disk_space,1,30,close_low_diskspace=500M

[NoLooseEnds]

I've tried a bit more, but I'm still stuck. I'm now trying to debug with a dedicated rtorrent and a dedicated flood docker image (instead of combining them).

I've figured out:

• The interface load when I quit flood, not rtorrent (as I previous thought)
• I got the same "reaction" both if I use socket-file, and if I use ip:port.

No idea why it's behaving this way.

[NoLooseEnds]

This seem to be an issue caused by using Traefik and a non-default pathURI (i.e /flood instead of /. Not sure witch is causing it, but I'm thinking Flood, since it sort of loads up (hence Treaefik working), but is just stuck on the "loading screen".

[NoLooseEnds]

Looking into this again. Still stuck, but I think I've narrowed it down further.

• non default path, does not matter for this issue (except for modifying the config.js correctly), I've switched to subdomain and it still behaves this way.

I'm trying to route the rtorrent and flood docker via an openvpn-client docker, and that is breaking it. network_mode: "service:openvpn-client"

Why does Flood halt, as long as it has access to the socket it should not care? Makes no sense. It serves files fine, but will not let me past the loading icon.

flood             |
flood             | > [email protected] start /usr/flood
flood             | > node server/bin/start.js
flood             |
flood             | Flood server starting on http://undefined:3000.
flood             |
flood             | GET /overview 200 12.714 ms - 543
flood             | GET /static/css/main.16a9269d.css 200 9.979 ms - -
flood             | GET /static/js/main.bbb83ce9.js 200 13.268 ms - -
flood             | GET /static/media/Roboto-500.1afbee5a.woff2 200 3.429 ms - 10248
flood             | GET /static/media/Roboto-700.3b38c16e.woff2 200 7.463 ms - 10276
flood             | GET /auth/verify?1551966088456 401 7.575 ms - -
flood             | GET /api/activity-stream?historySnapshot=fiveMin 401 0.261 ms - -
flood             | POST /auth/authenticate 200 44.647 ms - 211
flood             | GET /api/settings 200 20.859 ms - 2
flood             | GET /overview 200 1.229 ms - 543
flood             | GET /api/activity-stream?historySnapshot=fiveMin 200 10.966 ms - -
flood             | GET /api/client/settings - - ms - -
flood             | GET /static/js/main.bbb83ce9.js 304 1.286 ms - -
flood             | GET /static/css/main.16a9269d.css 200 4.375 ms - -
flood             | GET /static/media/Roboto-500.1afbee5a.woff2 304 1.085 ms - -
flood             | GET /static/media/Roboto-700.3b38c16e.woff2 304 3.120 ms - -
flood             | GET /auth/verify?1551966109737 200 3.023 ms - 52
flood             | GET /api/settings 200 1.130 ms - 2

[NoLooseEnds]

I've tried to digg a bit more:

Just to make sure I didn't configure something wrong with keeping flood and rtorrent as separate docker images, I tested with a different docker image (linuxserver/flood) that combines rtorrent and flood into one image.

It still halted on login. So from there I disconnected/removed the network_mode: "service:openvpn-client" and ran it "vanilla". Still did not work.

Then I sort of had an breaktrough – I tested opening the docker host address/url:3000, and that worked. I tried the same on the traefik address/url, and that did not work. That just loads the username/password box, and then it halts on the loading screen.

The logs from flood shows it loads the exact same files when it works (via docker host and via the traefik host). So I don't understand whats going on.

At least it looks like I've narrowed it down to that Traefik is breaking something with flood (or vica versa).

Does anyone have any clue? @noraj @jfurrow

[noraj]

You're using a third-party docker image (from linuxserver) and an untest OS (Traefik) and making teh whole thing going through a VPN. Why don't you use the docker image provided in this repo? I don't know it may be your VPN configuration.

All I can tell is that this is the recommended way to install: https://rawsec.ml/en/archlinux-install-rtorrent-flood-sftp/

Try to reproduce that in some docker containers.

[NoLooseEnds]

I don't think you read my previous post that well (or I was unclear).

I've run a lot of docker images, both the dockerfile from this repo and others, to try see if they did anything different (including docker images that combine rtorrent and flood in one image, and not in two separate). I've also done it with and without routing it through a VPN container – and that makes no difference.

Traefik is not an OS, it is an awesome reverse proxy.

Everything works if I use the docker host as the URL on port 3000 (ie. dockerhostname.subdomain.TLD:3000), but Flood hangs/stops on the loading screen if I use the Traefik host (ie. flood.subdomain.TLD).

Hence the issue is between Traefik and Flood somewhere. But I have no idea why. Everything else works with Traefik (including rutorrent, and a lot of other non torrent related services).

If I'm guessing, it could be something with the http headers, but I'm not skilled enough to figure that out as of yet.

[noraj]

Ok so whatever is Traefik you're trying to use it as a reverse proxy. So basically you can take a look of what I did with Nginx (https://rawsec.ml/en/archlinux-install-rtorrent-flood-sftp/#configure-nginx) or the wiki (https://github.com/jfurrow/flood/wiki/Using-Flood-behind-a-reverse-proxy). Only a simple proxy pass should be needed but if you are using http 2 on the edge side you may need to specify to use http 1.1 for the app side (proxy_http_version 1.1; with nginx). There is no bug of flood here. I think this is just about configuring your reverse proxy correctly.

[NoLooseEnds]

That's the thing, afaik I'm not doing anything special (and all other services works fine – i.e I'm currently running Sonarr, Radarr and Jacket containers routed via the VPN container with the exact same reverse proxy (traefik) settings – and that works flawlessly. ).

And the reverse proxy (traefik) is sort of working (i.e it loads up the login (or setup) screen), but hangs when logging in.

So something is going on at that moment, when it is trying to log you in.

[noraj]

Maybe https://github.com/jfurrow/flood/wiki/Troubleshooting#stuck-after-log-in

[noraj]

I never saw this scgi block in config.js. and I never succeed to make rtorrent works with flood using an UNIX socket, so I'm using a local tcp connection.

[NoLooseEnds]

Thanks, but the setup works fine when you access the host directly in the browser i.e dockerhost:3000, but hangs when logging in if you if you access it via the reverse proxy on flood.subdomain.TLD. And you can test both ways simultaneously.

So there is something with flood and traefik that I can't figure out.

[noraj]

If directly accessing the docker is fine, it must be an issue with traefik. As I said previously, look at https://rawsec.ml/en/archlinux-install-rtorrent-flood-sftp/#configure-nginx and try to adapt and reproduce what I did. I'll close this issue as it is not a bug from flood. Please go to the discord if you want to ask for support.

[NoLooseEnds]

Ok. But it has to be something special with Flood, since it semi-works (ie. loads up the login/setup part, but hangs in the loading screen after entering the credentials). And every other container (including rutorrent, that connects to the same socket) works.

[stigger]

I also experience exactly the same symptoms. In my case it's not a docker image, just self-installed flood with nginx, nginx has proxy_pass http://127.0.0.1:3000;. Works fine when accessing flood directly, hangs when accessing through nginx.

[NoLooseEnds]

Glad I'm not alone.

Could it be a "bug" with Flood? It has to be something with the login process that Flood does differently than most other? Since I have a few other services that requires login that works fine.

Maybe it should be reopened and have the bug tag after all @noraj?

[noraj]

Did you tried to add proxy_http_version and other headers I used in my example with nginx?

PS : I'm not a dev, only a member helping with issue on its own spare time.

[stigger]

I didn't, I followed this guide, which mentioned only the proxy_pass: https://github.com/jfurrow/flood/wiki/Using-Flood-behind-a-reverse-proxy

Will try later today.

[stigger]

I added additional settings and that did not help. I looked in the dev console which request is actually hanging, and it turns out that it's /api/activity-stream?historySnapshot=fiveMin: it's returned quite fast when accessing directly, but never finishes and eventually times out when accessing via nginx. In my case the response is ~10M in size.

[NoLooseEnds]

Looks like that is the same issue I face – sort of. Mine is not 10M in size, but it gives no response.

[noraj]

I re-installed rTorrent + Flood recently from git. Working behind nginx reverse proxy. The steps I followed are described here. And finally it works perfectly. Nearly every user of flood make it work behind a reverse proxy (Nginx, Apache httpd, etc.). I'm sorry @stigger but the current version of flood works behind a reverse proxy, if it is not working it may be because you have an external program interfering, you misconfigured the setup, or something else but not because of flood.

[noraj]

PS : As you can read I'm using more instructions that only proxy_pass and a lot of tutorials are using those blocks too. Maybe it was shinji257 that wrongly simplified the wiki page https://github.com/jfurrow/flood/wiki/Using-Flood-behind-a-reverse-proxy/_history

[noraj]

@Zyrophr As you seem to use a nested route, have you put baseURI: '/flood' in your config.js ?

For support there is no better place than the Discord troubleshooting channel.

--- PS ---

I'm not a dev of Flood, only a member helping with issues on his free time.

The only dev is @jfurrow, but he is not active anymore. @Zyrophr if you care about Flood take a look at #712 and #672. The actual project is slowly dying without active developers.

[andsens]

@Zyrophr, add a / to the end of your location /flood { like so location /flood/ {, do the same for your proxy_pass like so proxy_pass http://127.0.0.1:3000/, and then kill the rest it's not needed.

location /flood/ {
    proxy_pass http://127.0.0.1:3000/;
}

In order to support easy access without the trailing slash, add this below:

location /flood {
    rewrite ^/flood$ /flood/ permanent;
}

My case was a little more complicated, I actually had two reverse-proxy chained. One front-facing with SSL and another that simply spliced connections to rtorrent RPC and flood on that VM. Apparently keep-alive don't work on nginx if you proxy twice.
My tests:

Front facing nginx -> VM nginx -> flood: activity-stream is dead
VM nginx -> flood: works
Front facing nginx -> flood: works

So with regards to keep-alive settings on a reverse proxy, logic would dictate both of the nginx setups are configured correctly. I have no clue whatsoever why chaining two reverse proxies doesn't work.

[0xAF]

I had this problem too. After the login screen Flood hangs and do not show the torrents screen. I just updated the repo (git pull) and ran npm run build (which actually fixed the problem). I guess I just had to rebuild it, so my browser gets up-to-date JS code.

[billimek]

Has anyone successfully found a traefik configuration that will work with flood? Using traefik for about 30 other applications and don't experience this type of behavior.

I have no problem hitting flood directly but when proxying via traefik, it experiences the issue with not rending anything after the initial flood login screen. This is with the default / path and no custom subdomain.

[andsens]

@billimek, I am almost certain that the hanging has something to do with the TCP connection not staying open via keep-alive so that flood can push the activity-stream data. I would suggest figuring out what exactly is terminating your TCP connection.

[chortya]

In my case the issue was with the adblocker (Adguard). I figured this out because Flood worked from my mobile but not laptop Chrome. Flood IP was whitelisted but Adguard probably altered TCP flow anyways.

[DotEfekts]

I'm having the same issue and as far as I can tell @andsens is right about keep-alive connections being disrupted but they don't seem to be dropped altogether, just delayed for some minutes, which leads me to think Traefik is buffering these responses for some reason. Whether this is a Flood specific thing or a general Traefik thing I'm not sure.

[0xAF]

My problem was present while running nginx, but actually even opening flood directly (on it's port), there was still problem. So at least for me, the problem was in flood and rebuilding everything with npm fixed it. I've seen the same problem before, but after reloading the page it was working, but not this time. Perhaps some system update broke something on which flood relied...

[andsens]

@DotEfekts I figured it out!
On nginx when chaining 2 nginx reverse-proxies I can get keep-alives working by disabling proxy buffering on the front-facing proxy. It has no effect when I turn it off on the proxy right before flood.

proxy_pass http://flood;                                                                                                                 
proxy_buffering off;

I work with traefik myself, though not in that context. There seem to be some buffering related configs in traefik, but the documentation implies that buffering is something you turn on. So I'm not sure whether the underlying issue is the same.