The NGINX config reloader can now handle re-symlinked /data/web/nginx directories on Hypernode. Previously when the NGINX directory was a symlink and the symlink was replaced the new link target would not be watched. In the new version any re-created or re-symlinked NGINX directory will be watched instead of the original symlink target from when the daemon started and first resolved the symlink.
Problems with symlink based deployments
We have been getting reports from people running into problems when trying to do Capistrano or Deployer type symlink based deployments when the app user NGINX directory was included in the release directory. The problem was that because the NGINX config reloader uses filesystem events to monitor changes using the inotify API, only changes from within the NGINX directory would be detected and trigger the config validator to reload.
But because for the deployment process of some shops the NGINX directory is included the release directory because the rules are coupled to the revision of the shop, some people for example re-symlink the /data/web/nginx directory to /data/web/release-1234/nginx every time they deploy. Doing these types of deployments can have many advantages like getting near atomic updates and it is common practice to re-symlink the webroot (/data/web/public) in this fashion as well.
The solution
So in order to facilitate this the NGINX config reloader has been modified to take this scenario into account. When a symlink to /data/web/nginx is replaced or the complete directory is removed and recreated the config reloader will now stop watching the original directory, reload and reacquire a filesystem notifier within five seconds to track and act on changes in the new target.
This change will be gradually rolled out over the course of the next seven days on all Hypernodes.