hm interesting.
I let the disabled timer, time out and re-enable blocking and once again the CPU climbed and the DNS could not resolve any nslookups
Back to high usage.
Suppose I will downgrade the instance and see if it helps due as I am unable to pinpoint the concern.
Downgrade was successful so far:
Version
Core: 6.0.4
FTL: 6.0.2
Web: 6.0.1
going to allow some more clients to filter in and hit the pihole DNS to see if the outcome is stable.
will follow up this eve with updates as I am going to be working on this and monitoring all night.
Downgrading the instance to 6.0.4 has all device up and running 100% and doesn't trigger CPU pinning like 6.0.5 did.
All clients are operational for now, going to sit on 6.0.4 for a few days and hold off on upgrading the instance until a few new revisions are pushed
Thank for the help troubleshooting today!
The problem is that the issue is not going to get resolved without further input from you as - much to my disliking - any attempts to reproduce it locally here on any of the testing systems have failed, so far. As Pi-hole consists of three components, could you be a bit more specific which version you mean with 6.0.4.
Furthermore, it'd indeed be tremendously helpful if you could help us identify which of the components cause these issues for you, e.g. running
pihole checkout ftl v6.0.4
pihole checkout web v6.0.2
leaving core at where it was to see if it is really the core component update from 6.0.4 to 6.0.5 which is causing this. The core component can be switched like
pihole checkout core v6.0.5
vs.
pihole checkout core v6.0.4
If that's indeed the cause, the following would be very helpful:
ls -l /etc | grep pihole
ls -l /etc/pihole
once on the working and the problematic system. Permission errors are my current best bet if it is really the core version that is causing the issues here.
Hello @DL6ER
If I can be of further assistance I will be. I did take a backup of the 6.0.5 instance and can re-deploy it to further assist you and the community.
If there is a good time to work with you on discovery I am happy to help. My assumption is the CPU pinning was related to FTL and/or maybe db writes as the logs showed many time the db was busy and dropped DNS lookups?
So far downgrading from:
Core: 6.0.5
Web: 6.0.2
FTL: 6.0.4
to
Core: 6.0.4
Web: 6.0.1
FTL: 6.0.2
is working stellar, no issues to report, smooth sailing, fast & stable 
Let me know your thoughts when you have a moment.
Thank you.
You probably mixed the checkout statements?
with either
should have resulted in
Core: 6.0.4 or 6.0.5
Web: 6.0.2
FTL: 6.0.4
Hello, running sudo checkout commands prompts to switch branches, which at this time I am avoiding due to the concerns that were previously stated.
At the preset time the instance is running the following versions with a stable outcome:
Core version
[✓] Version: v6.0.4
[i] Remotes: origin https://github.com/pi-hole/pi-hole.git (fetch)
origin https://github.com/pi-hole/pi-hole.git (push)
[i] Branch: master
[i] Commit: v6.0.4-0-g567bb72
Web version
[✓] Version: v6.0.1
[i] Remotes: origin https://github.com/pi-hole/web.git (fetch)
origin https://github.com/pi-hole/web.git (push)
[i] Branch: master
[i] Commit: v6.0.1-0-g42e7279
FTL version
[✓] Version: v6.0.2
[i] Branch: master
[i] Commit: ac500d5f
Let me know if I can be of any further assistance.
Thank you.
Checking back to see if there are any bug fixes coming down the pipe (6.0.6+).
Thank you 
Updated to the following version since the initial post/report:
Core v6.0.6
FTL v6.1
Web interface v6.1
No father concerns to report.
The following version above resolved and addressed the concern.
Thank you!
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.