On 29/09/2015 00:15, Olivier Brunel wrote:
[2] https://github.com/jjk-jacky/anopa/blob/master/src/utils/aa-setready.c
Yeah, the problem is, aa-setready is prone to the same race condition as s6-notifywhenup was, which is the reason why I scrapped s6-notifywhenup and made a fd to report to s6-supervise instead. If the service dies while aa-setready does its thing, s6-supervise will modify the status file and send a fifodir event to report service death, and depending on the scheduler's whim, the status file may get incorrect information, and the fifodir events may be sent in the wrong order. I hated it when I realized it, but the only way to prevent that is to make the supervisor the only authority on the service state - only the supervisor should modify the status file and send fifodir events. So, from the service's point of view, only the notification-fd is a safe channel to use. -- Laurent
