Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
docker container exits within ~15 seconds
See original GitHub issueHi there. After running the docker container using: docker run -d -p 2700:2700 alphacep/kaldi-en:latest with python8.0 it exits after about 15 seconds. i don’t see any errors in docker console (below) i do see an error from command line, but i think b/c the docker container shuts down any tips?
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:192) Decoding params beam=13 max-active=7000 lattice-beam=6
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:195) Silence phones 1:2:3:4:5:6:7:8:9:10:11:12:13:14:15
LOG (VoskAPI:RemoveOrphanNodes():nnet-nnet.cc:948) Removed 1 orphan nodes.
LOG (VoskAPI:RemoveOrphanComponents():nnet-nnet.cc:847) Removing 2 orphan components.
LOG (VoskAPI:Collapse():nnet-utils.cc:1472) Added 1 components, removed 2
LOG (VoskAPI:CompileLooped():nnet-compile-looped.cc:345) Spent 0.0211859 seconds in looped compilation.
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:219) Loading i-vector extractor from /opt/vosk-model-en/model/ivector/final.ie
LOG (VoskAPI:ComputeDerivedVars():ivector-extractor.cc:183) Computing derived variables for iVector extractor
LOG (VoskAPI:ComputeDerivedVars():ivector-extractor.cc:204) Done.
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:237) Loading HCLG from /opt/vosk-model-en/model/graph/HCLG.fst
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:256) Loading words from /opt/vosk-model-en/model/graph/words.txt
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:264) Loading winfo /opt/vosk-model-en/model/graph/phones/word_boundary.int
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:272) Loading CARPA model from /opt/vosk-model-en/model/rescore/G.carpa
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:192) Decoding params beam=13 max-active=7000 lattice-beam=6
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:195) Silence phones 1:2:3:4:5:6:7:8:9:10:11:12:13:14:15
LOG (VoskAPI:RemoveOrphanNodes():nnet-nnet.cc:948) Removed 1 orphan nodes.
LOG (VoskAPI:RemoveOrphanComponents():nnet-nnet.cc:847) Removing 2 orphan components.
LOG (VoskAPI:Collapse():nnet-utils.cc:1472) Added 1 components, removed 2
LOG (VoskAPI:CompileLooped():nnet-compile-looped.cc:345) Spent 0.013211 seconds in looped compilation.
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:219) Loading i-vector extractor from /opt/vosk-model-en/model/ivector/final.ie
LOG (VoskAPI:ComputeDerivedVars():ivector-extractor.cc:183) Computing derived variables for iVector extractor
LOG (VoskAPI:ComputeDerivedVars():ivector-extractor.cc:204) Done.
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:237) Loading HCLG from /opt/vosk-model-en/model/graph/HCLG.fst
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:256) Loading words from /opt/vosk-model-en/model/graph/words.txt
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:264) Loading winfo /opt/vosk-model-en/model/graph/phones/word_boundary.int
LOG (VoskAPI:ReadDataFiles():vosk/model.cc:272) Loading CARPA model from /opt/vosk-model-en/model/rescore/G.carpa
brig-iMac:websocket brig$ ./test.py test.wav
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/websockets/http.py", line 139, in read_response
status_line = await read_line(stream)
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/websockets/http.py", line 219, in read_line
raise EOFError("line without CRLF")
EOFError: line without CRLF
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/websockets/client.py", line 101, in read_http_response
status_code, reason, headers = await read_response(self.reader)
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/websockets/http.py", line 141, in read_response
raise EOFError("connection closed while reading HTTP status line") from exc
EOFError: connection closed while reading HTTP status line
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "./test.py", line 22, in <module>
asyncio.get_event_loop().run_until_complete(
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/asyncio/base_events.py", line 608, in run_until_complete
return future.result()
File "./test.py", line 8, in hello
async with websockets.connect(uri) as websocket:
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/websockets/client.py", line 517, in __aenter__
return await self
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/websockets/client.py", line 542, in __await_impl__
await protocol.handshake(
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/websockets/client.py", line 290, in handshake
status_code, response_headers = await self.read_http_response()
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/websockets/client.py", line 103, in read_http_response
raise InvalidMessage("did not receive a valid HTTP response") from exc
websockets.exceptions.InvalidMessage: did not receive a valid HTTP response
brig-iMac:websocket brig$ docker run -d -p 2700:2700 docker.io/alphacep/kaldi-en:latest
6219b699d57e515c1be75c9f6fa83448d18acba2c2aa50580a3b6f545ac38ab5
brig-iMac:websocket brig$ ping localhost:2700
ping: cannot resolve localhost:2700: Unknown host
brig-iMac:websocket brig$
Issue Analytics
- State:
- Created 3 years ago
- Comments:11 (5 by maintainers)
Top Results From Across the Web
Why docker container exits immediately - Stack Overflow
A docker container exits when its main process finishes. In this case it will exit when your start-all.sh script ends.
Read more >What to do if a Docker container immediately exits
If you run a container using docker run and it immediately exits and every time you press the Start button in Docker Desktop...
Read more >Why Does My Docker Container Stop? - Tutorial Works
A Docker container exiting doesn't usually indicate that something is wrong. But, nevertheless, you might be wondering why it's exited!
Read more >Understanding Docker Container Exit Codes
The first step in answering this question is to identify the exit code for the docker container. The exit code may give a...
Read more >Docker container stop automatically after running - Webkul
SOLUTION: In order to fix this issue, we need to either leave something running in the foreground or use a process manager such...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I’m coming late to this but I had the exact same problem on my Mac Notebook running Docker Desktop.
I think it’s a memory problem. I noticed that Docker Desktop has a max memory setting of 2G. I’ve got 16G in my Notebook so I cranked it up to 7G (randomly) and it now gets as far as listening on the port and responding (i.e. runs perfectly 😃 )
My guess is that the (virtual) host OS (hyperkit) is killing the process during startup as it grows.
Great software btw. I really appreciate the effort that’s gone into this.
Just to finish on this, I built a new image using the full en-us model (vosk-model-en-us-0.22). With Docker Desktop memory still set to 7G I ran this and the behaviour happened again. The output of docker run (foreground) is:
and that’s where it ends - exactly as before.
Increasing the Docker Desktop memory setting to 8G lets it run:
The key is that it has finished its initialisation and is now listening.
Needing 8G for the full en-us model exactly agrees with the Troubleshooting section here.
The moral of the story is that these models are memory hungry and you need to allocate sufficient resources. On top of that, running the server in a container makes it slightly more tricky to track this down and on top that running on a mac (and I’m guessing on windows as well) where the docker host is itself virtualised makes this a little more difficult still. In these cases the (virtual) OS is terminating the process (with extreme prejudice 😃) during its initialisation stage but there is no indication that this is what has happened. I’d say the key thing to notice is that the server never gets beyond initialisation to the listening stage.