Detached process just stall

[watermelon0guy]

When using mcvcli start -d, the server doesn't start. There's no memory usage and no CPU usage. I'll dig into the code myself a little bit.

You can see how I detach from the process and attach back.

2025-11-02.20-48-31.mp4

[0x7d8]

what minecraft server software are you using?

[watermelon0guy]

NeoForge 1.21.1 21.1.213

{
  "jarFile": "server.jar",
  "stopCommand": "stop",
  "profileName": "default",
  "modpackSlug": null,
  "modpackVersion": null,
  "ramMB": 8192,
  "javaVersion": 21,
  "extraFlags": [
    "-XX:+UseZGC",
    "-XX:+ZGenerational",
    "-XX:ActiveProcessorCount=5"
  ],
  "extraArgs": [],
  "pid": null,
  "identifier": null
}

It works with simple run script and tmux.

[watermelon0guy]

mcvcli/src/commands/start.rs

Lines 291 to 306 in e68ab9c

	let [stdin, stdout, stderr] = detached::get_pipes(config.identifier.as_ref().unwrap());
	#[allow(clippy::zombie_processes)]
	let child = std::process::Command::new(binary)
	.args(&config.extra_flags)
	.arg(format!("-Xmx{}M", config.ram_mb))
	.arg("-jar")
	.arg(&config.jar_file)
	.arg("nogui")
	.args(&config.extra_args)
	.env("JAVA_HOME", java_home)
	.stdin(File::open(stdin.path()).unwrap())
	.stdout(File::create(stdout.path()).unwrap())
	.stderr(File::create(stderr.path()).unwrap())
	.spawn()
	.unwrap();

I think the pipes variables go out of scope and close their descriptors. Because of this, the logs have nowhere to write to and Minecraft freezes. The buffer is only 64 KB, and when it runs out, the server stops. After attaching to the process, it regains a "target" to write to and continues working

mcvcli/src/commands/start.rs

Lines 302 to 304 in e68ab9c

	.stdin(File::open(stdin.path()).unwrap())
	.stdout(File::create(stdout.path()).unwrap())
	.stderr(File::create(stderr.path()).unwrap())

I think you can use Stdio::null(), but I'm not sure if you can read logs created before the attach

[0x7d8]

This is definitely an annoying issue, the fd thing is fine (just points to a pipe), but the pipes are indeed limited to 64kb before they push backpressure

[0x7d8]

I could probably do it similar to screen, where I make mcvcli the ghost process instead of java, and then have full control of output behaviour