Issue: Image file upload fails

Have been able to track it down to this error that occurs instantly, looking into what time limits is getting exceed.

[17-Oct-2020 12:17:46] WARNING: [pool www] child 3778642 said into stderr: "php-fpm7.4: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1868."

If you checked the path and permissions are okay, then I would still encourage you to check the disk usage at that path. Based on the triggers for that error, I see the following possibilities:
- Target path does not exist (but if you uploaded a different file type, then it probably does)
- Target path is not writable (file permissions)
- Target path's disk is full or does not have enough space left to write the file (this is possible, especially if you have partitioned the hard drive, and have not placed the wiki attachment directory in a large data partition).
- Target path uses a stream wrapper instead of an absolute path (doesn't appear to be the case here)
- Unable to get an exclusive file system lock on the target path
- The source upload file disappeared from disk before it could be written to the target path (don't think I've ever seen this happen, but possibly it's related to a problem in the Imagick implementation, see below)

As for the 502 and underlying errors:

In VaultWiki we have hardcoded a time limit of 5 seconds for processing a user upload via Imagick, in order to protect you when a botnet tries to upload 100 files at once and possibly freeze your server. This limit was added because Imagick is designed in such a way that it is vulnerable to image bombs (small image files that can inflate to millions times memory and/or time usage) and other security holes.

When added to the 1 second connection limit and the 3 second transfer limit, this results in 8-10 seconds of time allotment per image uploaded.

You can work around this issue by reducing the dimensions of the image you are uploading before you upload it.

OR

While we do include support for Imagick, it is only because of vBulletin's native support. We STRONGLY recommend disabling vBulletin's Imagick support on your site, as well as disabling permission for user uploads of avatars, as well as some other user image types that might let users upload images from a remote server. Also disable vBulletin's options to automatically resize uploaded images that are too large.

As we reported to vBulletin developers in late 2017, which led to them ending support for vBulletin 4 that quarter, their implementation of Imagick and some of these other image features even without Imagick contains security holes, most notably against image bombs and slow-loris type attacks, and should not be used in public without major changes. We successfully performed such attacks against our own test sites so we knew they were viable.

This is fixed in the next release.

Basically if the final directory where the uploaded image was going to be moved did not exist yet, this error would be thrown when trying to move it.

This was not unique to Imagick configurations. It was occurring rarely in our tests because our tests contain test data (including test directories), and this error would only occur if it came up with a test directory that did not exist yet. If you upgraded from 4.0.x, then you possibly had some directories already.

There were some related quirks:
- Immediately after uploading an image, if the image gets moved, the thumbnails fail to generate and the image gets changed to a regular file.
- Immediately after uploading an image, the thumbnails that do get created are instantly deleted.
These are also fixed in the next release.