Runing in microk8s

[docfactory37]

Hi All,

Just wanting some help i'm running this image in microk8s and when i deploy and start the container i get the below issue.

if i run it in just docker it works fine no issue.

I used to run this in microk8s but and to rebuild my server. hope some can help but its very odd as it used to work fine in the past.

im also using the latest version of this container

[SeeTwoArrr]

Hi,

Not sure if this is still relevant but a lot will be needed than just a screenshot.

You said it's working on Docker, that makes me think it might be misconfiguration or incorrect yaml. What kind of resources are you deploying? Can you show the yaml?

[javydekoning]

Here is a working example with MetalLB:

apiVersion: v1
kind: Service
metadata:
  name: rutorrent
  namespace: default
  annotations:
    metallb.universe.tf/allow-shared-ip: rutorrent
spec:
  selector:
    app: rutorrent
  type: LoadBalancer
  loadBalancerIP: 192.168.1.252
  ports:
    - name: http
      port: 8080
      targetPort: 8080
      protocol: TCP
    - name: scgi
      port: 8000
      targetPort: 8000
      protocol: TCP
    - name: torrent-tcp
      port: 51413
      targetPort: 51413
      protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: rutorrent-upd
  namespace: default
  annotations:
    metallb.universe.tf/allow-shared-ip: rutorrent
spec:
  selector:
    app: rutorrent
  type: LoadBalancer
  loadBalancerIP: 192.168.1.252
  ports:
    - name: torrent-udp
      port: 6881
      targetPort: 6881
      protocol: UDP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rutorrent
  namespace: default
  labels:
    app: rutorrent
spec:
  selector:
    matchLabels:
      app: rutorrent
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: rutorrent
    spec:
      containers:
        - name: rutorrent
          image: ghcr.io/crazy-max/rtorrent-rutorrent:4.0-0.9.8-0.13.8
          imagePullPolicy: Always
          resources:
            requests:
              memory: "1Gi"
              cpu: "500m"
            limits:
              memory: "1Gi"
              cpu: "4"
          env:
            - name: TZ
              value: Europe/Amsterdam
            - name: PUID
              value: "911"
            - name: PGID
              value: "911"
            - name: RUTORRENT_PORT
              value: "8080"
            - name: RT_INC_PORT
              value: "51413"
            - name: XMLRPC_PORT
              value: "8000"
          ports:
            # RUTORRENT_PORT
            - containerPort: 8080
            # XMLRPC_PORT
            - containerPort: 8000
            # RT_INC_PORT
            - containerPort: 51413
            # DHT
            - containerPort: 6881
          volumeMounts:
            - name: downloads
              mountPath: /data/
              subPath: config/rtorrent-config
            - name: downloads
              mountPath: /downloads/
      volumes:
        - name: downloads
          hostPath:
            path: /downloads
            type: DirectoryOrCreate
      restartPolicy: Always

[NGAJean]

Does any Helm chart is ongoing and/or planned ?

[SeeTwoArrr]

I also have it running in a k3s cluster myself. Could make a Helm chart but that would take some time as I imagine many people have different setups. For example I am running it in combination with gluetun to have rtorrent go over VPN only, but the web interface is then proxied by another pod to expose that normally.

[rayslava]

Have same situation with k8s node.
Interestingly, xmlrpc.log shows everything as expected (requests come and responses go out), but ruTorrent still reports No connection to rTorrent. Check if it is really running. Check $scgi_port and $scgi_host settings in config.php and scgi_port in rTorrent configuration file.
Don't know, where should I start digging to find the root cause.
Does ruTorrent have any log configuration support? rutorrent.log is empty

[rayslava]

Okay, I just spent a couple of hours profiling, and managed to resolve the issue.

The root cause is RLIMIT_NOFILES. My k8s node sets it to 17179869076 by default, so rtorrent just consumes all the available memory on start, during the close(2) syscall (didn't check the sources, to find out why, wild guess: it tries to close all the fds in loop to become a daemon), and the process gets killed by OOM.

The issue is not reproducible in plain docker case, since docker has appropriate limits set, and sample docker-compose.yml has explicitly set RLIMIT_NOFILES. I guess, the behavior depends on the k8s/k3s backend and therefore the setup can work or not work depending on node configuration.

Currently, I baked an image with echo "s6-softlimit -o 65536 rtorrent -D -o import=/etc/rtorrent/.rtlocal.rc -i ${WAN_IP}" >> /etc/services.d/rtorrent/run in 04-create-services.sh and it works perfectly. Not sure about correct solution for s6 though, but I can suggest adding RTORRENT_ULIMIT_NOFILES envvar with a reasonable default as a configuration option.

[crazy-max]

but I can suggest adding RTORRENT_ULIMIT_NOFILES envvar with a reasonable default as a configuration option.

SGTM