Use supervisor to run fastcgi behind nginx.

Previously I wrote how to get the WlzIIPSrv large image server running on webfaction, using lighttpd.

Fast-forward 2.5 years, and I was busy porting the whole site (again), this time from webfaction (acquired by godaddy, who are planning to kill the great webfaction product), along with all of my other websites (including this one that you’re reading), to a fast, self-managed Hetzner VPS in Nuremberg.

I needed to get that exact same WlzIIPSrv large image slice server fastcgi running, but this time behind nginx and preferably without lighttpd.

I could not find the solution quickly, so I thought I’d write up what I came up with.

In short: Unlike apache and lighttpd, nginx does not manage your fastcgi processes, so you need something that can manage and expose them to nginx via socket, much like what php-fpm does for the php world.

It turns out supervisor has explicit support for fastcgi, and it is exactly what I used in this case to get the slice server running again.

Just to jog your memory as to what it is we’re trying to achieve, below is a screenshot of slice 25 of human orbit S2897L, zoomed in to maximum magnification:

As you pan and zoom around that image, five WlzIIPSrv processes are serving up the requested image tiles.

Configure supervisor.

On Ubuntu, install with apt install supervisor.

Now create a file /etc/supervisor/conf.d/visorb_wlziipsrv.conf that looks something like the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

[fcgi-program:visorb_wlziipsrv]
command=/a/dir/owned/by/www-data/wlziipsrv.fcgi
socket=unix:///a/dir/owned/by/www-data/%(program_name)s.sock
socket_owner=www-data
socket_mode=0700
process_name=%(program_name)s_%(process_num)02d
numprocs=5
directory=/tmp
umask=022
priority=999
autostart=true
autorestart=unexpected
startsecs=1
startretries=3
exitcodes=0
stopsignal=QUIT
stopasgroup=false
killasgroup=false
stopwaitsecs=10
user=www-data
redirect_stderr=true
stdout_logfile=/a/dir/owned/by/www-data/visorb_wlziipsrv.stdout.log
stdout_logfile_maxbytes=1MB
stdout_logfile_backups=10
stdout_events_enabled=false
stderr_logfile=/a/dir/owned/by/www-data/visorb_wlziipsrv.stderr.log
stderr_logfile_maxbytes=1MB
stderr_logfile_backups=10
stderr_events_enabled=false
environment=LOGFILE="/a/dir/owned/by/www-data/visorb_wlziipsrv.log",VERBOSITY="5",MAX_IMAGE_CACHE_SIZE="10"
serverurl=AUTO

… and then restart supervisor with systemctl restart supervisor.

Configure nginx.

Below I show the two main location blocks in the relevant nginx server { block for context, but the third location block is the most important.

I used the same path where the frontend scripts had been configured to find wlziipsrv.fcgi.

Other than that, the most important bit is that the unix socket location should match what was configured in supervisor. nginx will pass through request information via this socket, and supervisor will hand that information over to the five wlziipsrv processes that it’s managing.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# see https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/
location / {
  # First attempt to serve request as file, then
  # as directory, finally PHP!! for wordpress
  #try_files $uri $uri/ =404;
  try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
  include snippets/fastcgi-php.conf;
  fastcgi_pass unix:/var/run/php/php-fpm.sock;
}

location /cgi-bin/wlziipsrv.fcgi {
  include /etc/nginx/fastcgi_params;
  fastcgi_pass unix:/a/dir/owned/by/www-data/visorb_wlziipsrv.sock;
}

Activate the new configuration as per usual, by first running nginx -t to check the config, and then systemctl reload nginx to get nginx to load it.