New tool: froglimit - Githubissues

c-cube / frog-utils

[frozen] Scheduling and running jobs on a shared computer, then analyse their output

BSD 2-Clause "Simplified" License

5 stars 0 forks source link

New tool: froglimit #27

Open Gbury opened 9 years ago

Gbury commented 9 years ago

It could be nice to have a new tool for imposing limits to a program. Using ulimit as is done currently is fine, but it has a few flaws:

it is a console tool, so not as stable as using a system call would be
it seems to limit the process and each children separately, rather than limit the sum of resources

Additionally, froglimit could behave in a way similar to that used in the CASC competition (e.g sending SIGALRM and/or SIGXCPU when a process timeouts), which could be nice.

c-cube commented 9 years ago

+1 for this feature, this is often needed.

Gbury commented 8 years ago

This is actually pretty much the same as issue #29 . My current plan would be to use "obus" to access the systemd API, and use that internally to limit processes launched in frogutils. From what i remember, we could avoid a hard dependency on obus, as its main use is to generate files to allow direct access to dbus APIs.

c-cube commented 7 years ago

obus is a mess, imho. Even cgroups would be simpler…

Gbury commented 7 years ago

The problem is that at medium term, the cgroups API will move from the filesystem to systemd. Obus is one way to interact with systemd without too much headache. If you have another suggestion, I'm all ears.

c-cube commented 7 years ago

Your ctypes bindings are not future-proof?

Gbury commented 7 years ago

I don't use ctypes bindings, :p Originally, the only way to access the cgroups API was through the filesystem (the C libraries out there also have to go through the filesystem), and so it is what I implemented in my ocaml package (there really was not much benefit to go through a C library). However, it raises some problems concerning permissions, so there is now a systemd API, which should become the only one in the future (possibly removing the filesystem API at one time).