Connectivity / auth / api issues after update to 6.x

Expected Behaviour:

I should be able to login to pi-hole using the web interface
I should be able to ssh into pi-hole

Actual Behaviour:

I often get: "API seats exceeded increase webserver.api.max_sessions" error when attempting to login via web interface.

I get 429 Too Many Request errors returned to a python script that queries the API every 10 mins

My ssh sessions stop responding / freeze

I have tried increasing webserver.api.max_sessions but it does not seem to fix the problem.

I have been running pi-hole for many years without issues. These are since recent update to 6.x

I cant ssh in to run a debug ATM. (session froze.. when I try to reconnect I get: client_loop: send disconnect: Broken pipe)

I have also noticed CPU spiking to > 50% which I have never seen in the past.


I just rebooted the pi-hole and after reboot it seems to have forgotten it hostname ? I can now only hit it on its ip ?

If you encrypt the API, then each new query is a separate seat.

Try turnng off the python script, restart FTL and see if the problem resolves.

And, please upload a debug token as requested by our help template.

Apparently your script is not using sessions correctly.

If a script is authenticating again and again, every time it queries the API, it also needs to logout and delete the session every time, to avoid session exhaustion.

Execute the steps suggested by jfb.

Thanks,

It is authenticating every time..

Based on the API Authentication Documentation:

"By default, the session lasts for 5 minutes."

And I only hit the API every 10mins, so I auth every time ??? Is this incorrect ?

After reboot the pi-hole is no longer responding on pi-hole.local ?

I went into the advanced settings and "dns.domain" was changed back to default of "lan"

I changed it back to "local" but I still cannot connect to: pi-hole.local ?

Please generate a debug log, upload it and post the token URL here.

https://tricorder.pi-hole.net/LdvQQvE5/

Right off the top, a problem noted:

*** [ DIAGNOSING ]: Operating system
[✓] Distro:  Raspbian
[✗] Version: 10
[✓] dig return code: 0
[i] dig response: "Raspbian=11,12 Ubuntu=20,22,23,24 Debian=11,12 Fedora=40,41 CentOS=9"
[✗] Error: Raspbian is supported but version 10 is currently unsupported (https://docs.pi-hole.net/main/prerequisites/)

Raspbian/Debian Buster is no longer supported by either Debian or Pi-hole.

I recommend that you save your Pi-hole settings with teleporter, and then upgrade your OS to a supported OS. Then reinstall Pi-hole and import your saved settings.

Will an older saved set of settings < 6.x work or will I need a fresh set ? Some of my settings appear to have been changed during update to 6.x

Hang onto both. The V6 settings should be correct, but have the older set just in case.

Where did you see this? Session expires after 1800 seconds by default.

I don't know how your script is handling the sessions, but the message "API seats exceeded" means you are not correctly deleting the sessions after using them.

You can take a look at the api.sh file used by pihole api command.

The apiFunc() function does basically 3 steps:

  1. Login to the API;
  2. execute the commands to retrieve the data and show the returned values (or error messages in case of error)
  3. Logout (to delete and free the session).

Pi-hole API Documentation:

Authentication

POST/Auth

2nd paragraph:

"Both the Session ID (SID) and CSRF token remain valid for the session's duration. The session can be extended before its expiration by performing any authenticated action. By default, the session lasts for 5 minutes. It can be invalidated by either logging out or deleting the session. Additionally, the session becomes invalid when the password is altered or a new application password is created."

1 Like

If you are not logging out or deleting the sessions, they will be expired, but still occupying a seat.

If I were to cache the SID between api calls, how long will the SID be valid for once retrieved ?

Your log shows the timeout is set to 1800 seconds, but you don't need to cache it.

If you authenticate (creating a new session), use the SID and then delete the session every time after using it, you can repeat the process.

Thanks. We need to correct this.

I'm having a hard time with this.

The pi-hole is quite unstable ATM..

When I can connect to its web interface via ip address, I'm seeing CPU spiking to 130%..

It intermittently resolves external lookups but local network resolution does not work.

I'm looking for the quickest way to get back core functionality.

Should I uninstall latest pi-hole 6.x and install an older release (5.18.3 ?) that seemed to be working fine prior to update ?

Any guides to doing the above ?

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.