Skip to content
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

[BUG] Fatal Python error: init_interp_main: can't initialize time #20

Closed
maxirus opened this issue Jun 12, 2021 · 4 comments
Closed

[BUG] Fatal Python error: init_interp_main: can't initialize time #20

maxirus opened this issue Jun 12, 2021 · 4 comments

Comments

@maxirus
Copy link

maxirus commented Jun 12, 2021

When running on a Raspberry Pi 4, I get the following error:

Fatal Python error: init_interp_main: can't initialize time
Python runtime state: core initialized
PermissionError: [Errno 1] Operation not permitted

Current thread 0xb6f40390 (most recent call first):
<no Python frame>

Based on other project threads (ie. here), it appears to be a problem with Alpine and the RPi.

Installing libseccomp2 from backports is a workaround.

@maxirus
Copy link
Author

maxirus commented Jun 12, 2021

Changing the base image from alpine to slim-buster resolves the issue.

@dchesterton
Copy link
Owner

I'd prefer to use alpine base images rather than slim to keep image sizes as small as possible and as it appears to be an issue just with Docker and Raspberry Pi 4's and there are documented fixes (e.g. https://blog.samcater.com/fix-workaround-rpi4-docker-libseccomp2-docker-20/) I'm going to close this.

@maxirus
Copy link
Author

maxirus commented Jul 23, 2021

@dchesterton we're talking about a difference of ~50mb between alpine and slim. You'll find more issues with Alpine down the road (ie. musl DNS) that just create more headaches than it's worth to save a few MBs for an image that will not be pulled too often. Image size is really only paramount in situations where you have highly elastic workloads.

I would strongly encourage you to reconsider as Debian based images have much better support, especially in the @Home environment. Or at the very least, build for both using a separate tag.

@dchesterton
Copy link
Owner

I've built many, many Docker images based on Alpine and it's always worked flawlessly. I'll happily use a more feature packed base image when I have a more complicated project with more dependencies but this is a fairly simple script and Alpine suits it just fine. I also disagree that image size doesn't matter much beyond Kubernetes etc. but that's a discussion for another day 🙂

There's a documented fix and this issue itself is not even a problem with Alpine per-se but more outdated dependencies on the host. Therefore, all things considered, I'm not going to add a Debian build and unnecessarily increase the complexity of the build process.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants