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

realtime clock inaccessible on v7.1 image #102

Closed
dervogt opened this issue Jan 20, 2022 · 4 comments
Closed

realtime clock inaccessible on v7.1 image #102

dervogt opened this issue Jan 20, 2022 · 4 comments

Comments

@dervogt
Copy link

dervogt commented Jan 20, 2022

Hi Mike,

it seems there is an issue with the recent v7.1 image and access to the system time after upgrading my piaware image to the "latest" tag.

The piaware container throws a lot of these errors and CPU load is incredibly high:
sleep: cannot read realtime clock: Operation not permitted

WHen reverting to the docker hub tag / image mikenye/piaware:v6.1 the error message goes away and CPU load is back to normal again.

I am running the container in a docker stack, these are my settings from the stack compose file:

piaware:
image: mikenye/piaware:latest
tty: true
container_name: PiAware
hostname: piaware
restart: always
environment:
- TZ=Europe/Berlin
- LAT=53.68030
- LONG=10.03456
- FEEDER_ID=REMOVED FOR GITHUB
- RECEIVER_TYPE=rtlsdr
- BEASTHOST=adsb_rcvr_ham
- BEASTPORT=30005
- VERBOSE_LOGGING=false
- ALLOW_MODEAC=yes
networks:
- ADSB
healthcheck:
disable: true
tmpfs:
- /run:exec,size=64M
- /var/log

-
I know the indentation of the YAML somehow got lost here on github, but I got it right on my docker env.
Let me know if you need anything else.

Running the container in privileged mode seems to be a possible solution as per the web, but this is not supported when running in Stack as far as I know and with the v6.1 image it works flawlessly, hence I reverted back to that version for my prod setup.

@fredclausen
Copy link
Member

fredclausen commented Jan 20, 2022

Mike, I'm not sure your intentions but the image probably needs to be reverted back to buster-20211220-slim to fix the RTC issue (technically libseccomp2 on the host) or bullseye-20211220-slim and provide instructions to use the script that @kx1t made (https://github.com/fredclausen/docker-acarshub/blob/main/arm32.MD / https://raw.githubusercontent.com/fredclausen/docker-acarshub/main/libseccomp2-checker.sh) to fix the issue on the user's host.

FWIW I think it's worth staying on bullseye and providing the user instructions to fix their host. buster at this point is pretty old and upgrading base images to something far less old provides benefits that outweigh the cost of running a simple script on the host.

@mikenye
Copy link
Member

mikenye commented Jan 21, 2022

Hi @fredclausen, thanks so much for this. I will update this image's README.md to include the wording from your repo and comment above. :-)

@fredclausen
Copy link
Member

You're welcome Mike! If it helps you I can move the ARM32 libseccomp2 install stuff in to a new repo and make a more generic readme explaining the issue and the fix.

@mikenye
Copy link
Member

mikenye commented Jan 21, 2022

@dervogt, further to the discussions above, the TLDR is here: https://github.com/fredclausen/Buster-Docker-Fixes. That repo explains everything and has a workaround/fix.

@mikenye mikenye closed this as completed Jan 21, 2022
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

3 participants