mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [mesos] cf-natali commented on a change in pull request #355: Handle EBUSY when destroying a cgroup.
Date Wed, 01 Apr 2020 15:28:51 GMT
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

Mime
View raw message