Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running Nix under strace, I see lots of invalid close syscalls #1506

Closed
copumpkin opened this issue Aug 8, 2017 · 7 comments
Closed

Running Nix under strace, I see lots of invalid close syscalls #1506

copumpkin opened this issue Aug 8, 2017 · 7 comments

Comments

@copumpkin
Copy link
Member

copumpkin commented Aug 8, 2017

See here:

[pid 30244] prctl(PR_SET_SECCOMP, 0x2, 0xb04880, 0xffffffffffffff78, 0) = 0
[pid 30244] chdir("/tmp/nix-build-foo-build.drv-0") = 0
[pid 30244] prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid 30244] close(3)                    = 0
[pid 30244] close(4)                    = 0
[pid 30244] close(5)                    = 0
[pid 30244] close(6)                    = 0
[pid 30244] close(7)                    = 0
[pid 30244] close(8)                    = 0
[pid 30244] close(9)                    = 0
[pid 30244] close(10)                   = 0
[pid 30244] close(11)                   = 0
[pid 30244] close(12)                   = 0
[pid 30244] close(13)                   = 0
[pid 30244] close(14)                   = 0
[pid 30244] close(15)                   = 0
[pid 30244] close(16)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(17)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(18)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(19)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(20)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(21)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(22)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(23)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(24)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(25)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(26)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(27)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(28)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(29)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(30)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(31)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(32)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(33)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(34)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(35)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(36)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(37)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(38)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(39)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(40)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(41)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(42)                   = -1 EBADF (Bad file descriptor)
[pid 30244] close(43)                   = -1 EBADF (Bad file descriptor)
... hundreds of thousands more lines ...
[pid 30244] close(1048567)              = -1 EBADF (Bad file descriptor)
[pid 30244] close(1048568)              = -1 EBADF (Bad file descriptor)
[pid 30244] close(1048569)              = -1 EBADF (Bad file descriptor)
[pid 30244] close(1048570)              = -1 EBADF (Bad file descriptor)
[pid 30244] close(1048571)              = -1 EBADF (Bad file descriptor)
[pid 30244] close(1048572)              = -1 EBADF (Bad file descriptor)
[pid 30244] close(1048573)              = -1 EBADF (Bad file descriptor)
[pid 30244] close(1048574)              = -1 EBADF (Bad file descriptor)
[pid 30244] close(1048575)              = -1 EBADF (Bad file descriptor)
[pid 30244] uname({sys="Linux", node="70126c8570fa", ...}) = 0
[pid 30244] personality(0xffffffff /* PER_??? */) = 0
[pid 30244] personality(0x40000 /* PER_??? */) = 0
[pid 30244] setgroups(1, [30000])       = 0
[pid 30244] setgid(30000)               = 0
[pid 30244] getgid()                    = 30000
[pid 30244] getegid()                   = 30000
[pid 30244] setuid(30001)               = 0
[pid 30244] getuid()                    = 30001
[pid 30244] geteuid()                   = 30001
[pid 30244] rt_sigaction(SIGPIPE, {SIG_DFL, [], SA_RESTORER, 0x7f83a4f9e840}, NULL, 8) = 0
[pid 30244] write(2, "\1\n", 2)         = 2
[pid 30240] <... read resumed> "\1", 1) = 1
[pid 30244] execve("/nix/store/y6mfysf2w7yx30bfyp9qk9br29qccwlw-bash-4.4-p12/bin/bash", ["bash", "-e", "/nix/store/9krlzvny65gdc8s7kpb6l"...], [/* 22 vars */] <unfinished ...>
[pid 30240] read(14, "\n", 1)           = 1

I can't find anything obvious in the Nix source code that would cause that behavior, but I figured I'd point it out, since it seems like wasted effort.

I'm on 1.11.13.

cc @shlevy @domenkozar @edolstra

@shlevy
Copy link
Member

shlevy commented Aug 8, 2017

https://github.com/NixOS/nix/blob/master/src/libutil/util.hh#L266

@copumpkin
Copy link
Member Author

Upon further inspection, this appears to be intentional: https://github.com/NixOS/nix/blob/1.11.13/src/libutil/util.cc#L1035-L1043

I'll leave this open to make sure this is intentional.

@dezgeg
Copy link
Contributor

dezgeg commented Aug 8, 2017

As sad it sounds, that is the portable way of closing all file descriptors (ensuring you don't leak them to the builds for example).

https://stackoverflow.com/questions/899038/getting-the-highest-allocated-file-descriptor/918469#918469 for the non-portable ways of doing the same thing.

@copumpkin
Copy link
Member Author

Can we not get away with {O,FD}_CLOEXEC flags to avoid this altogether?

@dezgeg
Copy link
Contributor

dezgeg commented Aug 8, 2017

No, since the process could have inherited non-O_CLOEXEC file descriptors from its parent.

@copumpkin
Copy link
Member Author

Boo, okay. I guess I'll close this then 😦

@copumpkin
Copy link
Member Author

Lovely, thanks @edolstra

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants