compreface-core exits with code 132 during startup #417
Comments
|
Do other images start normally? |
|
I thought so because I was able to navigate to the webpage and create a user and login. It just fails with a something went wrong when trying to test when uploading an image. I did change the external port for the web to be 8001 in the compose. Here is my compose output |
|
I don't see any errors in this log. Could you try to recognize a face and then send logs after the error appears? |
|
2 things that stick out in the above: |
|
looks like this is really the problem of the old CPU: |
|
Could you please add this info to the readme, maybe under a new requirements section? Please also add an example code how to check this, like |
|
yes, it makes sense, we are preparing a new release now, I'll add this to the documentation in it. |
|
Ahh, i seem to have stumbled upon this same issue. damn, lots more reading to do then. |
|
I did some mods on my double take home assistant config where I tried to filter some cameras by adding zones and all of the sudden I get too many SQL variables . and then when I check compreface containers I find this the the db #664 2021-11-19 17:47:40.957 UTC [1] LOG: listening on IPv6 address "::", port 5432 2021-11-19 17:47:40.970 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2021-11-19 17:47:40.998 UTC [24] LOG: database system was interrupted; last known up at 2021-11-19 17:40:38 UTC 2021-11-19 17:47:41.402 UTC [24] LOG: database system was not properly shut down; automatic recovery in progress 2021-11-19 17:47:41.410 UTC [24] LOG: redo starts at 0/16516A0 2021-11-19 17:47:41.427 UTC [24] LOG: invalid record length at 0/17707D8: wanted 24, got 0 2021-11-19 17:47:41.427 UTC [24] LOG: redo done at 0/17707A0 2021-11-19 17:47:41.427 UTC [24] LOG: last completed transaction was at log time 2021-11-19 17:42:39.048739+00 2021-11-19 17:47:41.570 UTC [1] LOG: database system is ready to accept connections 2021-11-19 17:47:59.166 UTC [31] FATAL: unsupported frontend protocol 1234.5680: server supports 2.0 to 3.0 2021-11-19 17:47:59.480 UTC [33] FATAL: unsupported frontend protocol 1234.5680: server supports 2.0 to 3.0 2021-11-19 17:47:59.488 UTC [35] FATAL: unsupported frontend protocol 1234.5680: server supports 2.0 to 3.0 2021-11-19 17:48:03.673 UTC [37] FATAL: unsupported frontend protocol 1234.5680: server supports 2.0 to 3.0 2021-11-19 17:48:04.119 UTC [39] FATAL: unsupported frontend protocol 1234.5680: server supports 2.0 to 3.0 2021-11-19 17:48:04.136 UTC [41] FATAL: unsupported frontend protocol 1234.5680: server supports 2.0 to 3.0 2021-11-19 17:48:13.715 UTC [32] WARNING: there is no transaction in progress the bellow log is from double take error: SqliteError: too many SQL variables |
|
looks like a double-take error, see the logs: |
|
Yes .. I noticed in the end it's not compreface as I have stopped compreface and docker-compose forced it up again however I can't find any logs in compreface containers. Then I did the same with double take (deleted the image as well and volumes) reinstalled in Home assistant but still same issue .. Then took anothe lxc and did a docker-compose on double take and it works .. so it must be related to Home Assistant .. or both .. funny enough I have installed nginx on home assistant to be able to access some containers behind .. I'm wondering if this caused some disruptions ... |
|
I wonder if Coral support would help to circumvent this issue. I have an Intel J4125 Gemini Lake mini-pc, and it seems to lack support for AVX. When I boot it with the single container, it exists with just "AVX2 not detected".
|
|
About my last comment: I was using the Hass addon. It makes the AVX2 verification in the beginning of it. However, disabling such verification leads me to localhost:3000 errors when using the frontend. PS: more info at #583 (comment) |
|
CompreFace doesn't support AVX2, it also doesn't support Google Coral, so it won't help. Also, CompreFace doesn't support ARM devices, so it won't work on Raspberry. |
|
In fact, my situation is more like:
So, my question would be more like: Let's say in a remote future, CompreFace supports Google Coral: do you think that by using Google Coral I would be able to circumvent the fact that my CPU does not support AVX instructions? |
|
Version with Google Coral will be based on Tensorflow Lite, so it will require AVX. |
|
Got it. Thank you! |
|
I have got it running without AVX on my nas using these wheel files: yaroslavvb/tensorflow-community-wheels#209. On the docker side, i override the command, like command: "tail -f /dev/null" so it doesnt crashloop, and then i docker exec into the container, installer the non-avx version and manually bringing up: uwsgi --ini uwsgi.ini . It seems to work fine on my NAS so far. But will keep posted if someone is interested. here is what i did to get it work on non-AVX:
|
@TonyTromp Did you use a custom build? Is it possible to share your docker compose yaml? I tried with your instructions and I cannot make it work in my NAS. |
Describe the bug
Running on ubuntu 18.04 with docker following docker compose container exits with error code 132
To Reproduce
Steps to reproduce the behavior:
Followed 0.4.1 release instructions
Expected behavior
It should start
Desktop (please complete the following information):
Additional context
The text was updated successfully, but these errors were encountered: