Monthly Archives: July 2015

Which nginx location stanza is being evaluated?

One thing I’ve had to get used to working with nginx, is that it can be hard to understand which configuration stanza (which part / section of the nginx virtualhost configuration file) is being evaluated, especially given an existing site with a complex history.

Useful trick here is to add a custom header for each of the sections, like so:

server {
add_header X-My-Debug-Header-01 srv;
listen 80 default_server;

location ~ test\.php$ {
add_header X-My-Debug-Header-02 loc-test-php;
try_files $uri =404;
fastcgi_pass unix:/var/run/php5-fpm.sock;
include fastcgi_params;
}

location /pictures {
add_header X-My-Debug-Header-03 loc-pictures;
alias /usr/share/nginx/html;
index index.php index.html index.htm;
}

}

Now, for each section match, there will be a convenient header which can be viewed with e.g. wget --server-response (wget -S) or curl --head (curl -I).

Caveats: the Firefox LiveHTTPHeaders plugin doesn’t seem to show non standard headers. Also, when nginx serves a 40x or 50x, the custom header tends not to get served.

WordPress uploads silently fail while it pretends pictures are there

Silly wordpress issue – trying to upload an image, everything seems to go smoothly accept that the uploaded image isn’t there, the links to the images are broken. Permissions for the upload dir look fine too. Chances are, somewhere apache is logging a line like

PHP Warning: POST Content-Length of 15148998 bytes exceeds the limit of 8388608 bytes in Unknown on line 0, referer: https://your_site.com/your_uri/wp-admin/themes.php?page=custom-background

So what is needed is a higher upload limit. In /etc/php5/apache2/php.ini (or corresponding file in your distro, if you use Apache), change post_max_size and upload_max_filesize to something appropriate.

An additional issue I had is where my blog is not on the root of its vhost/domain. So check in what filesystem directory the uploaded files end up, and whether the uploads link points at the right place on your filesystem. The wordpress config files should have the upload directory specified in e.g., on Ubuntu/Debian, /etc/wordpress/config-your_site.com.php.

TRIM on Linux not supported for modern Samsung SATA drives?

Previous title: Discard/TRIM not getting through KVM/LVM/MD/SATA/SSD stack

I thought my TRIMs were being blocked by the virtualization/LVM stack, but it turns out the bare device won’t be TRIMmed either.

# fstrim /mnt/sde/
fstrim: /mnt/sde/: FITRIM ioctl failed: Operation not supported

According to this Algolia blog article there has been an kernel bug affecting these drives (mine is a Samsung 850 PRO 1TB), so I guess it has been blacklisted for the time being.