Trouble sleeping (problem with sleep command)

1

I am very familiar with Linux but very unfamiliar with NixOS. I’m digging into it.

I have come across strange behaviour with sleep.

Can anyone think of an explanation for what I’m seeing?

$ time /run/current-system/sw/bin/sleep 1s

real    1m0.064s
user    0m0.002s
sys     0m0.006s

$ time sleep --version

real    1m0.064s
user    0m0.003s
sys	    0m0.004s


$ file /nix/store/wm44fyi9ya4r354rkfn075chss24lmwh-cni-0.8.1/bin/sleep
/nix/store/wm44fyi9ya4r354rkfn075chss24lmwh-cni-0.8.1/bin/sleep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=iG-YzV4q5KA00ueCwOs3/ZEg5iA_aPvHIl6_eeHDK/qvEWRILe6n4uEKL7_ovu/MfCMSOBpBrf6Xjy2IhMH, not stripped
2 Likes
2

This is in whatever the CNI package is. The typical sleep binary would come from coreutils.

As an aside, Nix eats these kinds of conflicts for lunch. Unless you really need whatever it is that the cni package does at all times, you can leave it out of your system/user packages and only have it on PATH within a shell for working on the project(s) that need it, or only within the scripts that invoke it, etc.

1 Like
3

Thank you for your insight. I am curious to know what you mean by “Nix eats these kinds of conflicts for lunch.”

Apparently when I added the cni package (networking for containers) Nix changed the symlink from the coreutils sleep binary to the cni sleep binary.

$ file /run/current-system/sw/bin/sleep
/run/current-system/sw/bin/sleep: symbolic link to /nix/store/wm44fyi9ya4r354rkfn075chss24lmwh-cni-0.8.1/bin/sleep

When I removed the cni package Nix re-linked to the coreutils sleep binary.

$ file /run/current-system/sw/bin/sleep
/run/current-system/sw/bin/sleep: symbolic link to /nix/store/wyjmlzvqkkq0pn41aag1jvinc62aldb1-coreutils-9.0/bin/sleep

Is there a way to avoid collisions like this or at least be alerted to them?

Before you say RTFM, I am :slight_smile:

Thanks again!!!

4

TBH I thought it worked this way. I think I see the code that would trigger it, and I see past discussions about the warnings. Maybe we can bait someone with a deeper knowledge pool in… @ggpeti @roberth? :slight_smile:

It’s not terribly well documented, but there’s a notion of priority that can help you triage an issue like this. If lib is in scope, you can replace cni in your list of packages with something like (lib.setPrio 20 cni) to decrease the priority of that package.

  • Most importantly, Nix makes it easy to create more granular environments tailored to some specific projects/scripts/task. This enables us to keep packages that don’t actually contain things we’re constantly invoking out of our system/user environment to minimize the number of conflicts that we need to sweat.
  • When we do have to sweat a conflict, Nix enables us to write code to control the relevant environment (whether system, user, or more granular). This gives us as much control as we need to get the results we want in most cases.
5

Trouble sleeping (problem with sleep command)

Glad you specified, but just in case, they make pills for the former :wink: Unless you’re losing sleep over your problem with the sleep command.

1 Like
6

It’s crazy that it only warns when there’s a conflict.
Warnings in builds especially must be assumed to be invisible, not just because of the lack of logs by default in the CLI, but because they won’t be shown unless there’s something to re-build (or reconfigure).
It should error by default, perhaps with an option to allow conflicts.
I’m also surprised that coreutils doesn’t get priority. I guess it’s “nice” for customization, but I don’t think Sysnic73 is happy about his “customization”. I don’t really want it to be prioritized by default though. An error is better. Explicit is good. Principle of least surprise, that kind of thing.

Warnings during evaluation are slightly better, but they’re still warnings and therefore a bad experience. In this case we can’t know the problem during evaluation, so that’s not useful here. (but maybe why I was pinged?)

2 Likes
7

I just pinged you because you helped review and merge buildEnv: better warning and error messages by ggPeti · Pull Request #134215 · NixOS/nixpkgs · GitHub, which looks like the most recent update to the collision code.

1 Like
8

Hmm. Perl code. Not a language I can confidently review. I can nag about tests though :laughing:

9

It’s still early days for me with Nix (day 2) but I agree with you, a conflict like this should error by default.

I reinstalled the cni package with the same result. I captured the rebuild output, there was no mention of the conflict. This seems like a problem.

1 Like
10

When i first started out with nix, i’d nix-env installed busybox and forgot about it. That caused me all sorts of fun and games with collisions in my user environment.

I now stray away from this pattern, and basically just use nix shells or nix develop shells, and add the minimal essential programs to my nixos system packages.

normal distros have a mechanism for detecting collisions, especially in /usr/bin and related default system folders.

naming stuff in computer science is hard, and unix is no exception to this.

2 Likes
11

I started my Linux journey in 1993 with Slackware 1.0 and Kernel 0.9x (I think).

Over the years I have tried many distros. I spent most of my career in the Red Hat ecosystem. I currently run Fedora pretty much exclusively on my home servers and workstations but NixOS and Nix are so intriguing that I’m considering a switch. It’s clear that with NixOS I still have a lot to learn.

I’m quite embarrassed that abathur had to point out to me that the problematic sleep was bundled with the cni package and not with the standard coreutils package.

BTW, I’m very impressed with the feedback I’ve been receiving to my post. I’m looking forward to hellping others in the future.

5 Likes
12

Watch out, nix it can be addictive!

If you can get over the original hurdle of ‘it’s unix jim, but not as we know it’, then i am pretty certain you’ll find that a declarative reproducible system is what you’ve been looking for all this time. You really have to use traditional tools for quite some time, to understand what their major short comings are, nix dares to do things differently. If it’s not nix that ‘wins’ this way of approaching software assembly and configuration… , it will be Guix , if it’s not Guix it will be something else that replicates this idea (well).

No matter how much unix/linux experience you have, were all basically learning new stuff here as well as sharing general unix experience too. It always feels like a level playing field and people like yourself have a lot to give i assure you…,even if you nix skills are embryonic at this time.

There are some great resources here and all around. Real humans will be willing to help you if you can ask great questions, put a little bit of work into to achieving what you want, and because nix is real infrastructure as code, test cases or git repo’s that can be cloned are always welcome, so the results can be reproduced.

You might even get the ‘nix bug’, and git checkout a version of nixpkgs, becoming a committer and squash a few bugs, adding a package or maintaining some you care about! You never know.

Maybe, you’ll like it so much you’ll sneak in at work , and if works then there are a lot of companies now doing fee based nix consultancy and customer success services in your country.

Nix, solves a lot of problems and give you some new problems, which IMHO are nicer to have.

Welcome!!! , I hope you have some fun with nix, now and into the future.

Also, GitHub - nix-community/nix-index: Quickly locate nix packages with specific files [maintainers=@bennofs @figsoda @raitobezarius] may help you in the future! many cool nix tools are not part of the base operating system :frowning:

p.s. reddit is also good for a much needed laugh… https://www.reddit.com/r/NixOS/comments/o6sgw5/unfortunately_no_one_can_be_told_what_nix_is_you/

13

I’ve been away from the computer for a while. Thanks for the pep talk.

14

no worries…! I’ve been away for a bit too, but slowly reentering the matrix.