Error when missing cgroup value memory.peak #2780
Conversation
|
But it did 'work' without this thing, it just reported it as 0? I think it's better to document that than to not allow cgroupv2 at all (which is basically what this PR does) on older kernels (like the one in Ubuntu 22.04). Or did it fully break for you? |
Yes, it was working because we allowed it to. But we didn't allow it in the cgroup v1 implementation either, so there you were guaranteed to always get real memory usage value. I think silently reporting zero when the kernel does not support it, creates a confusing situation (which happened to us at the BAPC). So better to explicitly bail out and let the user switch to cgroup v1. You're on an older kernel anyways. |
|
If others think the same I think we need to re update the docs to tell them how to switch to v1. I think we removed that now |
|
If we do this (I don't feel strongly), then we should change the script that I touched in 8f8f4c0 from warning to error to get this error before you start judging. |
|
Is this only a problem for people upgrading DOMjudge on their current OS or also for people installing a new server (Debian stable, current Ubuntu LTS)? If we also do this for new installations on newer/current versions seems a bit hard for informational level of info (assuming that runguard still does its job and still terminates submissions taking too much memory) I'm not sure if the IMO minor decrease in memory is worth the discussion people need to have to have cgroupV1 enabled again with their sysadmin so I would at least give an override flag for this behaviour or an explicit question when the judgedaemon boots? |
|
Ubuntu 22.04 at least doesn't support it. It's not the latest LTS, but I think it's still widely used, especially since there is no ICPC 24.04 image yet (although it is coming). |
In that case I think terminating like @eldering suggests is the better option but also adding an override flag for when you accept this (minor) decrease in performance if its only informational. @eldering did the submissions with |
eldering
force-pushed
the
error-missing-memory.peak
branch
from
8cf1538 to
b3a8dda
Compare
doc/manual/install-judgehost.rst
Outdated
| ``GRUB_CMDLINE_LINUX_DEFAULT="quiet cgroup_enable=memory swapaccount=1 isolcpus=2"`` | ||
|
|
||
| On modern systems where cgroup v2 is available, DOMjudge will try to | ||
| use that. This requires kernel versions 5.20 or 6.0 or later to |
There was a problem hiding this comment.
| use that. This requires kernel versions 5.20 or 6.0 or later to | |
| use that. This requires kernel versions 5.19 or 6.0 or later to |
judge/create_cgroups.in
Outdated
| minor=$(echo "$kernel_version" | cut -d '.' -f 2) | ||
| if [ "$major" -lt 5 ] || { [ "$major" -eq 5 ] && [ "$minor" -lt 19 ]; }; then | ||
| echo "WARNING: Kernel ($kernel_version) is too old to record peak RAM usage" >&2 | ||
| echo "Kernel ($kernel_version) is too old to record peak RAM usage with cgroup V2, trying cgroup V1" >&2 |
There was a problem hiding this comment.
Why are you not failing here with the cgroup_error_and_usage?
eldering
force-pushed
the
error-missing-memory.peak
branch
from
b3a8dda to
266cf7e
Compare
This replaces the `memory.memsw.max_usage_in_bytes` value from cgroup v1. We always assume it's there so we should fail if it is not. Otherwise things silently degrade in a way they would not have before. Also document this in the create_cgroups script and manual. Addresses #2763
eldering
force-pushed
the
error-missing-memory.peak
branch
from
266cf7e to
1224ad3
Compare
4 participants
This replaces the
memory.memsw.max_usage_in_bytesvalue from cgroup v1. We always assume it's there so we should fail if it is not. Otherwise things silently degrade in a way they would not have before.Addresses #2763