can't set correct time
HerrFrutti opened this issue · 6 comments
Error:
[-1227173427] unbound[1:1] error: gettimeofday: Operation not permitted
if you get the time inside the container:
root@unbound:/opt/unbound# date
Thu Jan 1 01:00:00 CET 1970
root@unbound:/opt/unbound# zdump /etc/localtime
/etc/localtime Fri Feb 27 19:29:32 1970 CET
root@unbound:/opt/unbound# cat /etc/timezone
Europe/Berlin
my docker compose:
unbound:
container_name: unbound
image: mvance/unbound-rpi:latest
hostname: unbound
#ports:
# - "53:53/tcp"
# - "53:53/udp"
volumes:
- "./unbound:/opt/unbound/etc/unbound"
- "/etc/timezone:/etc/timezone:ro"
- "/etc/localtime:/etc/localtime:ro"
networks:
macvlan-nw:
ipv4_address: 192.168.X.X
restart: always
I don't know how to get the correct time inside the container...
And that leads to DNSSEC -> SERVFAIL
$ dig sigok.verteiltesysteme.net @192.168.X.X
; <<>> DiG 9.10.6 <<>> sigok.verteiltesysteme.net @192.168.X.X
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59399
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sigok.verteiltesysteme.net. IN A
;; Query time: 10 msec
;; SERVER: 192.168.X.X#53(192.168.X.X)
;; WHEN: Sun Jan 09 00:14:26 CET 2022
;; MSG SIZE rcvd: 55
- /usr/share/zoneinfo/Europe/Berlin:/etc/localtime:ro
doesn't change anything...
thanks.
My Pi runns buster. I'll try installing bullseye tomorrow and let you know.
quick update:
on ubuntu with the non rasp image it works. Right now installing bullseye and will report the result!
With Raspberry Pi OS Bullseye it works!
Only error I'm getting now:
[1641840076] libunbound[19:0] error: udp connect failed: Cannot assign requested address for 2001:500:9f::42 port 53
Thank you for the update. It's an odd one, but the Bullseye upgrade does the trick. It doesn't make sense to me that a Bullseye container doesn't run on a Pi with Buster, but that was my experience.
As for the remaining error, it's a long-standing issue. I don't know how to solve it, but it doesn't appear to cause any problems beyond log noise/volume. I think it's an upstream issue that manifest with Docker, given how it treats IPv6.