grindcore.ch

Beni Grind

Mon, 04 Feb 2019 19:57:57 +0100 zuletzt bearbeitet: Mon, 04 Feb 2019 20:00:08 +0100

!Hubzilla Support Forum I'm again unable to upload images. Last time it was a size restriction on PHP. This time it started with the latest Hubzilla update, not a reconfiguration of PHP and I'm unable to add any file. It doesn't even turn up in the post body.

According to my webserver log both POST requests to /wall-attach/navigium and /item result in a 200 status. The request to /item has a size of 0B.

Any hint where I should start debugging this?

EDIT: I just checked the file storage. Apparently the files are uploaded successfully but are not inserted into the post I try to attach the image to.

mehr anzeigen 20 Kommentare

Giacomino

Mon, 04 Feb 2019 20:14:11 +0100

just a test

Sophie

Mon, 04 Feb 2019 20:24:44 +0100

[OT]
We want Alps, we want Alps!
[/OT]

Beni Grind

Mon, 04 Feb 2019 20:26:39 +0100

I figured that this is again a problem specific to my hub. I tried multiple browsers. It happens everywhere, so it has to be some misconfiguration of my hub.

Beni Grind

Mon, 04 Feb 2019 20:27:12 +0100

@Sophie

- I'll fix this soon... hopefully.

Giacomino

Mon, 04 Feb 2019 20:45:44 +0100

@skiing point this works ?

Sophie

Mon, 04 Feb 2019 20:50:09 +0100

Mario Vavti

Tue, 05 Feb 2019 12:43:39 +0100

@Beni Grind there were no changes in 3.8.9 that could affect image uploads from the editor in any way...

Beni Grind

Tue, 05 Feb 2019 12:59:49 +0100

@Mario Vavti I was dumb enough to upgrade the packages on the server at the same time - now I can't tell what lead to the problem :/ It's somehow weird:

The picture gets uploaded successfully
The picture is set as "only visible to me"
If I try to set the permissions manually to "public" and select the image from the album it still doesn't show up in the selection.

So I guess I somehow messed up the permission system, not the upload. Interestingly I uploaded a picture on the 27th January and it still worked back then. Except for the package upgrade and the upgrade of Hubzilla I didn't touch the server in the mean time.

Mario Vavti

Tue, 05 Feb 2019 13:04:17 +0100

There were also no chnges to the permission system.

Anyway, can you provide a path to reproduce? As you probably know already there are several possibilities to post/upload an image, so i might be just missing something because your workflow might be different to mine...

Beni Grind

Tue, 05 Feb 2019 13:25:17 +0100

@Mario Vavti I don't think you're missing anything. I just use the paper clip button under the post form. I use the setting where the pictures are uploaded to folders named after the month (02-2019 and so on). When I try to upload a file using the paper clip button, the file ends up in this folder with the "only me" permission set. The usual image tag in the edit field doesn't appear.

How can I provide a path to reproduce? I don't think it's reproducible on another instance.

Mario Vavti

Tue, 05 Feb 2019 13:28:11 +0100

Ok. In this case you should see a javascript error in the console. Permissions are correct (only you). We set the final permission for the image at the point you send the post since only then is clear who should be allowed to see the image...

Beni Grind

Tue, 05 Feb 2019 14:18:32 +0100

@Mario Vavti I checked the console and didn't see any errors. All I see is this:


LOADING data...
main.js:935:2
DATA ready in: 0.414 seconds.
main.js:968:3
LOADING images...
main.js:971:4
IMAGES ready in: 0.014 seconds.
main.js:975:5
collapseHeight() - contentHeightDiff: 0px

Is there a way to enable some kind of debugging messages on the client? What request should I see after the POST to /item to upload the image? There don't seem to be any followup requests.

Mario Vavti

Tue, 05 Feb 2019 14:55:31 +0100

Since the image text is (should be) added to the editor after the fileupload succeeds via javascript i was expecting an error...

Basically the return value of the POST to wall_attach should be the bbcode text to be inserted into the editor. The POST to /item should return the preview html in a json payload.

Beni Grind

Tue, 05 Feb 2019 15:02:56 +0100

Then there is something wron with the POST to wall_attach. The response payload is


{"message":"\n\n\n\n"}

And the response payload of the POST to /item is empty (0B).

Mario Vavti

Tue, 05 Feb 2019 15:13:24 +0100

Sigh... Are you using imagemagick or gd backend?

Mario Vavti

Tue, 05 Feb 2019 16:00:24 +0100

Have you seen any errors in the php log?

Beni Grind

Tue, 05 Feb 2019 18:40:55 +0100

@Mario Vavti Great, I keep forgetting that there is also a php log and keep checking the webserver and hubzilla logs over and over... The problem was:

WARNING: [pool www] server reached pm.max_children setting (10), consider raising it

What value makes sense here that I don't run into problems again?

Giacomino

Tue, 05 Feb 2019 19:14:26 +0100

maybe this page #^https://myshell.co.uk/blog/2012/07/adjusting-child-processes-for-php-fpm-nginx/
can help ( I hope)

Steffen K9 🐙

Tue, 05 Feb 2019 19:34:50 +0100

pm.max_children setting (10)
This is a very low setting. Only 10 PHP-FPM processes are allowed at the same time. You should raise the value. As a rule of thumb you can set it to 10 per CPU core (6 cores = max_children 60) and watch the load of the machine. Also, each PHP-FPM process needs approx. 50MB of RAM. If you have not enough RAM reduce the value to something that fits. And it shouldn't be set to a higher value than the max database connections (see database config). Otherwise you could run into trouble because PHP cannot open database additional connections.

Example: max database connections = 90; php-fpm max_children = 60 (that leaves some space for other db connections e.g. from PHP CLI (started by cron) and so on.)
This setting works pretty well on my machine with 12GB RAM.

Beni Grind

Tue, 05 Feb 2019 22:35:33 +0100

Thank you @Steffen K9 🐰, I'll look into this. I don't even remember what processor I have from the top of my head. 16 gig of ram for sure.