Scheduled Report pdf(s) blank with msg - Your session has timed out.

[BenCowan]

Environment: RHEL9 Installed Version: 2024R1.3.4

Following upgrade to 2024R1.3.4 (also upgraded php 8.1 to 8.3) our scheduled reports stopped working. The emailed attached pdf are blank with the exception of message - Your session has timed out.

I'm still searching logs, but so far only have observed this error in chromium_report.log:

7699 bytes written to file /home/nagios/scheduledreport-bcowan-FtFBsS4OYsQu-1742221802-Alerts - Last 24 Hours.pdf
[Mon, 17 Mar 2025 15:46:39 +0000] chromium-browser --headless=new --ignore-certificate-errors --enable-low-end-device-mode --disable-gpu --virtual-time-budget=10000 --run-all-compositor-stages-before-draw --no-pdf-header-footer --desktop-window-1080p --print-to-pdf='/home/nagios/scheduledreport-bcowan-FdEvm9ISAE7o-1742226399-Alerts - Last 24 Hours.pdf' 'http://localhost/nagiosxi/includes/comp ... dfrender=1'
[3462882:3462882:0317/084639.995734:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.portal.Secret.RetrieveSecret: object_path= /org/freedesktop/portal/desktop: org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.Secret” on object at path /org/freedesktop/portal/desktop
[3462882:3462882:0317/084639.995747:ERROR:secret_portal_key_provider.cc(150)] Failed to retrieve secret: No response from portal.
7699 bytes written to file /home/nagios/scheduledreport-bcowan-FdEvm9ISAE7o-1742226399-Alerts - Last 24 Hours.pdf

[gwesterman]

Hi @BenCowan,

Try running the command directly from the CLI. What does it output? Does the pdf exist or does it never get generated?

Are session.cookie_secure or session.cookie_samesite set in your php.ini? Try setting them to 0 or Off and restarting php-fpm.

It may also be worth it to try updating your packages.

Let us know what you find out.

Thank you!

[BenCowan]

Running from CLI gives the same response. I tried modifying php.ini as you advised and ran it again, with same results. Which packages were you referring to for updates?

[BenCowan]

I just resolved this by restoring our test server to a date prior to my upgrades to XI 2024R1.3.4/php 8.3. I copied the php.ini from the 2024R1.3.3/php 8.1 test server to our production system and the scheduled reports started working again.

I will update this issue if I can determine the specific line(s) that were causing the problem.

[BenCowan]

I believe the problem is due to a new php.ini that is introduced when you upgrade to remi php 8.3. I went through all the differences and isolated the problem properties:

> date.timezone = America/Los_Angeles
< session.use_strict_mode = 0
---
> session.use_strict_mode = 1

The upgrade had session.use_strict_mode = 0. Previously, our php.ini had session.use_strict_mode = 1. In my testing I found that if you enable strict_mode, you also need to have date.timezone defined. Not sure I understand why...

Many other settings are introduced that are not ideal for our environment and need to be customized, but these are the ones that caused the error 'Your session has timed out' in our environment.

This can be closed.

[Mikasa23]

I believe the problem is due to a new php.ini that is introduced when you upgrade to remi php 8.3. I went through all the differences and isolated the problem properties:

> date.timezone = America/Los_Angeles
< session.use_strict_mode = 0
---Baseball Bros Game
> session.use_strict_mode = 1

The upgrade had session.use_strict_mode = 0. Previously, our php.ini had session.use_strict_mode = 1. In my testing I found that if you enable strict_mode, you also need to have date.timezone defined. Not sure I understand why...

Many other settings are introduced that are not ideal for our environment and need to be customized, but these are the ones that caused the error 'Your session has timed out' in our environment.

This can be closed.

Glad to see you solved the problem. Do you think there might be an automated way to check and adjust php.ini changes after upgrading PHP? This would save others from having to do this manually in the future.

[BenCowan]

Sorry for the late reply. I use a script to upgrade php on my nagios servers, and this is the first time I've run into this problem, but I saved a copy of my php.ini, in an Ansible role I use for XI upgrades. I don't plan to automate the php upgrade, but I could add a step to my script to compare my php.ini to the /etc/php.ini following an upgrade, to see if anything has changed.