Bug #5044
closed
PHP-FPM Segmentation fault after Configuration Import of 2.0.1-RELEASE config
Added by MF Mark over 8 years ago.
Updated over 8 years ago.
Description
After installing from a fresh 2.2.4 nanobsd serial image, getting a segmentation fault in PHP-FPM after importing a configuration from another (identical hw) production PFSense Alix WRAP setup.
Is difficult to supply a fully redacted config.xml. Does anyone have a script for this?
Please advise guys.
Files
Just for clarity this seems to happen on boot (observed via serial console) and any attempt as restarting of it results in the same.
Found a core dump file hiding in /var/log/ which might help towards people figuring out what was going on here.
- Project changed from pfSense Packages to pfSense
- Status changed from New to Feedback
- Priority changed from High to Normal
- Affected Version deleted (
2.2.4)
this certainly isn't true in general, and not going to be possible to replicate given people have restored thousands of 2.0.x configs to 2.2.x with no issue. Could you send me the config privately? Email to cmb at pfsense dot org. Downloading the status file from status.php will sanitize most sensitive things.
I can report that the bug is not present in pfSense-2.2.5-DEVELOPMENT-2g-i386-nanobsd-20150825-1210 I wonder what fix was contributed for this to be the case.
- Assignee set to Chris Buechler
Thanks for sending your config. It isn't replicable restoring to a 64 bit VM. It's from an ALIX it appears though, maybe nano or 32 bit specific, or slower hardware. I'll give it a shot on an ALIX, don't have one handy at this instant. I can't think of anything that's changed 2.2.4 to 2.2.5 that would have an impact.
Chris Buechler wrote:
Thanks for sending your config. It isn't replicable restoring to a 64 bit VM. It's from an ALIX it appears though, maybe nano or 32 bit specific, or slower hardware. I'll give it a shot on an ALIX, don't have one handy at this instant. I can't think of anything that's changed 2.2.4 to 2.2.5 that would have an impact.
Thanks Chris. Turns out the issues are bigger than this as we are having full kernel panics under device low/medium load. Will put that into a seperate bug to avoid confusing things.
We are now on our second unit just to rule out hardware and it does indeed happen again.
- Status changed from Feedback to Not a Bug
appears to be a hardware issue, can't replicate with same config.
Also available in: Atom
PDF
Updated by 
Updated by