IIUC The wrapper that populates the processes file and the sync executed by the related systemd service on the host are supposed to share a file lock to prevent races on the processes file. This is because the wrapper adds to the file and sync truncates the file after it runs. However, the lock used in the wrapper is under /var/lock in the container which is not shared with the host so the sync script never waits for the wrapper to be done. Moving the lock file to a path on a shared mount in the container seems to solve that particular race.
... in addition ...
it appears that the triggering of the systemd process that runs the sync command is also racy. It appears that if the processes file has entry added after the shared lock is released, but the sync process isn't completed, sync doesnt happen again.
This was reproduced by restarting the neutron dhcp agent container when 3 subnets were configured. The first problem resulted in only one sidecar being created, the second issue would occasionally result in one or more side car containers being missed in the sync. The processes file would have remaining entries and restarting the dhcp_dnsmasq service on the host would cause the remaining side cars to get created.
> It appears that if the processes file has entry added after the shared lock is released, but the sync process isn't completed, sync doesnt happen again.
that particular part of the issue really sounds like a race in systemd watchers?..