FreeTAKTeam / FreeTAKServer-Docker

Official Docker Image for FreeTAKServer
Eclipse Public License 2.0
42 stars 26 forks source link

error: The directory named as part of the path /data/logs/supervisor/supervisord.log does not exist #12

Closed w111a closed 3 years ago

w111a commented 3 years ago

Os: Unraid 6.9.2 Image version: 1.7.5 (:dev tag) Problem: Starting the container with the /data path created at /mnt/user/appdata/freetakserver and ports 5000, 8080, 19023 8086, 8087, 8089, 8433. got the following error.   error: The directory named as part of the path /data/logs/supervisor/supervisord.log does not exist

The container stops

Solution : Added path /data/logs/supervisor to /mnt/user/appdata/freetakserver/logs/supervisor/

Container now starts without error. Not sure why this issue occured but is there anyway the fix the docker container so this was not needed. Thanks

skadakar commented 3 years ago

Could you provide your full start cmd?

w111a commented 3 years ago

Command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='freetakserver' --net='host' -e TZ="America/Regina" -e HOST_OS="Unraid" -e 'TCP_PORT_5000'='5000' -e 'TCP_PORT_8080'='8080' -e 'TCP_PORT_8086'='8086' -e 'TCP_PORT_8087'='8087' -e 'TCP_PORT_8089'='8089' -e 'TCP_PORT_8443'='8443' -e 'TCP_PORT19023'='19023' -v '/mnt/user/appdata/freetakserver/':'/data':'rw' **-v '/mnt/user/appdata/freetakserver/logs/supervisor/':'/data/logs/supervisor':'rw'_** 'freetakteam/freetakserver:dev' 5d16043b975b833f19fca6f7ba8b37b5a049a443fc10da7e6c1cb3f5842892ee

Bold section is what was added for the fix

skadakar commented 3 years ago

I suspect this can be fixed by re-ordering the dockerfile, probably won't be able to look at it before the weekend. Anyone else feel free to fix and add a PR.

skadakar commented 3 years ago

Fixed in https://github.com/FreeTAKTeam/FreeTAKServer-Docker/pull/15 awaiting merge

skadakar commented 3 years ago

If you could try again with the latest build and report back that would be most helpful.

w111a commented 3 years ago

Looks to be all good now. Rebuilt the server without the logs folder. As in update for others looking to run this, this is my start command that it working (note: some variables were needed to get it working. I had a conflicting service at 8443 and changed it to 8442).

Command:

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker create --name='freetakserver' --net='bridge' --privileged=true -e TZ="America/Regina" -e HOST_OS="Unraid" -e 'DataPackageServiceDefaultIP'='192.168.1.100' -e 'UserConnectionIP'='192.168.1.100' -e 'IP'='192.168.1.100' -e 'APPIP'='0.0.0.0' -p '5000:5000/tcp' -p '8080:8080/tcp' -p '8086:8086/tcp' -p '8087:8087/tcp' -p '8089:8089/tcp' -p '8442:8443/tcp' -p '19023:19023/tcp' -v '/mnt/user/appdata/freetakserver/':'/data':'rw' 'freetakteam/freetakserver:dev' 2d6ee0ca8794ab2a1e971b70a020f6bf0ba5a97ed5badd7c7a85b0970cfdbb44

LargoUsagi commented 3 years ago

@w111a Please let us know if this runs stable, if so we can tag it off so it wont change and break on you as the dev tag is an ephemeral tag.

w111a commented 3 years ago

This is the log after 9 hours. I had 3 devices on and off through the day and am using a VPN(wireguard) to connect over LTE.

###########################

g
###########################
Create logs folder
Set permissions on data folder
Setting default user connection IP: 192.168.1.100
Setting user connection IP: 192.168.1.100
Using default APIIP 0.0.0.0
Using default AllowedCLIIPs [127.0.0.1]
Using default CLIIP 127.0.0.1
Using Default SaveCoTToDB (True)
Using Default Connection Message
Setting IP: 192.168.1.100
Setting APPIP: 0.0.0.0
###########################
Preparations completed
###########################
2021-04-26 10:43:50,631 WARN For [program:FTS], redirect_stderr=true but stderr_logfile has also been set to a filename, the filename has been ignored
2021-04-26 10:43:50,631 WARN For [program:UI], redirect_stderr=true but stderr_logfile has also been set to a filename, the filename has been ignored
2021-04-26 10:43:50,631 INFO Set uid to user 0 succeeded
2021-04-26 10:43:50,633 INFO supervisord started with pid 13
2021-04-26 10:43:51,636 INFO spawned: 'quit_on_failure' with pid 15
2021-04-26 10:43:51,638 INFO spawned: 'FTS' with pid 16
2021-04-26 10:43:51,639 INFO spawned: 'UI' with pid 17
2021-04-26 10:43:52,428 INFO exited: UI (exit status 1; not expected)
2021-04-26 10:43:53,429 INFO success: quit_on_failure entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-04-26 10:43:53,429 INFO success: FTS entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-04-26 10:43:53,432 INFO spawned: 'UI' with pid 20
2021-04-26 10:43:54,433 INFO success: UI entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-04-26 10:44:07,602 INFO exited: FTS (exit status 1; not expected)
2021-04-26 10:44:08,605 INFO spawned: 'FTS' with pid 26
2021-04-26 10:44:10,278 INFO success: FTS entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
###########################

g
###########################
Create logs folder
Set permissions on data folder
Setting default user connection IP: 192.168.1.100
Setting user connection IP: 192.168.1.100
Using default APIIP 0.0.0.0
Using default AllowedCLIIPs [127.0.0.1]
Using default CLIIP 127.0.0.1
Using Default SaveCoTToDB (True)
Using Default Connection Message
Setting IP: 192.168.1.100
Setting APPIP: 0.0.0.0
###########################
Preparations completed
###########################
2021-04-26 10:44:48,932 WARN For [program:FTS], redirect_stderr=true but stderr_logfile has also been set to a filename, the filename has been ignored
2021-04-26 10:44:48,932 WARN For [program:UI], redirect_stderr=true but stderr_logfile has also been set to a filename, the filename has been ignored
2021-04-26 10:44:48,932 INFO Set uid to user 0 succeeded
2021-04-26 10:44:48,933 INFO supervisord started with pid 13
2021-04-26 10:44:49,936 INFO spawned: 'quit_on_failure' with pid 15
2021-04-26 10:44:49,939 INFO spawned: 'FTS' with pid 16
2021-04-26 10:44:49,941 INFO spawned: 'UI' with pid 17
2021-04-26 10:44:51,578 INFO success: quit_on_failure entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-04-26 10:44:51,578 INFO success: FTS entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-04-26 10:44:51,579 INFO success: UI entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

I have found that when I first spin up the container I will have an unexpected exit of one or more services ( UI and/or FTS), after which the service restarts. But if I restart the container all the services start and run without issue and no unexpected exits.

The only hiccup has been that I am unable to create a user when I choose certs as 'true'. Creating a user without certs works fine.

Would you like me to start issues for these?

skadakar commented 3 years ago

The UI restart is expected if there is no DB yet.

Certs is probably unrelated to the docker image, so make that issue in the main repo or better yet join the discord and ask there, someone is probably able to help you.

skadakar commented 3 years ago

You can exec into your docker container to see more detailed logs under /data/logs

docker exec -it CONTAINERNAME /bin/bash

w111a commented 3 years ago

You can exec into your docker container to see more detailed logs under /data/logs

docker exec -it CONTAINERNAME /bin/bash

Thank you. Looking deeper in the log file it looks like the service restart is due to the db not being created.

I am now noticing blocks of

 handling shared data 

time since last reset 0:00:30.001713

 handling shared data 

 handling shared data 

 handling shared data 

resetting

 handling shared data 

 handling shared data 

 handling shared data 

 handling shared data 

time since last reset 0:00:30.005176

 handling shared data 

 handling shared data 

resetting

 handling shared data

where I assume what is the connection is resetting 28 times in this sequence. I did not notice a disturbsnce in the actual server. Is this normal behaviour?

I will post an issue in the main repo for the certs.

Thanks again.

w111a commented 3 years ago

Sounds like regular resets is normal for FTS.