[BUG] Docker image exits immediately after creation

[mgrimace]

Describe the bug
The image is successfully created but exits immediately. Using docker to deploy on Ubuntu server.

Expected behavior
Docker install works and webUI is accessible via IP:port

Version Number
0.8b

Error Report

docker ps -a

CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                      PORTS                                       NAMES
5a8f57e26a0a   msrf-msrf                                      "/bin/sh -c 'poetry …"   25 seconds ago   Exited (1) 23 seconds ago                                               msrf-msrf-1

docker logs msrf-msrf-1

Traceback (most recent call last):
  File "/msrf/main.py", line 15, in <module>
    import database
  File "/msrf/database/__init__.py", line 1, in <module>
    from .database_access import *
  File "/msrf/database/database_access.py", line 3, in <module>
    import util
  File "/msrf/util/__init__.py", line 1, in <module>
    from .configloader.config import *
  File "/msrf/util/configloader/config.py", line 1, in <module>
    import yaml
ModuleNotFoundError: No module named 'yaml'

[Pixxeasy]

I have experienced the same issue. For me, deleting the poetry.lock file before building the docker solved this issue.

[mgrimace]

I have experienced the same issue. For me, deleting the poetry.lock file before building the docker solved this issue.

Thanks so much for sharing that workaround and for identifying the culprit. Hopefully it's an easy bug fix. From the python-poetry documentation "the poetry.lock file prevents you from automatically getting the latest versions of your dependencies."

I'm guessing this is related this note in the current project's documentation "Note: The bundled Chrome and Chromedriver binaries will likely be outdated. This is to prevent breaking changes in Chrome and Chromedriver from affecting the program."

I'm off, see explanation below.

[thearyadev]

The poetry lock file is to ensure the dependencies are correctly configured in your environment as it is in my environment. I’m not entirely sure why deleting the lock file solves this problem.

the package pyyaml is correctly configured in the pyproject.toml and the poetry.lock file (poetry.lock is automatically generated when adding dependencies to a poetry project.)

I recently learned something about poetry. The dockerfile contains a line something like this:

RUN poetry install; exit 0;

When i was installing dependencies, there was some issue that caused a non-zero exit code related to the configuration of the project. This command would ensure the poetry install would then exit successfully, even if there were failures in the dependency installation. The original issue was non-critical, but it completely went over my head that there could be issues with dependency installation. This wasn’t something that appeared in my testing.

I found a fix for this and will be implementing it here in the coming days.

in the coming days i’ll be making some github actions to build and publish the image to ghcr.io so you dont have to build the image yourselves, preventing issues like this.

I'm guessing this is related this note in the current project's documentation "Note: The bundled Chrome and Chromedriver binaries will likely be outdated. This is to prevent breaking changes in Chrome and Chromedriver from affecting the program."

This is unrelated to the lock file. The dockerfile contains this line:

RUN apk add chromium-chromedriver

Which retrieves the latest version of the chromedriver/chrome combination every time the image is built.

This note was originally for the zip file included in the github release, as this was targeted at windows desktop usage. The zip file came. bundled with an installation of chrome and a compatible chromedriver, which i did not update.

[mgrimace]

That's great information, thanks for clarifying and I appreciate the work/fix!

[thearyadev]

Updated the main branch.

1. removed dependency installation failure bypass RUN poetry install; exit 0;
2. Added GitHub actions CI for ghcr.io.

MSRF can now be deployed using the following compose file:

version: "3.9"
services:
  msrf:
    image: ghcr.io/thearyadev/msrf:latest
    ports:
    # external:internal
    - "50947:50947"
    volumes:
    - ./accounts:/msrf/accounts # directory which should contain the accounts.sqlite file. 

or by pulling ghcr.io/thearyadev/msrf:latest

Also, thanks for pointing out the problem with the poetry.lock file. So the RUN poetry install; exit 0; bypassed any errors when installing dependencies, which I never ran into because of this. (Stupid of me to have this in hindsight). The poetry.lock file is a file containing every dependency and sub dependency of the program, and there was an issue with the installation of that exact hash of Selenium.

This error would not show in the build, and would kind of be "invisible" in execution.

[mgrimace]

Initial testing and bug is fixed for me. I appreciate the compose + prebuilt image, excellent work!
I also made some minor additions to the compose file (added container_name, timezone, and restart values).

version: "3.9"
services:
  msrf:
    container_name: msrf
    image: ghcr.io/thearyadev/msrf:latest
    environment:
      - TZ=America/Toronto
    ports:
      - '50947:50947' # external:internal
    volumes:
      - /opt/appdata/msrf/accounts:/msrf/accounts # directory which should contain the accounts.sqlite file. 
    restart: unless-stopped

I'll test with account, etc., but initial tests are looking great!

[mgrimace]

Follow-up, after adding accounts in the webui I'm getting the following error, [Line 132] eligible account was not found:

It did show that the accounts were successfully added with their passwords when I entered them, and they appear in the left column with 0 points (they have >0 each).

Want me to start a new bug tracker/issue or keep the testing here?

edit: and no errors in the error column

[thearyadev]

by default it waits 24 hours before running again.
so it attempted to run but failed somehow.

I'll do some testing and let you know if I need more info soon.

I haven't explicitly tested the dependency changes so that is likely causing an issue.

we can continue using this gh issue. Thanks for the feedback.