8
i2p front end inaccessible after its container is restarted (lemmy.world)
submitted 2 months ago* (last edited 2 months ago) by NegativeLookBehind@lemmy.world to c/docker@programming.dev
4 comments fedilink hide all child comments

I'm experimenting with i2p and a librewolf container setup in Docker compose. However, the i2p web console front end (127.0.0.1:7657) becomes inaccessible if the container itself is restarted. This can be remedied by removing the directories that get created by the volume mappings in the compose file, but this obviously not ideal. Anyone have experience with this problem? I've seen hints from people online suggesting that the data in those directories getting somehow corrupted. I have not yet investigated that further.

version: "3.5"
services:
  i2p_router:
    image:
      geti2p/i2p:latest
    environment:
    - JVM_XMX=256m
    volumes:
    - ./i2phome:/i2p/.i2p
    - ./i2ptorrents:/i2psnark
    ports:
    - 4444:4444
    - 6668:6668
    - 7657:7657
    - 9001:12345
    - 9002:12345/udp

  libre_wolf:
    image:
      linuxserver/librewolf
    ports:
    - 9300:3000
    - 9301:3001

volumes:
  i2phome:
  i2ptorrents:
networks:
  frontend:
    driver: bridge
top 4 comments
sorted by: hot top controversial new old
[-] NegativeLookBehind@lemmy.world 1 points 2 months ago* (last edited 2 months ago)

Doing more digging, I captured checksums of all files that get created by the i2p container, with

find i2p* -type f -exec md5 {} + > 1sum # After starting container

and

find i2p* -type f -exec md5 {} + > 2sum # After restarting container

Comparing the files with diff -y 1sum 2sum, I noticed this file was the only one whose checksum changed:

MD5 (i2phome/router.ping) = 95fd0fa14b084cf019f2dd9e0884aa1 | MD5 (i2phome/router.ping) = f4b060ae4f789f7d24f2851c06597c4

EDIT:

Preserving this file outside of the volume directory and copying it back in after the container restarts allows the web console to function as expected.

EDIT 2:

To take it a step further, I'm mounting it read only into the container at runtime like this:

- ./router.ping:/i2p/.i2p/:ro

which is sort of a hack, but I think I can live with it.

[-] onlinepersona@programming.dev 0 points 2 months ago* (last edited 2 months ago)

You should probably look at the logs. It helps narrow down the issue and provide us also with more information.

Logs are either in the i2p home folder or in the docker logs.

Anti Commercial-AI license

[-] NegativeLookBehind@lemmy.world 1 points 2 months ago

Yeah, I looked at the logs originally, and would've posted them had they been relevant. The problem is, the logs do not differ between a working and non-working container. They're literally this, before and after a restart:

Starting I2P
[startapp] Running in container
[startapp] Running in docker network
[startapp] setting reachable IP to container IP 172.26.0.2
Starting I2P 2.5.2-0
OpenJDK 64-Bit Server VM warning: You have loaded library /tmp/i2p-JtRKWUcL.tmp/libjbigi.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
[-] onlinepersona@programming.dev -1 points 2 months ago
  1. How long did you wait for the router to be back up?
  2. Have you looked at the logs within the container? docker compose exec i2p_router tail -F .i2p/wrapper.log

For me, it comes back up after a few seconds.

WARN: There may be another router already running. Waiting a while to be sure...
WARN: Old router was not shut down gracefully, deleting /i2p/.i2p/router.ping
INFO: No, there wasn't another router already running. Proceeding with startup.

Anti Commercial-AI license

this post was submitted on 13 Sep 2024
8 points (100.0% liked)

Docker

966 readers
2 users here now

founded 1 year ago
MODERATORS
erlingur@programming.dev
ProgramPhoenix@programming.dev
Ategon@programming.dev