Poolcontroller docker container keeps restarting (fresh install)

[MaxVonEvil]

Hi everone and @tagyoureit @emes, @wurmr

I'm currently working on getting the latest poolcontroller+dashpanel docker image running via docker-compose on a Pi4.
Yet it seems the containers keeps restarting due to an illegal read operation on a directory inside the container?

As I'm not a Docker guru by any stretch (but hey, I can google ;) I could use a kick in the right direction or a bit of help how to solve this. Here's the steps I took:

1. Used the unmodified docker-compose.yml which includes both server and dash panel, published in the wiki

2. Did a docker-compose pull and docker-compose up -d So far so good

3. Yet when checking status with docker container ls -a it's status never changes from 'Restarting (1) 5 seconds ago'

4. Running a docker logs --tail 50 --follow --timestamps poolcontroller shows repeats of this block of errormessages:

2022-06-04T20:06:18.704201739Z Error reading configuration information. Aborting startup: Error: EISDIR: illegal operation on a directory, read
2022-06-04T20:06:18.751804539Z Error: EISDIR: illegal operation on a directory, read
2022-06-04T20:06:18.751888818Z at Object.readSync (node:fs:723:3)
2022-06-04T20:06:18.751906670Z at tryReadSync (node:fs:433:20)
2022-06-04T20:06:18.751923170Z at Object.readFileSync (node:fs:479:19)
2022-06-04T20:06:18.751938893Z at new Config (/app/config/Config.ts:37:69)
2022-06-04T20:06:18.751954412Z at Object. (/app/config/Config.ts:192:31)
2022-06-04T20:06:18.751971504Z at Module._compile (node:internal/modules/cjs/loader:1101:14)
2022-06-04T20:06:18.751987486Z at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
2022-06-04T20:06:18.752002875Z at Module.load (node:internal/modules/cjs/loader:981:32)
2022-06-04T20:06:18.752018561Z at Function.Module._load (node:internal/modules/cjs/loader:822:12)
2022-06-04T20:06:18.752034061Z at Module.require (node:internal/modules/cjs/loader:1005:19)

It would seem evident that Docker is not happy about something in /app/config/Config.ts

5. I also tried composing with all the bells and verbose whistles I could think (sudo docker-compose --verbose up --force-recreate --build --renew-anon-volumes) But all I got was the same.

6. I made a copy of the container image and shelled into it:
   docker commit poolcontroller mypcdebug
   docker run -it --rm --entrypoint sh mypcdebug
   Checking the /app/config/Config.ts, it's in there alright and it's got 755 permissions, so it would seem permissions are in order.
   Opening the file with vi, line 37:69 as referenced above is: this._cfg = fs.existsSync(this.cfgPath) ? JSON.parse(fs.readFileSync(this.cfgPath, "utf8")) : {};^M it seems that it's the existSync() method throwing the error, yet I could be wrong..?

NOTE1: It should be said that running the container manually with docker run --rm -it --group-add dialout -p 4200:4200 --device /dev/ttyUSB0 msmi/nodejs-poolcontroller seems to work fine, yet I really need to run it in the background.

NOTE2: I know the docker install to be kosher as it's currently running Zwavejs2MQTT in another container without issue.
Would appreciate any suggestions to help crack this nut. Let me know if I need to do a bug-report or anything else.

Thanks
/Max

[rstrouse]

The error message indicates that the process running njsPC does not have access to read the config.json and defaultConfig.json files.

[rstrouse]

There should not be a config.json or defaultConfig.json directory. These are both files in the root of the application. Yes the config.json file will be created on startup however, if a config.json directory exists then a file of the same name may not. When the code calls for checking for its existence it will fail if there is a config.json directory. This is because you cannot test for its existence with read you cannot also write bytes to a directory.

[MaxVonEvil]

Thanks for that very good explanation. I immediately went and knocked out the offending empty config.json directory under /data/poolcontroller, yet this yields a new interesting error when I try starting the container with a docker start poolcontroller

Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/data/poolcontroller/config.json" to rootfs at "/app/config.json": mount /data/poolcontroller/config.json:/app/config.json (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
Error: failed to start containers: poolcontroller

This is what the docker-compose file looks like

services:
poolcontroller:
container_name: poolcontroller
restart: always
user: node:dialout
devices:
- /dev/ttyUSB0
ports:
- "4200:4200"
volumes:
- /data/poolcontroller/config.json:/app/config.json
- /data/poolcontroller/data:/app/data
image: msmi/nodejs-poolcontroller
poolcontroller-dashpanel:
restart: always
container_name: poolcontroller-dashpanel
ports:
- "5150:5150"
volumes:
- /data/poolcontroller-dashpanel/config.json:/app/config.json
image: msmi/nodejs-poolcontroller-dashpanel
depends_on:
- poolcontroller

(completely unmodified)
I looked around and it seems the docker volume bind method could be what is giving me grief. I found a stackoverflow posting, which I'm digging into. Also there is an interesting docker compose example in the last part of this docker doc. I'm guessing I could mod the docker compose yaml to something like ths

volumes:
  - type: bind
    source: /data/poolcontroller/config.json
    target: /app/config.json

And of course my $#%@'ing Pi4 had to crash while I was working 500mi away..gaaah! Now I have to wait to come home on Friday before I can try/troubleshoot some more.. Stay tuned :)

[rstrouse]

I am not a docker user but I don't think that is right. The config.json file will not be located in the data directory. The only files you will find in there are state and config json files. The data directory is created on init if it does not exist. It does this because GIT would force everybody to lose their pool configuration every time they did a pull if it didn't. The same is true for the following directories off the application root:
backups
logs
web/bindings/custom

These directories are created at runtime so they will not yet exist when the application is first run. They are persistent and contain the localized configuration data for the particular installation. The same is true for config.json. This file is created on first run using the data from the defaultConfig.json. All of this is off the application root so I don't understand why docker would require so many gymnastics for a directory structure. The only thing that could be in the way here is that it requires permission to create files and directories off the application root and subsequently read from them.

The config.json file is located in the root of the app directory. It is not located in the dist directory. The dist directory is only for transpiled typescript files and created when tsc is called on startup by the TypeScript compiler.

For dashPanel there should be a volume mount for uploads, logs and data off the root application. NOTE: These directories are created at runtime.

For REM there should be a volume mount for logs and data. NOTE: These directories are also created at runtime.

[MaxVonEvil]

@rstrouse you and me both :) Just been mucking about with Docker, Yet I think I may have a working solve here, along the lines above (even a blind chicken can step in a turd, I suppose :) Anyway - it seems to be a problem in other cases that docker creates directories instead of files on the host. To mitigate it, I essentially created the two config.json's manually (for pool controller and dash panel in the host-OS). Here is the step by step on how I got it to work:

Having the images pulled already and the associated containers stopped:

Enter

1. I "cold mounted" the image (not the container which at this point is borked), running a shell inside it so I could access the files inside:
   docker run -it --rm --entrypoint sh msmi/nodejs-poolcontroller

2. As the shell launches into the /app virtual folder inside the image, I can access the defaultConfig.xml. I just dumped it out on screen and copied it to the clipboard:
   cat ./defaultConfig.xml

3. Using CTRL+D to exit the shell, I went to the host directory and deleted the config.xml which is not supposed to be there (sudo needed as we dont have read permissions here per default): msmi/nodejs-poolcontroller
   cd /data/poolcontroller
   rmdir config.json

4. Start an editor and paste in the config file, Edit what you need (equipment, mqtt, etc) and save.
   sudo nano config.json

5. Repeat steps 1-4 for the poolcontroller-dashpanel image and extract and possibly mod the config file for that one as well

6. Modify your ~/nodejs-poolcontroller/docker-compose file. This is what mine looks like:

services:
  poolcontroller:
    container_name: poolcontroller
    restart: always
    user: node:dialout
    devices:
      - /dev/ttyUSB0
    ports:
      - "4200:4200"
    volumes:
    - type: bind
      source: /data/poolcontroller/config.json
      target: /app/config.json
    image: msmi/nodejs-poolcontroller
  poolcontroller-dashpanel:
    restart: always
    container_name: poolcontroller-dashpanel
    ports:
      - "5150:5150"
    volumes:
    - type: bind
      source: /data/poolcontroller-dashpanel/config.json
      target: /app/config.json
    image: msmi/nodejs-poolcontroller-dashpanel
    depends_on:
      - poolcontroller

The above just specifies the bind type and specifies the source and target on two separate lines. Apparently this forces docker to recognize this as a file. The regular binding of the data directory seems to work fine (meaning it does not break launch of the container, yet I don't see any log files being created there?)

7. Start the composer file
   **cd ~/nodejs-poolcontroller
   docker-compose up -d
   **

8. Check the containers are running. Do this twice with min 30 sec between, to ensure they arent restarting still
   docker ps -a

9. Check the poolcontroller is not yelling bloody murder over one thing or another by tailing the live log output
   dockerlogs --tail 50 --follow --timestamps nodejspoolcontroller

So, there might be stuff I am missing, I honestly dont know, yet this got me running and I hope this might help others who run into this situation. Thanks again for pointing me in the right direction of the config.json

[JamonGrande]

I ran into a similar reboot loop issue on a ReadyNAS 422 and completely removing the volumes: config section worked for me.

Added my working config to the wiki