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
Received on Tue Sep 29 2015 - 12:16:25 UTC