Project

General

Profile

Actions
Copy link

Regression #13942

closed

PHP error on ``status_logs_settings.php`` if the configuration contains an empty ``syslog`` section

Added by Marcos M about 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Jim Pingle
Category:
System Logs
Target version:
2.7.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.05
Release Notes:
Default
Affected Version:
2.7.0
Affected Architecture:

Description

See:
https://forum.netgate.com/topic/177633/logs-not-updating-on-23-01

[06-Feb-2023 18:19:00 America/New_York] PHP Fatal error:  Uncaught TypeError: Cannot access offset of type string on string in /usr/local/www/status_logs_settings.php:72
Stack trace:
#0 {main}
  thrown in /usr/local/www/status_logs_settings.php on line 72

config.xml contains:

<syslog></syslog>

Actions
Copy link
 #1

Updated by Marcos M about 1 year ago

  • Status changed from New to Pull Request Review
  • Parent task set to #13446
Actions
Copy link
 #2

Updated by Jim Pingle about 1 year ago

  • Parent task deleted (#13446)
  • Plus Target Version set to 23.05
Actions
Copy link
 #3

Updated by Jim Pingle about 1 year ago

  • Assignee set to Jim Pingle
Actions
Copy link
 #4

Updated by Danilo Zrenjanin about 1 year ago

I couldn't apply the patch on the:

23.01-RELEASE (amd64)
built on Fri Feb 10 20:06:33 UTC 2023
FreeBSD 14.0-CURRENT

Please check.

Actions
Copy link
 #5

Updated by Marcos M about 1 year ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #6

Updated by Danilo Zrenjanin about 1 year ago

I applied the patch (8b962c6a752a654f2def293d93c102d2d20a6887) and then made a backup. I added an empty <syslog></syslog> tag in the backup file and then restored the backup config. The PHP error appeared right after visiting the system logs settings.

Please check again.

Actions
Copy link
 #7

Updated by Jim Pingle about 1 year ago

Danilo Zrenjanin wrote in #note-6:

I applied the patch (8b962c6a752a654f2def293d93c102d2d20a6887) and then made a backup. I added an empty <syslog></syslog> tag in the backup file and then restored the backup config. The PHP error appeared right after visiting the system logs settings.

Please check again.

What was the exact error you observed? Are you certain the patch applied fully/successfully?

Actions
Copy link
 #8

Updated by Jim Pingle about 1 year ago

I tried again on a fresh snapshot and <syslog></syslog> does not produce a crash. If you added a tag you might have actually added a second <syslog> section which resulted in a different error. The default configuration already contains a <syslog> section with one setting defined inside.

Actions
Copy link
 #9

Updated by Danilo Zrenjanin about 1 year ago

  • Status changed from Feedback to Resolved

That was my bad. I probably didn't wait long enough for the system_package to finish the installation process after restoring the config on 23.01.

I tested again on the 2.7.0.a.20230330.0600, and after restoring the config with an empty <syslog></syslog> tag, there was no PHP error.

It's fixed. I am marking this ticket resolved.

Actions
Copy link
 #10

Updated by Jim Pingle about 1 year ago

  • Subject changed from PHP error when viewing system logs settings to PHP error on ``status_logs_settings.php`` if the configuration contains an empty ``syslog`` section

Updating subject for release notes.

Actions
Copy link

Also available in: Atom PDF