exec -a broken on coreutils

[cfricke]

Issue description

When executing exec -a "name" sleep 1 bash fails to rename the current process to "name" (pass "name" as 0th argument) and exits with name: unknown program 'name'. I have verified with various different bash versions (.31, .49) on none-NixOS systems. This behavior is unique to NixOS, as far as I can tell.

Steps to reproduce

• Run bash with clean env: env -i bash
• Execute test command:

bash-4.3$ exec -a name sleep 1
name: unknown program ‘name’
Try 'name --help' for more information.

Technical details

• System: 16.09pre87381.ddb7588 (Flounder)
• Nix version: nix-env (Nix) 1.11.2
• Nixpkgs version: 16.09pre87381.ddb7588

[langston-barrett]

I can't reproduce this:

~ > bash --version
GNU bash, version 4.3.42(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
~ > env -i bash
bash-4.3$ exec -a name sleep 1
~ >

[cfricke]

The curious thing here is that this error message supposedly is not even contained in the bash source code, it's actually a zsh error message.

If I log in as root in a TTY (skipping any xsession, personal profile settings and display manager configuration), with an empty home directory, I get a clean bash shell, where $SHELL, $0 and ps -p $$ are all referencing bash. Still, I see:

$ exec -a name sleep 1
name: unknown program ‘name’
[configuration.txt](https://github.com/NixOS/nixpkgs/files/383845/configuration.txt)
Try 'name --help' for more information.

Is there a tool like nix-container that would help to isolate this even further? Attaching my configuration.txt

[matthiasbeyer]

I can reproduce:

GNU bash, Version 4.3.42(1)-release (x86_64-unknown-linux-gnu)

on:

• System: 16.09pre87431.3badad8 (Flounder)
• Nix version: nix-env (Nix) 1.11.2
• Nixpkgs version: "16.09pre87431.3badad8"

[dezgeg]

It is coming from / due to the single-binary coreutils build.

[anderspapitto]

@dezgeg could you expand on that? I have no idea what you mean.

I'm also seeing this on unstable. There's no hint of zsh anywhere on my system.

[anderspapitto]

If someone can point me towards what the 'single-binary coreutils build' is, I'd like to investigate why that change would have broken this feature.

[dezgeg]

Since recent changes to the coreutils expression (i.e. check git log) all the coreutils programs are just symlinks to a single binary, so argv[0] is then used to resolve which program from coreutils needs to be run.

[anderspapitto]

cool. So, I've done a little bit of digging and it looks like this is an upstream bug, though I'm not sure if it's coreutils' bug or bash's bug, or a bug of any software that uses both of them. exec -a works by setting argv[0], and with the single-binary option, coreutils depends on argv[0] to know what program it is. Other programs that don't use such tricks should be fine. For example,

[anders@gurney:~]
$ bash -c 'exec -a name sleep 1'
name: unknown program ‘name’
Try 'name --help' for more information.
[anders@gurney:~]
$ bash -c 'exec -a sleep sleep 1'
[anders@gurney:~]
$ bash -c 'exec -a echo sleep 1'
1
[anders@gurney:~]
$ bash -c 'exec -a name git --version'
git version 2.9.2

[moyamo]

It seems this problem can be bypassed by appending /<program name> to argv[0]. e.g.

$ bash -c 'exec -a name sleep 10'
name: unknown program ‘name’
Try 'name --help' for more information.
$ bash -c 'exec -a "name/sleep" sleep 10'
# Terminal sleeps for 10 seconds

[vcunat]

Single-binary build of coreutils is known to break some weird use cases. So far I fail to see some that would justify us switching the default coreutils back. Affected people can also use coreutils.override { singleBinary = false; }.

[anderspapitto]

@vcunat The thing is, since no other distro does this (the single-binary feature was added specifically for the stripped-down android userland), all the miscellaneous software that does have a dependency is going to stay broken forever (for example - who can you picture ever fixing https://git.zx2c4.com/password-store/tree/src/password-store.sh#n140 ?). Having a smaller coreutils isn't part of NixOS's core value proposition, so I don't think it makes sense to innovate there if the cost is that more random things are broken that "just work" on other distros. A certain amount of breakage is unavoidable just due to how Nix works - why opt in to more pain when we do have a choice?

Also, changing coreutils is a mass-rebuild type of change - modifying it via packageOverrides doesn't strike me as a reasonable workaround (I just tried it - but all I want is for passmenu to work, not to rebuild docker and chromium from source).

[vcunat]

changing coreutils is a mass-rebuild type of change

I meant you can use the overridden coreutils only for the packages where needed, without affecting stdenv or anything else.

[moyamo]

@anderspapitto I'd like to point out that their does seem to be a patch for password store, but I do not know if it will be merged upstream.

I agree that coreutils shouldn't be the single binary, just because it saves ~5MB.

[Profpatsch]

(triage) I think this issue is at an impasse. What would be the way forward?

[cfricke]

I have no meaningful input on the topic, other that my original issue regarding pass has been fixed in that application.

[Profpatsch]

I’ll close, feel free to reopen, みんなさん