Webserver.session.timeout

[darrenoleary74]

OK, so some additional information to my previous response…

I left the PiHole login screen up with the Dev Tools pane showing, and at exactly 30 minutes after the initial session timeout and for every 30 minutes thereafter for the next couple of hours, it showed auth errors where it indicated the deletion of the session cookie. These repeated at every hh:15 and hh:45.
I noticed that the cookie had been deleted in the last failed auth entry from the original browser session.

I commenced a new PiHole UI session in another browser (on the same computer) prior to the next hh:15 and, sure enough, it timed out at hh:15. I had forgotten to check the Preserve Log checkbox so I have no log information.
I immediately started another session in the same browser (checked the Preserve Log checkbox this time) to see if it would time out at hh:30 or keep going again until hh:45.
The session timed out at hh:30, so UI session timeout does appear to be occurring every :15 minutes.

The only thing that I know of that is running every 15 minutes against all of my PiHole instances is nebula-sync - at :00, :15, :30 and :45.

I’ve now stopped the docker container for nebula-sync and started a new PiHole UI session to see if it times out again at hh:45.

With nebula-sync stopped and hh:45 since passing, the UI session did not timeout, so it then appears there is something related to nebula-sync’s process of data replication from a source to target(s).
To test this, I restarted the nebula-sync container and the PiHole UI immediately timed out.

With all that being said, and given that i’d been running nebula-sync without issue for the better part of the last 12 months since converting from PiHole v5 to v6 and the only thing that changed recently for me has been upgrading to the latest PiHole release, was/has there been any changes to any of the components that could/would cause the UI to timeout to the login screen resulting from nebula-sync’s scheduled process of pushing data from a source to a target(s)?

My compose.yaml file for nebula-sync is set to always run the latest version, currently 0.11.1, which was released about 6 months ago.

My next course of action would be to contact the nebula-sync developer to see if they may be aware of any similar issues reported to them by users on how best to resolve, or unless you might be able to provide a solution.

[Bucking_Horn]

@Bucking_Horn

darrenoleary74, would your nebula-sync include that DNSSEC option, perhaps?

@darrenoleary74

I’ve now stopped the docker container for nebula-sync and started a new PiHole UI session to see if it times out again at hh:45.

With nebula-sync stopped and hh:45 since passing, the UI session did not timeout, so it then appears there is something related to nebula-sync’s process of data replication from a source to target(s).
To test this, I restarted the nebula-sync container and the PiHole UI immediately timed out.

Above demonstrates that nebula-sync sets one or more options in Pi-hole that require a restart, and that a Pi-hole restart would invalidate sessions.

As sessions are stored in Pi-hole's database, it would be expected that sessions do survive a restart:

@rdwebdesign

@Bucking_Horn

Would sessions survive a pihole-FTL restart?

Yes.
Sessions should be stored on the database and reloaded on restart.

If they are not, that would indicate a bug in the recent Pi-hole version.
And indeed, rdwebdesign explained earlier that the most recent optimisations changed the order of execution on FTL restarts, which could be causing your observation:

@rdwebdesign

We are currently investigating another issue that a logout happens when the user changes CNAME records.
(…)
There is already a fix in development branch to change the start order and load the web sessions earlier.

If you'd be willing to help testing this potential fix, you could consider switching to Pi-hole's development branch on one of your Pi-holes:

sudo pihole checkout dev

As operating the development branch may result in unexpected behaviour, you want to backup your existing Pi-hole installation before you do so.

If you'd want to return to the current release at any time, just run

sudo pihole checkout master

[darrenoleary74]

Thanks.

As far as I know and have read, nebula-sync does not use DNSSEC itself, but obviously, will sync any DNSSEC settings to other nodes from the source node if it is configured as such. My source node is not configured to use DNSSEC.

I don’t have a problem with switching to a dev release for either/both of my VM instances. These are backed up each day, so I can easily run them for 24 hours or so and restore them to my current instances. I could even apply it to the source node as I also have a backup that.

I’ll report back if the issue persists or is resolved under the dev branch.

[darrenoleary74]

so far, so good.

Nebula-sync has synchronized 6 or so times and the UI sessions i’ve had open - vIP, VM#1 direct, VM#2 direct and bare-metal direct - have all remained active rather than timing out after 15 minutes.

[Bucking_Horn]

Thank you for testing this.

The error was quite obvious when logout occurred after switching a value like a CNAME or DNSSEC validation via Pi-hole's UI, but less so in your case, with keepalived potentially having contributed, and with nebula-sync applying changes that triggered a restart more covertly.

On a side note: Details like usage of keepalived and nebula-sync probably should be disclosed as early as the initial post (though I don't think it may have made much of a difference here, perhaps only saving a few posts).

Once again, thank you for your patience in tracking this down with us.