G241
January 13, 2025, 3:22pm
1
The issue I am facing:
2025-01-13 08:31:15.167 CET [134518/T134546] INFO: Received 8/8 valid NTP replies from ntp.time.nl
2025-01-13 08:31:15.167 CET [134518/T134546] INFO: Time offset: 2.530962e+00 ms (excluded 0 outliers)
2025-01-13 08:31:15.167 CET [134518/T134546] INFO: Round-trip delay: 7.506073e+00 ms (excluded 0 outliers)
**2025-01-13 09:24:27.377 CET [134518/T134549] ERROR: Failed to unlock SHM lock: Operation not permitted in resolveClients() (/app/src/resolve.c:956)**
**2025-01-13 09:24:27.377 CET [134518/T134549] ERROR: Failed to unlock outer SHM lock: Operation not permitted**
2025-01-13 09:31:16.171 CET [134518/T134546] INFO: Received 8/8 valid NTP replies from ntp.time.nl
2025-01-13 09:31:16.171 CET [134518/T134546] INFO: Time offset: 2.807106e+00 ms (excluded 1 outliers)
2025-01-13 09:31:16.171 CET [134518/T134546] INFO: Round-trip delay: 7.566520e+00 ms (excluded 1 outliers)
2025-01-13 10:31:17.105 CET [134518/T134546] INFO: Received 8/8 valid NTP replies from ntp.time.nl
2025-01-13 10:31:17.106 CET [134518/T134546] INFO: Time offset: 2.430814e+00 ms (excluded 1 outliers)
Details about my system:
What I have changed since installing Pi-hole:
Your debug token is: https://tricorder.pi-hole.net/3jqPv6bK/
During executing pihole -d, I got these error lines in ftl.log:
2025-01-13 16:16:59.694 ERROR Failed to unlock SHM lock: Operation not permitted in resolveClients() (/app/src/resolve.c:956)
2025-01-13 16:16:59.694 ERROR Failed to unlock outer SHM lock: Operation not permitted
2025-01-13 16:16:59.695 ERROR Failed to unlock SHM lock: Operation not permitted in resolveClients() (/app/src/resolve.c:956)
2025-01-13 16:16:59.695 ERROR Failed to unlock outer SHM lock: Operation not permitted
Version information:
CORE_VERSION=v5.18.4-600-gefaa0f4
CORE_BRANCH=development
CORE_HASH=efaa0f42
GITHUB_CORE_VERSION=null
GITHUB_CORE_HASH=efaa0f42
WEB_VERSION=v5.21-1058-g603f35d5
WEB_BRANCH=development
WEB_HASH=603f35d5
GITHUB_WEB_VERSION=null
GITHUB_WEB_HASH=603f35d5
FTL_VERSION=vDev-bed065c
FTL_BRANCH=development
FTL_HASH=bed065cc
GITHUB_FTL_VERSION=null
GITHUB_FTL_HASH=bed065cc
G241:
During executing pihole -d, I got these error lines in ftl.log:
2025-01-13 16:16:59.694 ERROR Failed to unlock SHM lock: Operation not permitted in resolveClients() (/app/src/resolve.c:956)
2025-01-13 16:16:59.694 ERROR Failed to unlock outer SHM lock: Operation not permitted
2025-01-13 16:16:59.695 ERROR Failed to unlock SHM lock: Operation not permitted in resolveClients() (/app/src/resolve.c:956)
2025-01-13 16:16:59.695 ERROR Failed to unlock outer SHM lock: Operation not permitted
I am seeing the same errors in FTL.log
https://tricorder.pi-hole.net/J6e1R7z6/
DL6ER
January 14, 2025, 5:22pm
3
Thanks for bringing this up, it will be fixed by
pi-hole:development ← pi-hole:fix/resolve_shm_error
opened 05:23PM - 14 Jan 25 UTC
# What does this implement/fix?
Fixing a glitch reported on Discourse. See li… nk below.
---
**Related issue or feature (if applicable):** https://discourse.pi-hole.net/t/shm-errors-in-ftl-log-for-v6-development/75131/3?u=dl6er
**Pull request in [docs](https://github.com/pi-hole/docs) with documentation (if applicable):** N/A
---
**By submitting this pull request, I confirm the following:**
1. I have read and understood the [contributors guide](https://docs.pi-hole.net/guides/github/contributing/), as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1)
5. I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
## Checklist:
- [x] The code change is tested and works locally.
- [x] I based my code and PRs against the repositories `developmental` branch.
- [x] I [signed off](https://docs.pi-hole.net/guides/github/how-to-signoff/) all commits. Pi-hole enforces the [DCO](https://docs.pi-hole.net/guides/github/dco/) for all contributions
- [x] I [signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) all my commits. Pi-hole requires signatures to verify authorship
- [x] I have read the above and my PR is ready for review.
Further background if you are interested:
This is a (harmless) side-effect of the combination of two PRs:
pi-hole:development ← pi-hole:tweak/delay_v6_names
opened 05:10PM - 06 Dec 24 UTC
# What does this implement/fix?
This PR is an attempt to fix #2124
The de… scribed issue is that some IPv6 clients don't show a host name in the Query Log even when the network table has one.
The reason for this is timing. When a client issues a query over IPv6 quickly after it got this address, the first query arrived
the Pi-hole *before* the client is known to the network table. When FTL now tries to resolve this address's name, it cannot find a name. A few moments later, when the ARP cache is parsed for the next time, FTL may be able to correlate this new address through an identical MAC address to an existing address having a host name. However, as the default value of `resolver.refreshNames` is `IPV4_ONLY`, FTL actually never tries to resolve the address so it never gets to know the IPv6 client's host name.
The attempt we are doing here is *postponing* name resolution of IPv6 clients by two times the ARP processing interval - this should give plenty time for the network table to catch up so that - when the client name is tried to be resolved for the first (and only!) time - we can get it right away.
By default, ARP cache interpretation is run at the `database.DBinterval` interval.
---
**Related issue or feature (if applicable):** #2124
**Pull request in [docs](https://github.com/pi-hole/docs) with documentation (if applicable):** N/A
---
**By submitting this pull request, I confirm the following:**
1. I have read and understood the [contributors guide](https://docs.pi-hole.net/guides/github/contributing/), as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1)
5. I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
## Checklist:
- [x] The code change is tested and works locally.
- [x] I based my code and PRs against the repositories `developmental` branch.
- [x] I [signed off](https://docs.pi-hole.net/guides/github/how-to-signoff/) all commits. Pi-hole enforces the [DCO](https://docs.pi-hole.net/guides/github/dco/) for all contributions
- [x] I [signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) all my commits. Pi-hole requires signatures to verify authorship
- [x] I have read the above and my PR is ready for review.
and the later merged
pi-hole:development ← pi-hole:tweak/ntp_errors
opened 06:09PM - 30 Nov 24 UTC
# What does this implement/fix?
This PR has three changes regarding the NTP i… mplementation:
1. If there was a timeout, we log the used IP address in addition to the host name. This may be useful to determine if only specific servers cause timeouts (as suggested by @deHakkelaar)
2. Do not issue double warnings when receiving NTP replies fails, e.g. skip the first of these two:
``` plain
2024-11-28 05:28:35.590 CET [25437/T25447] WARNING: Could not recv() in reply() (/app/src/ntp/client.c:223): Resource temporarily unavailable
2024-11-28 05:28:35.590 CET [25437/T25447] ERROR: Failed to receive data from NTP server europe.pool.ntp.org: Timeout
```
3. In case the upstream server sends a "kiss code", we interpret and show it (e.g. "access denied" when authentication is required or "rate exceeded" when querying too often). Before, we simply logged
``` plain
Received NTP reply has invalid version, ignoring
```
in such a case.
---
**Related issue or feature (if applicable):** N/A
**Pull request in [docs](https://github.com/pi-hole/docs) with documentation (if applicable):** N/A
---
**By submitting this pull request, I confirm the following:**
1. I have read and understood the [contributors guide](https://docs.pi-hole.net/guides/github/contributing/), as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1)
5. I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
## Checklist:
- [x] The code change is tested and works locally.
- [x] I based my code and PRs against the repositories `developmental` branch.
- [x] I [signed off](https://docs.pi-hole.net/guides/github/how-to-signoff/) all commits. Pi-hole enforces the [DCO](https://docs.pi-hole.net/guides/github/dco/) for all contributions
- [x] I [signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) all my commits. Pi-hole requires signatures to verify authorship
- [x] I have read the above and my PR is ready for review.
Each PR on its own didn't show the issue, only the combination revealed it. It happens whenever the internal name resolution of an IPv6-connected device within your local network was postponed to increase the likeliness that we are able to infer its name from the network table if no name is provided by the device itself (commonly happens especially with mobile devices spoofing their MAC addresses for "privacy" reasons).
The FTL code handling locks is self-defensive and knows that this is an error to unlock a lock that has already been unlocked before so no harm is caused and your Pi-holes operate as usual.
1 Like
system
February 5, 2025, 4:29am
5
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.