PHP error_reporting level changed?
I notice that now a lot of warning/deprecated sort of messages are now being emitted - which is a good thing and the reasons should be found and fixed. But I don't remember seeing a change that modified the general/default error_reporting settings.
Did that change a few days ago?
If so, from what to what?
(I guess the setting is in pfsense-tools build somewhere - I haven't looked at that)
It would just be nice to know what default error reporting is on now, so as to give an idea of the range of fussy stuff that might be reported to syslog or pop out accidentally as text on the GUI.
fragged last edited by
I must be blind - I remember seeing that now!
At the end of a script that is reporting the last error seen, if the last error is not E_NOTICE.
I was trying to reproduce the message:
php-fpm: /rc.newipsecdns: PHP ERROR: Type: 8192, File: /etc/inc/shaper.inc, Line: 4365, Message: Assigning the return value of new by reference is deprecated
That is reported in https://forum.pfsense.org/index.php?topic=86448.0
I could not get it to do it on my system, with a few limiters. Then I took out the "not E_NOTICE" check. Then I started seeing the last error regardless of what it is. There are various E_NOTICE errors that happen on my configuration after the error, like:
http://php-fpm: /exec.php: PHP ERROR: Type: 8, File: /etc/inc/shaper.inc, Line: 4371, Message: Undefined index: queue]php-fpm: /exec.php: PHP ERROR: Type: 8, File: /etc/inc/shaper.inc, Line: 4371, Message: Undefined index: queue
http://php-fpm: /exec.php: PHP ERROR: Type: 8, File: /etc/inc/shaper.inc, Line: 3105, Message: Undefined index: burst]php-fpm: /exec.php: PHP ERROR: Type: 8, File: /etc/inc/shaper.inc, Line: 3105, Message: Undefined index: burst
After putting appropriate "isset() &&" code before is_array() in those places, I got the code so the last error is that "Assigning the return value of new by reference is deprecated" one, and it then appears in syslog.
So that error thing is a bit hit-and-miss, because the system is also remembering E_NOTICE stuff along the way, but then not reporting E_NOTICE. That can cause nothing to be reported, even though there was some other reportable-level message earlier in the code.
But with E-NOTICE being reported, there are 100s of things - all about unassigned variables… which is just lots of code that does not initialize vars, it lets the PHP default happen, that if a var is not set then that is treated as "empty","false"...
It would be a huge job to explicitly init every var before it is referenced - the code was just never written in that style.
It seems to be possible to also use set_error_handler() to have an error handler that can check the error level and log a message if the error is a level we care about, and then return and allow the code to continue (for non-fatal errors). That would get all the interesting error messages reported on-the-fly, rather than just the last one.
Is it worth looking into that?
The other way, which I used to quickly gather all the "not E_NOTICE" messages on my test system, was to add to /etc/rc.php_ini_setup:
error_reporting = E_ALL & ~E_NOTICE
Then these sort of error/warning/deprecated things come as "crash reports" to the dashboard. It is then easy to see the messages and go and fix the offending files.
Is it worth having that on in the RC so that everyone will quickly find and report these things as they exercise all the various menu options?
cmb last edited by
That seemed like a good idea at the time, but now I'm wondering. Yeah it's spewing stuff that's not necessarily helpful, sure it should be fixed, but might end up going back and silencing that.
Thanks for the pull request to fix at least some of that, I merged it.