[18:53] woot. global jam time [18:54] also, anybody in the hillsboro area who is open to giving blood, yahoo's hosting a blood drive for redcross tomorrow [18:58] :D [18:58] 8am-11am [20:37] i think of firefly every time one of you folks joins [21:23] that was the intention ;) [21:41] heh [22:04] slangasek: have you ever seen dconf-service hang on login [22:43] blkperl: no. I assume this is running against an NFS homedir? ;) [22:44] blkperl: don't look at who's assigned to implement https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-xdg-runtime-dir [22:44] slangasek: I found a ticket https://bugs.launchpad.net/ubuntu/+source/d-conf/+bug/645448 [22:44] Launchpad bug 645448 in d-conf (Ubuntu) "dconf doesn't support NFS" [Medium,Triaged] [22:44] heh [22:48] slangasek: so if we point XDG_CACE at /tmp or something it seems to allow login [22:48] XDG_CACHE* [22:48] we think that the homedir doesn't mount until in late in the login process which is why it just hangs in kernel land [22:49] oh? [22:49] are you using autofs? [22:50] yes [22:50] ah [22:50] so yeah, autofs was something of a blind spot while implementing upstart boot-time filesystem handling [22:51] essentially because the last time I tried to use it 8 years ago, it was crap, and I assumed everyone else had reached the same conclusion and only tested /etc/fstab-based mounting ;) [22:51] I know there've been a couple of escalated bugs recently about autofs support, but I don't know where those got to [22:51] well we use autofs because we can't have 5000 homedirs mounted at the same time on 200 nodes :) [22:52] if you can point me to those autofs bugs that would be great [22:52] right, but you could have a single /home mounted everywhere ;) [22:52] but yeah, I realize this doesn't scale out [22:53] looking now to see if there are any autofs SRUs that have gone through recently [23:00] blkperl: there've been recent autofs SRUs for lucid and natty, but I'm pretty sure it's not related to what you're seeing [23:03] slangasek: do you see any pitfalls with using /tmp for XDG_CACHE? This workaround seems to work [23:03] blkperl: I couldn't say [23:04] based on conversations at the last UDS I think later versions of dconf may have addressed this, but I'm not sure how [23:06] I made a bug 1046079 if your interested in commenting [23:06] Launchpad bug 1046079 in d-conf (Ubuntu) "dconf-service hangs on login with nfs mounted homedir" [Undecided,New] https://launchpad.net/bugs/1046079 [23:07] commenting is almost certain to get me nag mail from the desktop team about XDG_RUNTIME_DIR support not being done yet ;P [23:07] how about if I just work on that [23:07] yeah that sounds great :) [23:37] :) [23:40] blkperl: i might suggest /var/tmp [23:40] blkperl: you going to hack day on saturday at puppetlabs? [23:40] instead of /tmp, as it's guaranteed to remain present until reboot [23:40] whereas /tmp may be purged... [23:40] nathwill: Kitsune is alive http://15.185.226.243:8000/en-US/home [23:40] :D [23:41] nathwill: that doesn't solve the problem of users on multiple hosts at the same time [23:41] they changes hosts a lot and because nfs is broken.... [23:41] bkerensa: what hack day? [23:41] bkerensa: calagator link? [23:41] blkperl: MFNW+PDX [23:42] http://calagator.org/events/1250462748 [23:42] blkperl, i was suggesting a better location for XDG_CACHE than /tmp [23:42] but i see what you're saying... i seem to remember a bug about dconf and nfs homes, and the solution being to change the boot order...