s6 overlay v2? supervisor not listening #1072
Labels
Comments
|
Same thing on latest ubuntu server with brand new installation |
|
The version of s6 shouldn't matter. We use v2 inside the container and that's what will drive the container daemons. The host version doesn't come in to play. We need to see the |
|
Same issue here running on Raspbian 10 after updating to the latest docker image (2022.04.3). Downgrading back to version 2022.02.1 seems to solve the issue. How I fixed it:
|
Are you sure it is the same issue? Please see the upgrade notes on the Readme for information about buster based operating systems |
|
@PromoFaux I'm pretty sure this is the same issue, since the error message I get is exactly the same as OP's:
|
|
What is the apt list s6*As pointed above, the |
|
Can we also get your Just going by the error message, have you got the env variable Edit: That said, I have just tried on Double edit: Same thing on Rpi (Raspbian Buster) - works with no issue... |
|
Ah hold on. Both @Falenone and @Bauxitedev - I think this is another side-effect of the outdated libseccomp issue @Bauxitedev, as you're on Raspbian Buster - take a look at this comment here to see if that fixes things #1042 (comment) @Falenone : I'm not sure if there is a similar solution for Ubuntu 20.04, but the original issue on the moby repo is probably worth a read in your case Edit: TL;DR you need to be running |
|
I am also getting this error every time I am restarting or stopping container after I updated pihole to the latest version. 2022-04-27T16:59:33Z INF Autoupdate frequency is set autoupdateFreq=86400000 |
|
What is your |
|
Please find my docket-compose.yml file bellow. (I am using DHCP helper). version: "3"
services:
pihole:
build: ./pihole-doh-dot
container_name: pihole-doh-dot-dhcp
hostname: pihole-svr
ports:
- "53:53/tcp"
- "53:53/udp"
- "8008:80/tcp"
restart: unless-stopped
cap_add:
- NET_ADMIN
- SYS_NICE
environment:
TZ: 'Asia/Kolkata'
WEBPASSWORD: "PASSWORD"
ServerIP: "192.168.0.114"
VIRTUAL_HOST: "pihole.dns"
PIHOLE_DNS_: "127.0.0.1#5053;127.0.0.1#5153"
IPv6: "false"
DNSMASQ_LISTENING: "all"
PIHOLE_DOMAIN: "local"
DNSMASQ_USER: "root"
volumes:
- '/home/pi/pihole-doh-dot-install/pihole/:/etc/pihole/'
- '/home/pi/pihole-doh-dot-install/dnsmasq.d/:/etc/dnsmasq.d/'
- '/home/pi/pihole-doh-dot-install/config/:/config/'
depends_on:
- dhcphelper
networks:
backend:
ipv4_address: '172.33.0.100'
dhcphelper:
build: ./dhcp-helper
container_name: pihole-dhcp-helper
hostname: dhcp-helper-svr
restart: unless-stopped
network_mode: "host"
command: -s 172.33.0.100
cap_add:
- NET_ADMIN
networks:
backend:
ipam:
config:
- subnet: 172.33.0.0/16 |
|
This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days. |
|
This issue still there. |
|
What is the output of And |
Host:Listing... Done libseccomp2/stable 2.5.1-1+deb11u1 armhf Pihole:Listing... Done Docker
|
|
What is the dockerfile for the image you are building? |
|
I re-read this whole issue. You said you are receiving this error message: Do you have other problems besides this message? |
|
Yes, I am only getting this message while rebooting the container, and this started from the latest version of pihole, other than getting this message, pihole itself running fine.
|
|
So you don't have an issue. Note: |
|
Yes, I don't have any issue other than those messages in the longs. |
|
Same problems here. Seeing the same errors. Turns out that an underlying OS update had re-enabled A quick systemctl disable systemd-resolved.service
systemctl stop systemd-resolvedand were back to normal |
|
I have the same issue, container start fails with the same error message. I am using OpenSuse 15.4 (latest packages installed) and have the latest libseccomp2 version installed. Using latest pihole docker image. Systemd-resoved is disabled. Any ideas? |
|
I found (by accident) that my Pi-hole installations running in docker container on OpenSUSE 15.3 also shows this message - but not my other installations running in docker container on Ubuntu LTS 22.04… 🤔
But Pi-hole is up and running 👍🏻 But is this hourly stopping+starting related to this? |
|
I have no idea if this will make a difference to folk here, but we've upgraded the version of S6 inside the container to v3, which is currently in the Please can you try the |
|
This is much worse now: docker container is crash-looping-forever 😢
|
|
@thomasmerz is that a fresh container with empty volume mounts? Looks like the gravity on boot one-shot is timing out... I've not seen that in my testing so far 2022-07-18T09:11:12.047412317Z s6-rc: info: service 1-gravityonboot: starting
2022-07-18T09:11:12.048312560Z s6-rc: info: service lighttpd: starting
2022-07-18T09:11:12.049189884Z Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
2022-07-18T09:11:12.049981123Z s6-rc: info: service lighttpd successfully started
2022-07-18T09:11:12.051501367Z Starting lighttpd
2022-07-18T09:11:12.054524206Z Starting pihole-FTL (no-daemon) as pihole
2022-07-18T09:11:16.124574772Z [i] Neutrino emissions detected...
[✓] Pulling blocklist source list into range
2022-07-18T09:11:16.137937842Z
[✓] Preparing new gravity database
2022-07-18T09:11:16.158206492Z [i] Using libz compression
2022-07-18T09:11:16.158435722Z
2022-07-18T09:11:16.158723799Z [i] Target: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
[✓] Status: Retrieval successful
2022-07-18T09:11:16.764462978Z s6-rc: fatal: timed outThe key here being: I wonder what, if anything, is causing |
|
To troubleshoot start problems I 've added in dockerfile You could set theese in docker-compose env. |
This may be where i was going wrong with my testing - it was on my desktop :D |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Closed
|
@thomasmerz can you try again on latest dev, please? |
I tried with this:
Result:
|
|
Running with
Last messages: Waiting for…?! |
|
|
Anything interesting in |
|
If you mean that "errors" or "warnings" are "interesting": no. |
|
The warnings can be ignored, and will be sorted on the next FTL release pi-hole/FTL#1384 The Err's however, that is a new one to me! @DL6ER ? |
|
We've seen them before, it's a bug in However, there may be more similar bugs in the Dnsmasq code. @thomasmerz could you find the exact lines in |
|
|
Sorry, I could have been clearer. These warning have been triggered by queries happening at that time. The queries causing these errors have been logged in |
|
I got you and focussed on "2022-07-22 16:40:0x": |
|
~16:45 |
|
~20:40:10 |
|
~21:21:43: |
|
Okay, so nothing unexpected, these errors all come from |
|
This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days. |
|
I'm currently experiencing the same issue and been unable to resolve it through the suggestions here / in other issues. Environment
PiHole
LatestShow/Hide `dokku git:from-image pihole pihole/pihole:latest` logsFails with: v2022.02.1Show/Hide `dokku git:from-image pihole pihole/pihole:2022.02.1` logsBuilds without issues Show/Hide `dokku run pihole` logsThrows |
|
The issue you are seeing is actually: #1176 Please try the |
This can be ignored, and AFAIK is not an issue on the latest images |
Will post my test-results there in a moment, thanks for the quick reply! |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a: Run Issue (running Pi-hole container failing)
Details
On my Ubuntu 20.04.4 LTS with Docker version 20.10.14 The container won't start up using the official latest image
Related Issues
I did not find anything similar
How to reproduce the issue
These common fixes didn't work for my issue
docker runexample(s) in the readme (removing any customizations I added)If the above debugging / fixes revealed any new information note it here.
Add any other debugging steps you've taken or theories on root cause that may help.
I went to s6 folks and they pointed out that I have s6 overlay v3 and the container possibly uses v2. What can I do to get it up and running?
The text was updated successfully, but these errors were encountered: