简体中文 | English | Wiki home

This page describes every setting in the judge's configuration file, /opt/LLMOJ/config/judge.yaml (use your own directory if you installed elsewhere), how the number of judge slots is chosen, the sandbox, the systemd service, and how to change the number of slots on an existing installation.

The judge reads the file named by LIBREOJ_JUDGE_CONFIG_FILE and won't start without it. Most settings have no built-in default: the examples below come from config-example.yaml, and the installer may write other values. The example's key and sandbox.rootfsId are placeholders and won't work.

These are set only for a judge on the same server as the site; a remote judge leaves them empty, which turns the AI worker off.

cpuAffinity.compiler, cpuAffinity.userProgram, cpuAffinity.interactor and cpuAffinity.checker list the logical CPUs each kind of program may use (for example [0, 1]). The installer gives all four the CPUs it chose for judging. They don't give each slot its own CPU, and they must lie within the CPUs systemd allows the service. Without them, only systemd's limits apply.

The site sends some limits when the judge connects: limit.compilerMessage, limit.outputSize, limit.dataDisplay, limit.dataDisplayForSubmitAnswer and limit.stderrDisplay. They aren't settings in judge.yaml. Neither are each problem's time and memory limits, which also come from the site.

• LIBREOJ_JUDGE_CONFIG_FILE: the configuration file, <root>/config/judge.yaml.
• LIBREOJ_JUDGE_LOG_LEVEL: info by default. Use verbose or debug only while investigating a problem, and keep those logs private, as they contain signed download addresses.
• UV_THREADPOOL_SIZE: at least twice the number of slots plus two (up to 1024); the installer writes max(4, 2 × slots + 2). Each slot may wait on two programs at once (for interactive problems), and two more threads handle files. Restart the judge after changing it.
• NODE_OPTIONS=--max-old-space-size=512: the judge's own memory, not the limit for submitted programs.
• HYHOJ_AI_SAMPLE_INPUTS_DIR: private directory of AI sample inputs, <root>/data/ai-sample-inputs. It must be the same as the backend's, and must never be served publicly.

• The judge takes up to taskConsumingThreads submissions from the site at a time.
• Compiling, running tests and local AI checks share the slots. A test reserves its program's memory limit plus the interactor's (or the checker's, if larger), a compilation 512 MiB, and anything else 256 MiB; work starts, in order of arrival, when both a slot and its memory are free. Work that needs more than the whole budget runs on its own.
• Local AI checks use at most aiExecutionSlots slots and never hold up judging behind them.
• Downloads have their own queue of maxConcurrentDownloads.
• The AI worker also runs at most three AI pipelines at a time and accepts at most eight requests; these aren't extra slots and can't be configured.

Raising taskConsumingThreads or AI concurrency doesn't add capacity: only slots, with the CPUs and memory behind them, do.

A slot is where one compilation or one test runs at a time. One judge service runs all its slots. The default number of slots, which is also the most allowed, is:

the number of CPUs the judge may use minus one, or its memory in MiB divided by 256, whichever is smaller, and at most 511

The same rule applies to a judge on the site's server and to remote judges. A server with only one CPU, or less than 256 MiB of memory, can't judge.

"The CPUs the judge may use" takes into account CPU affinity, cgroup CPU sets and CPU quotas, not just nproc; "its memory" is the smaller of the server's memory and any cgroup memory.max. The judge's CPUs are taken from the end of the allowed list, which doesn't have to start at 0 or be contiguous.

For example, with eight CPUs (0–7) and 8 GiB of memory, the judge gets CPUs 1–7, seven slots, three submissions at a time, four downloads, working directories 1–7 and 16 threads. With only 512 MiB of memory, it gets two slots on CPUs 6 and 7 and six threads. Because work waits for memory, problems with large memory limits don't need fewer slots unless they're most of what you judge.

Each slot's 512 MiB tmpfs is the most it can hold, not memory set aside. Compilers, programs, the page cache, AI and the database all share the server's memory, and TasksMax, cgroups and CPU quotas still apply. lscpu -e=CPU,CORE,SOCKET,ONLINE shows which logical CPUs share a physical core; slots don't get cores to themselves.

The installer and the resize command use the same calculation, judge_capacity.py.

Every compiler, program, checker and interactor runs in the sandbox:

• as the unprivileged sandbox.user, unable to gain privileges (no_new_privs);
• in its own mount, PID, network, UTS and IPC namespaces, with a read-only file system and only its own task's directories;
• under cgroup v2 limits on memory, processes and CPU time.

A seccomp filter also refuses system calls that judged programs don't need (sandbox.syscallFilter, on by default):

• creating or entering namespaces, mounting and changing the root directory;
• ptrace and reading other processes' memory;
• keyrings, io_uring, bpf, performance events and userfaultfd;
• kernel modules, rebooting, swap, and setting the system time or name.

These calls fail with "operation not permitted", including through the 32-bit system call table (-m32 programs and int 0x80); x32 calls fail too. clone3 reports "not implemented", so that the C library falls back to clone, whose flags the filter can check. If the filter can't be installed, nothing runs.

To check this judge, compiling and running every language through the judge's own code and probing the filter with 64-bit and 32-bit programs:

sudo bash /opt/LLMOJ/deploy/sandbox/self-test.sh

It prints one line per check and takes from a few seconds to a minute. It uses its own temporary directories and never the judge's key, so it can run while the judge is working, though it competes with judging for CPU. --only cpp,java checks only some languages. The upgrader runs it with the new version, before switching over, whenever the judge or the sandbox changes.

What the sandbox can't do. Programs in the sandbox share the server's kernel, so a kernel vulnerability could still let one escape. The filter reduces how much of the kernel they can reach, but doesn't prove isolation, and the judge's control process runs as root. For contests open to the public:

• run judges on their own machines, not on the web server;
• keep the kernel up to date;
• keep the site's credentials (database, MinIO, AI keys) off remote judges, which need only their judge key.

The installer and the resize command write the judge's service with these settings. Check the files they wrote, and any drop-ins that override them.

User and Group aren't set, so the service runs as root; sandbox.user is a different user, inside the sandbox. CPUAccounting, MemoryAccounting, TasksAccounting, MemoryMax, CPUQuota and other limits aren't set and come from systemd's defaults or parent slices. To see the values in effect:

sudo systemctl show libreoj-judge.service -p CPUAccounting -p MemoryAccounting -p TasksAccounting -p LimitCORE -p TasksMax

Each working directory has its own mount unit (named by systemd-escape --path --suffix=mount): a tmpfs with size=512m,mode=0755,nodev,nosuid.

After adding or removing CPUs or memory, change the number of slots with the resize command. Don't rerun the installer with another --judge-slots, edit the installation records, or delete judge.yaml or the key to force a change.

The command works on a judge installed by the installer, with its standard working directories and services. A web-only server has no judge to resize; add a remote judge instead. --mode auto (the default) finds out whether this is a full site or a remote judge; --mode all or --mode remote only checks that it is the one you expect. The command refuses to change a service with its own MemoryMax or CPUQuota, drop-ins that affect it, or a service from another installation directory: review those by hand first.

resize-judge.sh prints English and resize-judge.zh-CN.sh Chinese; otherwise they're the same.

sudo bash /opt/LLMOJ/deploy/resize-judge.sh --prefix /opt/LLMOJ --plan
# with a number of your choice, which must fit the CPUs and memory:
sudo bash /opt/LLMOJ/deploy/resize-judge.sh --prefix /opt/LLMOJ --slots 6 --plan

--plan changes nothing. It shows the old and new slots, CPUs, memory and threads.

Choose a quiet time. Stop new submissions, rejudges, test runs and AI jobs, and wait until everyone's queued and running work has finished. If other judges can take over the queue, Drain this judge on the Judge Machine page instead and wait until it shows Drained; local AI jobs must still finish, because draining doesn't cover them. Idle CPUs, or an empty list of your own AI jobs, don't prove that nothing is running. --drained is your confirmation that you've done this; the command doesn't drain anything itself.

Run without options, the command shows the capacity and the draining requirement and asks for the number of slots. Entering a number (or pressing Enter for the default) confirms that the judge is drained and applies the change immediately, without asking again. Press Ctrl+C if work is still running.

sudo bash /opt/LLMOJ/deploy/resize-judge.sh --prefix /opt/LLMOJ

Or, without questions:

sudo bash /opt/LLMOJ/deploy/resize-judge.sh --prefix /opt/LLMOJ --slots 6 --apply --drained

The command:

1. backs up judge.yaml, the judge's services and their state to <prefix>/backups/judge-resize/<UTC time>/ and prints that directory;
2. stops only the judge;
3. updates the slots, working directories, CPUs, concurrency, threads, mounts and services, keeping the key, the site address, the sandbox image and the AI settings;
4. checks the services and runs a real sandbox test;
5. starts the judge again if it was running before (and checks its CPUs and threads); a judge that was stopped stays stopped.

If a check fails, it restores the backup. If even that fails, the judge stays stopped and the command tells you where the backup is. Keep the backup private: it contains the judge's key.

Check that the service is running and the judge is online on the site, then submit ordinary and interactive problems in the languages you use, and run a small AI job if you use local AI.

sudo systemctl is-active libreoj-judge.service
sudo systemctl show libreoj-judge.service -p AllowedCPUs -p EffectiveCPUs -p TasksMax

To undo the change, stop new work and drain again, then give the backup directory the command printed:

sudo bash /opt/LLMOJ/deploy/resize-judge.sh --prefix /opt/LLMOJ --rollback /path/to/backup --drained

This restores the judge's configuration, services and their previous state. It doesn't touch problems or the database, and doesn't undo submissions judged in the meantime. Check the judge again afterwards.

See also: Remote judges · Distributed judging. Sources: config.ts, configure-judge.py, executionCapacity.ts, taskQueue.ts, aiRunner.ts.