So until redesign of the dumping/restore procedure for fsnotify system we have to ignore nonempty notify queues
So until redesign of the dumping/restore procedure for fsnotify system we have to ignore nonempty notify queues
on dump and live with the fact that we're generating own events on restore.
on dump and live with the fact that we're generating own events on restore.
+
+
== Chopping the knot ==
+
+
Here are possible ways to resolve the situation
+
+
* when dumping files gather fsnotify and ghost file descriptors into separate lists and dump them at the very late stage; then read out notify events from fsnotify descriptors
+
* when restoring files collect fsnotify descriptors into a root criu task deferring theis restore until all other files (from every child process) are restored; then restore notifies and read out all generated events
+
+
both ways require significant rework of CRIU design so for a while we simply print out a warning if fsnotify queue is not empty and continue processing.