<arianvp>
remote-fs.target is fine there; but local-fs.target and swap.target are both phishy (they should be pulled in way earlier in boot; before sysinit.target)
<arianvp>
hmm; ok sleep now and make PR tomorrow :D
<flokli>
arianvp: local-fs.target and swap.target might have been old cruft left over
<flokli>
after we dropped these "don't make local-fs.target part of sysinit.target" patches
<andi->
now that we actually have a bunch of people that care about the systemd integration: Should be maybe try to have a regular chat about things we want to hack on? Especially regarding things like upstreaming our patches, systemd stage1 etc..
<arianvp>
like a bi-weekly short standup?
<arianvp>
flokli: Oh yeh now I remember
<arianvp>
local-fs.target was something to do with nixops no?
<arianvp>
nscd starts and stops multiple times for me during boot;
<arianvp>
which seems really odd
<arianvp>
ah nscd restarts every time /etc/resolv.conf gets written ;I see
<arianvp>
no wait that shouldn't be the case; it should reload instead
<arianvp>
does anybody else have nscd repeatedly starting and stopping during boot?
<andi->
arianvp: I wouldn't call it that because I don't want to pressure anyone but lets call it a sync of some sorts?
<andi->
arianvp: during my last reboot of this notebook nscd was started 3x
<andi->
seems to have been the same back in september, also 3x during bootup
<flokli>
Is it just being restarted, or segfaulting?
<flokli>
arianvp: local-fs.target was patched out of sysinit.target to handle nixops pushing keys for crypto volumes (and manually added to multi-user.target with the code you saw above)
<flokli>
These days, there remote-fs.target, and even something more granular like "cryptokeys via network", if we get cryptsetup support into systemd
<flokli>
+1 on some regular "things we'd like to tackle" meetup
<arianvp>
flokli:being restarted. I have a feeling NetworkManager or something else is restarting it
<arianvp>
something schedules a TryRestart call to dbus and restarts it
<arianvp>
but then later on nscd also restarts with no explicit reason; it's odd
<{^_^}>
#87221 (by mjlbach, 17 hours ago, open): No DNS until restarting firefox
<arianvp>
im getting more convinced we should just have nss modules in a global LD_LIBRARY_PATH
<arianvp>
given glibc people say this is safe to do
<flokli>
arianvp: naah
<flokli>
I'm so happy we mostly got rid of it
<flokli>
in our case, it starts to get really ugly if you have another glibc version
<flokli>
because this pulls in the whole closure of that library
<arianvp>
according to that thread that isn't an issue
<flokli>
I don't think they use NixOS
<arianvp>
nss modules can be linked against different version of glibc they say
<arianvp>
but maybe they're wrong :P
<arianvp>
but yeh still bit odd that nscd keeps restarting during boot
<arianvp>
havent been able to pinpoint why exactly. even with systemd.log_level=debug i dont really see why
<arianvp>
flokli: I also do not buy the whole glibc argument thingy
<arianvp>
doesnt nscd daemon run into the same issues itself?
<arianvp>
e.g. if nscd is from a different glibc than the nss modules you still have the same issue no?
<flokli>
arianvp: for nscd, it's not really a problem
<flokli>
as we construct the LD_LIBRARY_PATH for a matching nscd
<flokli>
write it in the unit
<flokli>
and then restart it
<flokli>
so nscd always matches with the rest of the nss modules
<flokli>
but if you mix and match other .so's with LD_LIBRARY_PATH, or RUNPATH pointing to impure locations (like we still need to do with OpenGL, for example), you end up with weird corner cases like the dynamic linker finding the library, but unwilling to load it, as it thinks it's incompatible
<flokli>
Only recently, I was banging my head against glxinfo not showing direct rendering. Until I realized that that glxinfo was linked against an older glibc, so the dynamic linker refused to load the opengl drivers
<flokli>
I'm quite happy about the nscd socket being a somewhat clean and stable interface here.