Lazytainer is not starting container after stopping it

[heisenberg2980]

I setup Lazytainer to manage a Firefox container. The container is correctly stopped when no traffic is detected, but when traffic is detected again the container does not start, these are the Laytainer logs:

DEBUG: 2023/07/11 08:42:28 lazytainer.go:111: Using default netInterface of eth0 because lazytainer.group.firefox.netInterface was not set
DEBUG: 2023/07/11 08:42:28 lazytainer.go:147: {groupName:firefox inactiveTimeout:30 minPacketThreshold:1 netInterface:eth0 pollRate:30 ports:[5800] sleepMethod:stop}
DEBUG: 2023/07/11 08:42:28 group.go:66: 0 received out of 1 packets needed to restart container
DEBUG: 2023/07/11 08:42:58 group.go:70: /////////////////////////////////////////////////////////////////////////
DEBUG: 2023/07/11 08:42:58 group.go:48: 0 packets received in the last 30 seconds
DEBUG: 2023/07/11 08:42:58 group.go:174: 0 active clients
30 / 30 seconds without an active client or sufficient traffic on running container
DEBUG: 2023/07/11 08:42:58 group.go:85: stopping container(s)
INFO: 2023/07/11 08:43:01 group.go:93: stopped container  /firefox-firefox-1
DEBUG: 2023/07/11 08:43:31 group.go:70: /////////////////////////////////////////////////////////////////////////
DEBUG: 2023/07/11 08:43:31 group.go:66: 0 received out of 1 packets needed to restart container
DEBUG: 2023/07/11 08:43:36 group.go:148: group firefox recieved 1 packets
DEBUG: 2023/07/11 08:43:36 group.go:148: group firefox recieved 2 packets
DEBUG: 2023/07/11 08:43:36 group.go:148: group firefox recieved 3 packets
DEBUG: 2023/07/11 08:43:36 group.go:148: group firefox recieved 4 packets
DEBUG: 2023/07/11 08:43:36 group.go:148: group firefox recieved 5 packets
DEBUG: 2023/07/11 08:43:36 group.go:148: group firefox recieved 6 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 7 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 8 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 9 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 10 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 11 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 12 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 13 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 14 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 15 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 16 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 17 packets
DEBUG: 2023/07/11 08:43:37 group.go:148: group firefox recieved 18 packets
DEBUG: 2023/07/11 08:43:38 group.go:148: group firefox recieved 19 packets
DEBUG: 2023/07/11 08:43:38 group.go:148: group firefox recieved 20 packets

This is the Lazytainer docker-comose.yaml file:

version: "3"
services:
  lazytainer:
    container_name: lazytainer
    image: ghcr.io/vmorganp/lazytainer:master
    environment:
      - VERBOSE=true # probably set this to false unless you're debugging or doing the initial demo
    ports:
      - 5800:5800
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    labels:
      # Firefox
      - "lazytainer.group.firefox.pollRate=30"
      - "lazytainer.group.firefox.inactiveTimeout=30"
      - "lazytainer.group.firefox.ports=5800"
      - "lazytainer.group.firefox.sleepMethod=stop" # can be either "stop" or "pause", or left blank for stop
      - "lazytainer.group.firefox.minPacketThreshold=1"

And this is the Firefox docker-compose.yaml file:

version: '3'
services:
  firefox:
    image: jlesage/firefox
#    ports:
#      - "5800:5800"
    volumes:
      - "./config:/config:rw"
    environment:
      - SECURE_CONNECTION=1
    network_mode: container:lazytainer
#    network_mode: service:lazytainer
    depends_on:
      - lazytainer
    labels:
      - "lazytainer.group=firefox"

[vmorganp]

I believe this is misconfiguration for the behavior you're expecting. The pollRate value also determines how responsive the container will be when receiving new traffic. In this case it's only checking whether it's received sufficient traffic every 30 seconds (meaning worst case, you may have to wait 30 seconds after providing sufficient traffic to turn your container back on).

You can fix this by lowering the pollRate clock or raising your patience for container continuation.

[heisenberg2980]

With the current configuration the container never starts no matter how much I wait, but changing the inactiveTimeout to 60 the container starts, so it seems the inactiveTimeout cannot be equal (or lower I guest) than pollRate as that causes the container to never start, maybe something to be included in the documentation.