Problems using Dockerfile

[edmcman]

• Should trex be installed in the Dockerfile? I was not able to compile the runner because trex did not seem to be present.
• After manually cloning trex, I experience the following:

root@f6567f8fa929:/trex-usenix25# cargo run --bin runner -- single-job 'Decompress binary' 'benchmarks/basic-test/evalfiles/test-linked-list-slot1' 
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/runner single-job 'Decompress binary' benchmarks/basic-test/evalfiles/test-linked-list-slot1`
$ timeout --verbose --kill-after=2 1800 /usr/bin/systemd-run --quiet --user --scope --property MemoryMax=64G --property MemorySwapMax=0 unxz --force --keep benchmarks/basic-test/evalfiles/test-linked-list-slot1.binar.xz
Failed to connect to bus: No medium found
Failed because running the job failed. Try again with        cargo run --bin runner -- single-job 'Decompress binary' 'benchmarks/basic-test/evalfiles/test-linked-list-slot1'            ! [00:00:00]   0/1   Decompress binary (failed = 1)                                          Error: Job failed

"Failed to connect to bus: No medium found" seems like a systemd problem. Should this be happening inside a container? I ran into an unrelated error with podman, so I'm using docker. Any help would be appreciated.

[jaybosamiya]

Hi Ed, thanks for trying TRex out.

1. Yes, you need to clone trex too to get it working, we'll update the instructions for the artifact to clarify this. Glad you recognized that the extra clone step is needed.
2. Container setups have weird interactions with the memory limiting technique we're using (the systemd-run thing). We have some code to auto-detect issues and disable the memory limiting with a warning, but it is not fully precise. Fwiw, it is perfectly safe to use --no-mem-limits if you have sufficient memory, and then it will run stuff without the systemd-run ... stuff.

Relevant bit of runner code that explains what happens if you use --no-mem-limits:

trex-usenix25/utils/runner/src/job.rs

Lines 771 to 790 in 008a18c

	let mem_limit_args = if self.no_mem_limit {
	vec![]
	} else {
	// Allow only a fixed amount of memory per process group (if you do it with rlimit, then
	// it is per process, but we want it per process group)
	match &*crate::SYSTEMD_RUN_PATH {
	Some(systemd_run) => cmd!(
	systemd_run,
	"--quiet",
	"--user",
	"--scope",
	"--property",
	"MemoryMax=64G",
	"--property",
	"MemorySwapMax=0",
	)
	.into(),
	None => vec![],
	}
	};

[edmcman]

Thanks, I'll try `--no-mem-limits` as a workaround!

…

On Mon, Jul 28, 2025 at 6:20 PM Jay Bosamiya - ***@***.*** ***@***.***> wrote: *jaybosamiya* left a comment (secure-foundations/trex-usenix25#1) <#1 (comment)> Hi Ed, thanks for trying TRex out. 1. Yes, you need to clone trex too to get it working, we'll update the instructions for the artifact to clarify this. Glad you recognized that the extra clone step is needed. 2. Container setups have weird interactions with the memory limiting technique we're using (the systemd-run thing). We have some code to auto-detect issues and disable the memory limiting with a warning, but it is not fully precise. Fwiw, it is perfectly safe to use --no-mem-limits if you have sufficient memory, and then it will run stuff without the systemd-run ... stuff. Relevant bit of runner code that explains what happens if you use --no-mem-limits: https://github.com/secure-foundations/trex-usenix25/blob/008a18cda9fc96be45b97543a5b1f2c8c474d7df/utils/runner/src/job.rs#L771-L790 — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHYKZKJSIRQLGBVNZVURTD3K2O37AVCNFSM6AAAAACCSD6MNGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMZQGAZDONBXGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>