<torhex-pasmul[m]>
Putting a bind mount to `/nix` in the chroot helps. Now `mongod` dies with `SIGABRT`, no obvious info on why.
<isd>
Probably make-bundle.sh should be pulling in whatever it needs from /nix.
<torhex-pasmul[m]>
well, it particularly needs zlib and libstdc++.so.6
<isd>
There's a line in there that tries to use ldd to find all necessary shared libraries. So apparently this doesn't work on nix for some reason.
<torhex-pasmul[m]>
right, nixos doesn't keep a global list of shared libs, each executable has rpath set to their locations
<torhex-pasmul[m]>
further attempts indicate the `mongod` binary works fine when invoked outside of sandstorm's chroot, so it's something about the environment specifically
<isd>
ldd doesn't consult a global list; it examines (actually runs) the ELF itself. `ldd $(which nix-shell)` seems to work as expected for me.
<torhex-pasmul[m]>
Sure. But if you try it on the distributed `mongod` it links to zlib and libstdc++.so.6 without an absolute path and so it has to be added to rpath.
<isd>
Does it not show up in ldd if you've done that?
<torhex-pasmul[m]>
Yes after the executable is patched it shows up and runs fine
<torhex-pasmul[m]>
Aah, good, so it's primarily a data compat issue rather than API.
<isd>
the storage format is different on newer versions, so we'd have to script an upgrade for people's existing systems -- the mongo docs expect you to do an upgrade manually, which is a non-starter for sandstorm
<isd>
But yeah, other than that it should work on newer mongo
<isd>
I should get off the computer and start winding down for bed. Later.
<torhex-pasmul[m]>
Thanks for your support.
larjona has quit [Ping timeout: 258 seconds]
<torhex-pasmul[m]>
I believe I understand the mongo crash: bind-mounting `/dev/urandom` doesn't result in a device data can be read from.
<torhex-pasmul[m]>
`/dev/zero` exhibits the same behavior.
<torhex-pasmul[m]>
I'm going to try a patch to mount `/dev` instead of individual devices. Initial testing with `unshare` seems ok.
<isd>
hm, but it seems to be working with the standard build?
<isd>
There's a comment in there suggesting it's like that because bind mounting all of /dev wasn't working when in a UID namespace
<torhex-pasmul[m]>
Well, for whatever reason it doesn't work on my system (testing manually with `unshare` shows the same behavior)
<torhex-pasmul[m]>
Right now I'm facing the issue that meteor dependency fetching is definitely not deterministic
<torhex-pasmul[m]>
it's either putting a random value or a hash in the directory names for downloaded packages
<isd>
Does the standard build not work on your system?
<isd>
re: meteor, can't say I'm surprised :(
larjona has joined #sandstorm
xet7 has quit [Read error: Connection reset by peer]