[Bug] Fail to launch daemonize jailer v1.10.1

[xuehaonan27]

Describe the bug

jailer(v1.10.1) fail to run with flag --daemonize, and could run without flag --daemonize.

To Reproduce

1. Built jailer binary from tag v1.10.1.
2. Run following command:

/root/firecracker_src/build/cargo_target/x86_64-unknown-linux-musl/debug/jailer \
    --exec-file /root/firecracker_src/build/cargo_target/x86_64-unknown-linux-musl/debug/firecracker \
    --id "test-instance" \
    --gid 100 \
    --uid 123 \
    --daemonize

3. The process exits immediately.
4. Run following command (without --daemonize this time)

/root/firecracker_src/build/cargo_target/x86_64-unknown-linux-musl/debug/jailer \
--exec-file /root/firecracker_src/build/cargo_target/x86_64-unknown-linux-musl/debug/firecracker \
--id "test-instance" \
--gid 100 \
--uid 123

5. The console hang with [test-instance:main] Running Firecracker v1.10.1 which means jailer is running well.
6. Open another console, run tree /srv/jailer/firecracker/test-instance/ and could see output like this:

/srv/jailer/firecracker/test-instance/
└── root
    ├── dev
    │   ├── kvm
    │   ├── net
    │   │   └── tun
    │   ├── urandom
    │   └── userfaultfd
    ├── firecracker
    ├── firecracker.pid
    └── run
        └── firecracker.socket

There's a firecracker.socket which means it's running well too.

Expected behaviour

When running jailer with --daemonize, the process could be started and expose the API socket for communication.

Environment

• Firecracker version: v.1.10.1
• Host and guest kernel versions: Host kernel 6.8.0-51-generic; Guest kernel not used (bare jailer process).
• Rootfs used: Not used (bare jailer process).
• Architecture: x86_64 (x86_64 x86_64 x86_64 GNU/Linux)

Additional context

[Author TODO: How has this bug affected you?]
I am developing a firecracker SDK in Rust, this bug prevents me to test functionality with daemonized instances.

[Author TODO: What are you trying to achieve?]
Start the daemonized jailer and communicate with it via API socket.

[Author TODO: Do you have any idea of what the solution might be?]
I repeated exactly the same on firecracker / jailer v1.7.0. And it succeeds with a running daemonized firecracker and a API socket exposed.
PR #4259 (Commit da92bf6) seemed to have changed the behavior of daemonization.

Checks

• [y] Have you searched the Firecracker Issues database for similar problems?
• [y] Have you read the existing relevant Firecracker documentation?
• [y] Are you certain the bug being reported is a Firecracker issue?

[Manciukic]

I could reproduce this on my laptop (6.8/ubuntu) and a 6.1/amazon-linux metal instance using the commands above (slightly changed to make them work in the devtool):

/firecracker/build/cargo_target/x86_64-unknown-linux-musl/debug/jailer     --exec-file /firecracker/build/cargo_target/x86_64-unknown-linux-musl/debug/firecracker     --id "test-instance"     --gid 0     --uid 0     --daemonize

From what I can see, there seems to be a subtraction overflow happening in jailer/src/env.rs:718:

        self.jailer_cpu_time_us += get_time_us(ClockType::ProcessCpu) - self.start_time_cpu_us;

(gdb) bt
#0  __restore_sigs () at ../src_musl/src/signal/block.c:44
#1  0x00007ffff7d45454 in raise () at ../src_musl/src/signal/raise.c:11
#2  0x00007ffff7d42fdb in abort () at ../src_musl/src/exit/abort.c:11
#3  0x00007ffff7d2a28a in panic_abort::__rust_start_panic::abort () at panic_abort/src/lib.rs:48
#4  0x00007ffff7d2a279 in panic_abort::__rust_start_panic () at panic_abort/src/lib.rs:43
#5  0x00007ffff7d1a8be in std::panicking::rust_panic () at std/src/panicking.rs:862
#6  0x00007ffff7d1a7e7 in std::panicking::rust_panic_with_hook () at std/src/panicking.rs:826
#7  0x00007ffff7d1a546 in std::panicking::begin_panic_handler::{closure#0} () at std/src/panicking.rs:667
#8  0x00007ffff7d19999 in std::sys::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::{closure_env#0}, !> () at std/src/sys/backtrace.rs:170
#9  0x00007ffff7d1a20c in std::panicking::begin_panic_handler () at std/src/panicking.rs:665
#10 0x00007ffff7a64c30 in core::panicking::panic_fmt () at core/src/panicking.rs:74
#11 0x00007ffff7a653c7 in core::panicking::panic_const::panic_const_sub_overflow () at core/src/panicking.rs:181
#12 0x00007ffff7a9477a in jailer::env::Env::run (self=...) at src/jailer/src/env.rs:718
#13 0x00007ffff7a96798 in jailer::main_exec::{closure#1} (env=...) at src/jailer/src/main.rs:345
#14 0x00007ffff7a74616 in core::result::Result<jailer::env::Env, jailer::JailerError>::and_then<jailer::env::Env, jailer::JailerError, (), jailer::main_exec::{closure_env#1}> (self=..., op=...) at /rustc/90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf/library/core/src/result.rs:1348
#15 0x00007ffff7a9655c in jailer::main_exec () at src/jailer/src/main.rs:336
#16 0x00007ffff7a96093 in jailer::main () at src/jailer/src/main.rs:305

I think that calculation is wrong in the case of daemonize as the ProcessCpu time would get reset on the fork.

[Manciukic]

It seems that the jailer still works when in a release build because there are no overflow checks anymore, so that's why our CI didn't catch this bug. The parameter is just passed to firecracker cli for metric purposes I believe, it's not a functional value.