Segmentation fault when "updating database..." after upload

[JJ Fullmer]

I am trying to update my base image as I have done many times (so I’m pretty sure the issue isn’t the image or vm as the last successful upload for this image from this vm was 6 days ago)
I am suddenly getting this message in the apache error log

[Mon Feb 29 14:27:11.998127 2016] [core:notice] [pid 1027] AH00052: child pid 2371 exit signal Segmentation fault (11)
[Mon Feb 29 14:26:50.971240 2016] [core:notice] [pid 1027] AH00052: child pid 4057 exit signal Segmentation fault (11)
[Mon Feb 29 14:26:30.951298 2016] [core:notice] [pid 1027] AH00052: child pid 2368 exit signal Segmentation fault (11)

While the upload is hanging here…

This is the output of top on the server

Running on centos 7 ver 6505 with php 7

Is this just me or are others having this problem?

[JJ Fullmer]

I just remembered, I recently changed my bootfile to ipxe.kkpxe to test compatibility with some older machines.
Could that have anything to do with it?

[Tom Elliott]

I’m testing what I hope will fix. The segmentation fault, I don’t think, was the problem (directly).

It was the recent changes to the fogftp class. I’ve pushed what I hope will fix the issues, and am running a personal test at the moment.

I’ll keep you updated as I see more info as well.

[Tom Elliott]

@Tom-Elliott My fix didn’t fix the issue, though it does properly complete the tasking now, it’s failing to rename/put the file.

[JJ Fullmer]

I will test you fix as well deleting the current failed to move image first

[Tom Elliott]

@Arrowhead-IT fix pushed, after you test please let us know if it is indeed fixed.

[JJ Fullmer]

Testing now,
First thing I’m noticing is a bit of a speed decrease on the upload. It use to stay around 2 GB/min give or take
This time it dropped from 2 down to 800 MB/min but is speeding back up and settling around 1.4 GB/min. Not a huge deal since my image is only ~23 GB. But it’s just odd that this would change. Might also be the kernel update or something.

[JJ Fullmer]

Well it kept speeding up and ended up finishing about the same time as before, so there was more speed fluctuation than I usually see. So lets just ignore that.

Anyway it is back to hanging at updating database =(
So sadly no, not fixed.

Wait… what.
So while I was editing this post I decided to check the permissions of the images directories.
I noticed they were all set to 777 but owner and group was root.
From /images I ran chown _R fog.root ./ && chmod -R 775 ./ (from an alias if it matters)
Then suddenly I noticed the vm screen started doing things…And boom! it finished successfully.

Perhaps the permissions change in the upload image process needs to also change the owner to the fog user?
That or the updating database part now takes like 10 minutes and it was just coincidence that it worked after changing permissions

[JJ Fullmer]

In summary

Not quite working.
I think a simple change to the “changing permissions” part of the upload adding a chown -R fog.root /images
to the chmod -R 777 /images would do the trick. Or maybe just add that right before updating the database or moving the files.

[JJ Fullmer]

Updated to ver 6525 before updating the image again.
This time around it worked flawlessly as it should.