Unable to configure user name

[Tiwalun]

Description

I've just downloaded jujutsu on a new machine, but I'm unable to configure the username, or to interact with the config in any way. All operations involving config (jj config) seem to return an error about an invalid type or value.

Steps to Reproduce the Problem

1. Install jujustu using cargo binstall --strategies crate-meta-data jj-cli
2. Try to set user name using jj config set --user user.name "Martin von Zweigbergk"

The steps were performed on a machine where jujutsu was not installed, so no existing config was present.

Expected Behavior

I can set the username

Actual Behavior

The following error message is shown:

❯ jj config set --user user.name "Martin von Zweigbergk"
Config error: Invalid type or value for operation.username
Caused by: Null record
For help, see https://jj-vcs.github.io/jj/latest/config/.

I've tried setting the user name manually in ~/.config/jj/config.toml, but that doesn't seem to make a difference.

Specifications

• Platform: Ubuntu 24.04
• Version: jj 0.25.0-041c4fecb77434dd6720e7d7f1ce48d9575ac5f7

[arxanas]

Thanks for reporting. Does the issue also occur with jj v0.24?

[ilyagr]

Weird, I can't immediately reproduce it. What does jj config path --user say? Is there anything in that file? Does deleting (or, more safely, moving) it help?

Update: Yuya's comment below is probably more relevant.

[yuja]

Oh, do you have invalid (or maybe empty) name in your /etc/passwd entry? The old behavior was to fall back to "Unknown" or something. If that's common, the change should be reverted.

As a workaround, please add operation.username = "whatever" to config.toml.

[Tiwalun]

Thanks for reporting. Does the issue also occur with jj v0.24?

No, it seems to work fine with version v.024.

Oh, do you have invalid (or maybe empty) name in your /etc/passwd entry? The old behavior was to fall back to "Unknown" or something. If that's common, the change should be reverted.

I can't see anything obviously invalid in /etc/passwd, but I'm also not sure what exactly I should be looking for.

As a workaround, please add operation.username = "whatever" to config.toml.

Thanks, this seems to work.

[yuja]

I can't see anything obviously invalid in /etc/passwd, but I'm also not sure what exactly I should be looking for.

Can you run these commands? I expect the pwd entry would be missing, but I have no idea why. (Is it some container environment?)

$ id -u  # check uid
1000
$ python3 -c 'import pwd; print(pwd.getpwuid(1000))'  # get pwd entry for the uid (replace 1000 with the number printed above)
pwd.struct_passwd(pw_name=...)

[Tiwalun]

It's my work machine, there is some integration with active directory set up, but it's not a container environment.

The output looks like this:

python3 -c 'import pwd; print(pwd.getpwuid(391836079))'
pwd.struct_passwd(pw_name='tiwalun', pw_passwd='*', pw_uid=391836079, pw_gid=391800513, pw_gecos='Boehi, Dominik', pw_dir='/home/tiwalun', pw_shell='/bin/bash')

[yuja]

active directory set up

I'm not pretty sure, but the released binary doesn't use the system libc?, and it doesn't handle nsswitch properly?

[Tiwalun]

I've tried a simple example:

fn main() {
    let username = whoami::fallible::username();

    println!("I am {username:?}");
}

Compiled for musl:

cargo run --target x86_64-unknown-linux-musl
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/x86_64-unknown-linux-musl/debug/whomai_repro`
I am Err(Custom { kind: NotFound, error: "Null record" })

Compiled for system libc:

cargo run --target x86_64-unknown-linux-gnu
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/x86_64-unknown-linux-gnu/debug/whomai_repro`
I am Ok("tiwalun")

So it seems that whoami can't get the username if musl is used.

[joyously]

The error message has a difference between user.name and username.

[yuja]

it seems that whoami can't get the username if musl is used.

To be precise, musl wouldn't fully support name service switch. Local /etc/passwd works, but sssd wouldn't? #5232 will partially revert the change. I'll send a separate PR to add a fallback to $USER env var.

[kj]

I guess this will be fixed by the PR, but just wanted to add that perhaps this came up for me as I'm using systemd-homed (no entry in the /etc/passwd entry).