Running shpool in background consumes CPU

[rEnr3n]

What happened
I'm coming from tmux. I have a bash script containing multiple instances of tmux new-session -d. I want to replicate that in shpool. I wrote a bash script (see To Reproduce) and ran it. There are two shpool processes consuming one cpu thread each.

What I expected to happen
It shouldn't consume high cpu cycles forever.

To Reproduce
Steps to reproduce the behavior:

1. Write this bash script

#!/usr/bin/env bash
shpool attach 1 &
shpool attach 2 &

2. Run the script

Version info

$ shpool version
shpool 0.8.0

Logs
shpool1.log

[jasom]

I'm seeing a very similar behavior (100% cpu usage) when running shpool from a systemd service.

[ethanpailes]

On my system, shpool is hardly using any CPU, so this is a bit hard for me to repro and debug. Are either of you willing to try a little profiling to try to figure out where the hotspot is? I don't have a goto profiling tool for shpool for stuff like this, but maybe building shpool in debug mode (so just cloning this repo and building it with cargo build) and then running the daemon using the kcachegrind tool, which I think you do by prepending valgrind --tool=callgrind to the command you would use to invoke the daemon. That should hopefully produce a visualization that shows us where shpool is spending all its time and let us fix the problem.

[jasom]

I'll work on the above steps, but I manually sampled backtraces of the thread in question and found this backtrace to represent the common case:

#0  0x00007f212ca91f0c in read () from /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib/libc.so.6
#1  0x000055d88b75068c in <std::io::buffered::bufreader::BufReader<R> as std::io::Read>::read ()
#2  0x000055d88b5eff5d in std::sys::backtrace::__rust_begin_short_backtrace ()
#3  0x000055d88b6232cd in core::ops::function::FnOnce::call_once{{vtable.shim}} ()
#4  0x000055d88b77da1b in std::sys::pal::unix::thread::Thread::new::thread_start ()
#5  0x00007f212ca1bea3 in start_thread () from /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib/libc.so.6
#6  0x00007f212ca9fdfc in __clone3 () from /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib/libc.so.6

[jasom]

I also found a very simple way to reproduce:

nohup shpool attach foo

This runs shpool outside of a terminal, with an unreadable stdin, which is somewhat similar to how it is run from within systemd.

[jasom]

I strongly suspect that this is the cause:

shpool/libshpool/src/protocol.rs

Lines 258 to 261 in 0e45a86

	let nread = stdin.read(&mut buf).context("reading stdin from user")?;
	if nread == 0 {
	continue;
	}

EOF on stdin will cause this to loop forever, with stdin::read always returning Ok(0)

[jasom]

shpool attach foo </dev/null also reproduces the 100% CPU usage, further supporting this theory.

[jasom]

As an aside, if thread::Builder were used to name the two I/O threads, this would have been quicker to track down.

[ethanpailes]

As a workaround, you can probably just kill the attach processes that you are using to create the sessions after a second or so. That should take care of the CPU pegging and put the sessions in detached mode.