You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@mesos.apache.org by GitBox <gi...@apache.org> on 2020/04/01 15:28:51 UTC

[GitHub] [mesos] cf-natali commented on a change in pull request #355: Handle EBUSY when destroying a cgroup.

cf-natali commented on a change in pull request #355: Handle EBUSY when destroying a cgroup.
URL: https://github.com/apache/mesos/pull/355#discussion_r401705020
 
 

 ##########
 File path: src/linux/cgroups.cpp
 ##########
 @@ -696,13 +696,24 @@ Try<Nothing> remove(const string& hierarchy, const string& cgroup)
   string path = path::join(hierarchy, cgroup);
 
   // Do NOT recursively remove cgroups.
-  Try<Nothing> rmdir = os::rmdir(path, false);
-  if (rmdir.isError()) {
-    return Error(
+  // TODO The retry was added as a fix for kernel bug
+  // https://lkml.org/lkml/2020/1/15/1349
+  // where calling rmdir on a seemingly empty cgroup can fail
+  // with EBUSY while some tasks are exiting.
+  auto delay = Milliseconds(1);
+  for (auto retry = 10; ;) {
+    Try<Nothing> rmdir = os::rmdir(path, false);
+    if (!rmdir.isError()) {
+      return rmdir;
+    } else if (retry > 0) {
+      os::sleep(delay);
 
 Review comment:
   There is at least another code path which calls `cgroup::remove` - when the freezer subsystem isn't available: https://github.com/apache/mesos/blob/f8a3dd334934094ec44e07fa350f958d218bc78f/src/linux/cgroups.cpp#L1596
   
   Also it seems that `cgroup::mount` has a similar hack: https://github.com/apache/mesos/blob/f8a3dd334934094ec44e07fa350f958d218bc78f/src/linux/cgroups.cpp#L575
   
   It returns a future but can block retrying?
   
   So unless you feel strongly about it maybe best to keep it there, since failing to remove a cgroup is pretty much a fatal error?
   
   Also do you have a suggestion for this - I agree we should check for EBUSY, I'm not sure how to do it :).
   
   > > Should we retry only if ::rmdir() returns EBUSY errno error?
   > 
   > Definitely - I wanted to do that but I'm not sure what's the best way to do it: is there a way to access errno from Try<Nothing> rmdir or can I just assume that the global errno is preserved and access it directly?
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services