New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
URLDownloader doesn't work on docker-compose #146
Comments
Just to confirm, are you using a docker-compose setup? I believe it works on Kubernetes but not on docker-compose. |
Yes, I've forgotten to add this. I use the docker-compose. |
Sadly the code of Kangooroo is not (yet) open-sourced, but I can confirm that they are using the |
I got a new version of Kangooroo, which now allows setting the For future notes, it was brought to my attention that it is recommended to use a seccomp profile when running the container instead of modifying the chrome runtime with --no-sandbox. Seccomp is like an allow list of syscalls, so this list should be what we need to run chrome. An example of a valid profile to use can be found at: https://raw.githubusercontent.com/jfrazelle/dotfiles/master/etc/docker/seccomp/chrome.json This should be enough to get google-chrome working on a docker deployment. |
Describe the bug
I cannot make URLDownloader service working, and it's hard to get any related logs - neither in the production nor development mode. For any URL I send, the results are:
The number of retries has passed the limit.
& task pre-emptedCommand Command '['java', ...]' timed out after 150 seconds
Exception: Kangooroo was probably OOMKilled. Check for memory usage and increase limit as needed.
I tried to debug the issue by copying the generated config and running Kangooroo manually, to see what's happening. Results are:
Logs from Kangaroo
After those stack traces, Kangooroo runs further, but does nothing. However, I've managed to find some logs in the working tmp directory
(...)/tmp/99999ebcfdb78df077ad2727fd00969f/Default/chrome_debug.log
:This has finally directed me to this post, and indeed:
I did this debugging locally, building the image from source (commit
9137c7434dbd3fefcdfa71f82e4611e1f83a7ce9
); when I try to run thegoogle-chrome
command in the productionstable28
image (set up by the AL), the results are similar:(with or without
--headless
is the same)It looks like in both, locally built and the downloaded image, I have the same Chrome version:
To Reproduce
Steps to reproduce the behavior:
stable28
downloader versionExpected behavior
URLs are downloaded. In case of the error, appropriate logs are emitted: currently, without manual running, nothing helpful is preserved or logged.
Screenshots
Environment (please complete the following information if pertinent):
Additional context
I'm not sure if the sandboxing is really the problem, or it's something else. But this is the only one clue I've found.
The text was updated successfully, but these errors were encountered: