When graceful shutdown was requested, and then nginx was forced to do fast shutdown, it used to (incorrectly) complain about open sockets left in connections which weren't yet closed when fast shutdown was requested. Fix is to avoid complaining about open sockets when fast shutdown was requested after graceful one. Abnormal termination, if requested with the WINCH signal, can still happen though.
Binary upgrades are not supported without master process, but it is, however, possible, that nginx running with master process is asked to upgrade binary, and the configuration file as available on disk at this time includes "master_process off;". If this happens, listening sockets inherited from the previous binary will have ls[i].previous set. But the old cycle on initial process startup, including startup after binary upgrade, is destroyed by ngx_init_cycle() once configuration parsing is complete. As a result, an attempt to dereference ls[i].previous in ngx_event_process_init() accesses already freed memory. Fix is to avoid looking into ls[i].previous if the old cycle is already freed. With this change it is also no longer needed to clear ls[i].previous in worker processes, so the relevant code was removed.
Previously, if an event was posted by a read event handler, called by ngx_close_idle_connections(), that event was not processed until the next event loop iteration, which could happen after a timeout.
Due to structure's alignment, some uninitialized memory contents may have been passed between processes. Zeroing was removed in 0215ec9aaa8a. Reported by Johnny Wang.
Listening UNIX sockets were not removed on graceful shutdown, preventing the next runs. The fix is to replace the custom socket closing code in ngx_master_process_cycle() by the ngx_close_listening_sockets() call.
Previously, capset(2) was called with the 64-bit capabilities version _LINUX_CAPABILITY_VERSION_3. With this version Linux kernel expected two copies of struct __user_cap_data_struct, while only one was submitted. As a result, random stack memory was accessed and random capabilities were requested by the worker. This sometimes caused capset() errors. Now the 32-bit version _LINUX_CAPABILITY_VERSION_1 is used instead. This is OK since CAP_NET_RAW is a 32-bit capability (CAP_NET_RAW = 13).
Previously included file sys/capability.h mentioned in capset(2) man page, belongs to the libcap-dev package, which may not be installed on some Linux systems when compiling nginx. This prevented the capabilities feature from being detected and compiled on that systems. Now linux/capability.h system header is included instead. Since capset() declaration is located in sys/capability.h, now capset() syscall is defined explicitly in code using the SYS_capset constant, similarly to other Linux-specific features in nginx.
The capability is retained automatically in unprivileged worker processes after changing UID if transparent proxying is enabled at least once in nginx configuration. The feature is only available in Linux.
On some systems, it's possible that reaper of orphaned processes is set to something other than "init" process. On such systems, the changing binary procedure did not work. The fix is to check if PPID has changed, instead of assuming it's always 1 for orphaned processes.