Fails to read creation time for exited sessions on musl libc

[pedromfedricci]

2. Issues with the Zellij UI / behavior / crash

Basic information

binary: https://github.com/zellij-org/zellij/releases/download/v0.39.2/zellij-x86_64-unknown-linux-musl.tar.gz zellij --version: zellij 0.39.2 libc: musl libc v1.1.24 cross: ghcr.io/cross-rs/x86_64-unknown-linux-musl:0.2.5

Issue description

The recent Session Resurrection features (CLI and Session Manager) fail to read the creation time (ctime) for exited session files on musl libc since both Rust's std and the libc crate do not support it. Libc only supports statx for gnu and so std does not provide statx for musl. Because of this, the ReadAllSessionInfosOnMachine background job will always send the value 0 (Duration's default) as the current duration for exited sessions, code location.

Zellij ls

Zellij session-manager

Since the ReadAllSessionInfosOnMachine background job fetches session data in a loop, this issue also happens to fill the log file with Failed to read created stamp of resurrection file: Error { kind: Unsupported, message: "creation time is not available on this platform currently" quite fast, writing a new entry for every tick (default 1sec) x no. of active sessions x no. of exited sessions with a session-layout.kdl file.

Minimal reproduction

1. Download Zellij for linux/musl: https://github.com/zellij-org/zellij/releases/download/v0.39.2/zellij-x86_64-unknown-linux-musl.tar.gz
2. Run one or more sessions with the downloaded Zellij: <your_path>/zellij
3. Wait for about 1 minute so that Zellij will write layout snapshots for your new sessions
4. Confirm that session-layout.kdl files have been written with: ls ~/.cache/zellij/0.39.2/session_info/*
5. Close all sessions from step 2
6. Check their exit status and wrong duration with <your_path>/zellij ls (created: 0s ago is incorrect)
7. Run a new session like step 2
8. Check incoming errors in the log file with: tail -f /tmp/zellij-1000/zellij-log/zellij.log

Other relevant information

Building Zellij in a linux/gnu environment (cargo build --release or cargo install zellij) does not have such issues.

[pedromfedricci]

Some possible solutions that I could think of (other designs and ideas are welcome):

1. Keep current behavior for musl targets (always shows 0s ago) and either suppress the error entirely or cache it and then log it only once.
2. When targeting musl specifically, show the duration since last modification (that would be the last time Zellij took a snapshot) for exited sessions. This of course will not represent the "created at" duration accurately.
3. Update the behavior for all targets to show "last snapshot" instead of creation. The UI would read something like "Last Save", "Saved", etc. This would deviate the most from the current experience though. But one could argue that "last saved time" is a better hint to what the session will look like in comparison to its full duration.

[steakhutzeee]

I'm experiencing this too.

Also a question, so we need to wait 1 minute for the session to be cached?

If I create a session, issue some random command and then quit with Ctrl + q then I can't see the session with zellij ls

[pedromfedricci]

Yeah you need to wait for at least the serialization_interval's value (default 60 seconds) and session_serialization must be set to true (which is the default value).

[steakhutzeee]

Yeah you need to wait for at least the serialization_interval's value (default 60 seconds) and session_serialization must be set to true (which is the default value).

Thanks! Can this time be configured? Do not see it in the docs.

[pedromfedricci]

It is not in the docs page yet, but you can add to your config.kdl like this (value is in seconds):

serialization_interval 300

[brandonkal]

Could you release a gnu-linux binary at least until this is fixed?

[pedromfedricci]

I don't think a gnu based binary release is planned. The musl based one is convenient and easy enough to distribute, since it's all statically linked. The zellij package from your distribution is very likely built from source, targeting linux-gnu though. Another option is to build it yourself, I think that would only require you to install a Rust toolchain.

[sstark]

Is this also the reason why I get the following logged in zellij.log multiple times a second?

ERROR  |zellij_server::background| 2024-11-16 23:04:03.846 [async-std/runti] [zellij-server/src/background_jobs.rs:485]: Failed to read created stamp of resurrection file: Error { kind: Unsupported, message: "creation time is not available on this platform currently" }
ERROR  |zellij_server::background| 2024-11-16 23:04:03.846 [async-std/runti] [zellij-server/src/background_jobs.rs:485]: Failed to read created stamp of resurrection file: Error { kind: Unsupported, message: "creation time is not available on this platform currently" }
ERROR  |zellij_server::background| 2024-11-16 23:04:03.846 [async-std/runti] [zellij-server/src/background_jobs.rs:485]: Failed to read created stamp of resurrection file: Error { kind: Unsupported, message: "creation time is not available on this platform currently" }

[pedromfedricci]

Is this also the reason why I get the following logged in zellij.log multiple times a second?

ERROR  |zellij_server::background| 2024-11-16 23:04:03.846 [async-std/runti] [zellij-server/src/background_jobs.rs:485]: Failed to read created stamp of resurrection file: Error { kind: Unsupported, message: "creation time is not available on this platform currently" }
ERROR  |zellij_server::background| 2024-11-16 23:04:03.846 [async-std/runti] [zellij-server/src/background_jobs.rs:485]: Failed to read created stamp of resurrection file: Error { kind: Unsupported, message: "creation time is not available on this platform currently" }
ERROR  |zellij_server::background| 2024-11-16 23:04:03.846 [async-std/runti] [zellij-server/src/background_jobs.rs:485]: Failed to read created stamp of resurrection file: Error { kind: Unsupported, message: "creation time is not available on this platform currently" }

Yeah, that is correct. I would recommend running a glibc linked executable for now, it will work properly.