Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Media upload not working #4159

Closed
AlexKalopsia opened this issue Jan 10, 2022 · 16 comments
Closed

Media upload not working #4159

AlexKalopsia opened this issue Jan 10, 2022 · 16 comments

Comments

@AlexKalopsia
Copy link
Contributor

Running webtrees 2.0.19 on docker, behind reverse proxy.

Whenever I try and add a media file, nothing really happens. I select the file, give it a title and media type, i click Save but nothing happens, the popup dialog stays open.

docker logs only shows

webtrees:80 172.19.0.1 - - [10/Jan/2022:13:29:21 +0000] "GET /tree/family/create-media-object HTTP/1.1" 200 2569 "https://webtrees.mydomain.com/tree/family/add-fact/X331/OBJE" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0"
webtrees:80 127.0.0.1 - - [10/Jan/2022:13:29:23 +0000] "GET / HTTP/1.1" 302 669 "-" "curl/7.74.0"

If I check the network tab of Firefox, I do see the POST request, but it shows 117 bytes for an image that is actually 500 Kb.

Uploading media used to work, but I believe it broke now that I made webtrees reachable through an external url.

Nginx config:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name webtrees.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app xxx.xxx.xxx.xxx;
        set $upstream_port xxx;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

}

Any idea what could be the cause of this?

@fisharebest
Copy link
Owner

If I check the network tab of Firefox, I do see the POST request

What is the response from this POST request?

I'm guessing a 500. After a sucess response, the page would reload - showing the new image.

@AlexKalopsia
Copy link
Contributor Author

Yes, I do get 500.

More findings on uploading the original image as well as smaller versions:

  • 554Kb - 1030x1600 - FAIL
  • 404Kb - 824x1280 - FAIL
  • 165Kb - 515x800 - FAIL
  • 99Kb - 412x640 - SUCCESS

I initially thought it could be the super high resolution, but yeah, it turns out I need to make the image a lot smaller for it to succeed.

Notice that in the upload popup it says Maximum upload size: 51,200 KB

@fisharebest
Copy link
Owner

fisharebest commented Jan 10, 2022

Almost certainly the memory (or some other) limit of your server

See also https://webtrees.net/faq/thumbnails/

@AlexKalopsia
Copy link
Contributor Author

AlexKalopsia commented Jan 11, 2022

My memory_limit is set to 1024M which should be more than enough, so I don't think that's necessarily the issue.

Image Magick shows that it supports JPG, JPEG and PNG

For what concerns the processor, my NAS has a quad-core Intel Celeron J3455. Even in this case, I doubt this is causing the issue?

More details on the HTTP response:

undefined undefined undefined
server: nginx/1.20.2
date: Tue, 11 Jan 2022 08:54:09 GMT
content-type: text/html
content-length: 177
X-Firefox-Spdy: h2

request:

POST /tree/family/create-media-object undefined
Host: webtrees.mydomain.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://webtrees.mydomain.com/tree/family/add-fact/X331/OBJE
X-CSRF-TOKEN: BYLtxO7Llw3VBbEAaAwmoMkk7usvHjWt
X-Requested-With: XMLHttpRequest
Content-Type: multipart/form-data; boundary=---------------------------211958205730299905772163485560
Content-Length: 415833
Origin: https://webtrees.mydomain.com
Connection: keep-alive
Cookie: __Secure-WT-ID=018d1a053459ec2f95f334f0a2b5bf7d
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
TE: trailers

@fisharebest
Copy link
Owner

If it works for small images, but not large ones, it hints at a resource limit of some sort.

What are the details of the 500 response. It would generally contain an error message.

If you don't know how to use the developer tools in your browser, there are instructions here:
https://webtrees.net/faq/xhr/

@AlexKalopsia
Copy link
Contributor Author

The response is, sadly, just a generic 500 error in html code

<html>
<head><title>500 Internal Server Error</title></head>
<body>
<center><h1>500 Internal Server Error</h1></center>
<hr><center>nginx/1.20.2</center>
</body>
</html>
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->

@AlexKalopsia
Copy link
Contributor Author

For some extra info, I bashed into the docker container and did both php -i | grep -i "post_max_size" and php -i | grep -i "upload_max_filesize", and they both return 50MB

I also ran these commands from outside the containers, and they both return 32MB

In both cases this doesn't seem to be the issue, but I agree with you that if some sizes work it must be a server-side problem

@fisharebest
Copy link
Owner

If this was a catchable error (code or logic error), then webtrees would have generated a formatted 500 response.

Since it didn't - and we have a generic response from the webserver - then it also suggests a resource (cpu/memory/etc.) limit was reached, and the PHP process was terminated forcibly.

@AlexKalopsia
Copy link
Contributor Author

AlexKalopsia commented Jan 11, 2022

But how can this happen on a 165Kb - 515x800 image? That's what I find the most confusing to be honest :S Can you think of any other way I can debug this further?

Additionally, is there a way to trigger the thumbnail generation that doesn't go through a POST request? (ie manually uploading in a folder?)

Really appreciate the help so far!

@fisharebest
Copy link
Owner

Thumbnails are generated when a page tries to view them - not when you upload an image.

The upload simply saves the file in the media/ folder and creates a GEDCOM record in a database table.

@fisharebest
Copy link
Owner

But how can this happen on a 165Kb - 515x800 image?

Maybe your disk has less than 165kb free?
Maybe the filename contains characters that are incompatible with your filesystem.
Maybe the file triggers anti-virus software on your server.

Could be so many things. Difficult to guess.

@AlexKalopsia
Copy link
Contributor Author

To answer the question, I have Terabytes of available space and it fails even if I rename the file abcd.jpg 🤷‍♂️It also fails with other images, so yeah...I dunno :(

@AlexKalopsia
Copy link
Contributor Author

AlexKalopsia commented Feb 13, 2022

Still having this issue and not sure why this has been marked as closed? I haven't done any progress, but feels like maybe someone else might bump onto the same issue?

The issue seems to be caused bu the file resolution. I can shrink images and they eventually manage to upload, but I don't see any setting/warning related to this :S

@fisharebest
Copy link
Owner

not sure why this has been marked as closed?

Because I am pretty certain this is a server limitation, not a code issue.

Did you check the policy.xml file for the ImageMagick library?
On some OS/builds, it limits the amount of disk/cpu/ram that it will use...

@AlexKalopsia
Copy link
Contributor Author

Even if it's a server issue it makes sense to explore what could be the cause, I think.
As I said above, I find it extremely unlikely that this problem is related to resource limitation. I am literally processing a 165Kb 515x800 image!

I have terabytes of free space, 32Gb of ram, CPU is almost entirely available.

I guess I will ask on the webtrees-docker repo and see if they can provide some extra help, thank you.

@fisharebest
Copy link
Owner

fisharebest commented Feb 14, 2022

As I said in my last post, you might have TB of RAM, but if your imagick policy says to use only 128MB, then it won't be used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants