=== dspiteri is now known as Guest30044 === bigjools is now known as 21WACCDQH === jam is now known as Guest86076 === Guest86076 is now known as jam21 === jam21 is now known as jam1 [08:09] mornin' all === rogpeppe2 is now known as 16WAALSO4 === 16WAALSO4 is now known as rogpeppe === niemeyer is now known as 45PABCUAQ === bradm is now known as 5EXAAH0BV === wallyworld is now known as Guest64110 === benji is now known as Guest23911 === gary_poster|away is now known as gary_poster === Guest23911 is now known as benji [14:02] can anyone else bootstrap the local environment using trunk? [14:04] i get "restart: Unknown job: rsyslog" in /home/rog/.juju/local/log/cloud-init-output.log === dstroppa_ is now known as dstroppa === rogpeppe is now known as rogpeppe1 === rogpeppe1 is now known as rogpeppe [14:19] _thumper_: hiya [14:19] <_thumper_> oh hai [14:19] _thumper_: the local provider seems broken for me currently on trunk BTW [14:19] <_thumper_> awesome [14:19] _thumper_: i can't get it to bootstrap at all [14:19] <_thumper_> wasn't me === _thumper_ is now known as thumper [14:19] how are you bootstrapping? [14:20] thumper: juju bootstrap -e local --debug [14:20] that should work [14:20] thumper: indeed :-) [14:20] what's the error? [14:21] thumper: 2014-02-03 14:10:34 ERROR juju.cmd supercommand.go:294 exit status 1 [14:21] :-) [14:21] that sounds very familiar [14:21] I think I hit that too [14:21] * thumper thinks [14:21] thumper: looking in cloud-init-output.log, i see this: [14:22] restart: Unknown job: rsyslog [14:22] thumper: which i think is probably the cause [14:22] wat? [14:22] you should have rsyslog running [14:22] it is part of the OS [14:22] sudo status rsyslog [14:23] thumper: status: Unknown job: rsyslog [14:23] well there's you're problem [14:23] your [14:23] haha [14:23] rogpeppe: go [14:23] sudo start rsyslog [14:23] unknown job [14:23] ? [14:24] thumper: yeah [14:24] do you have rsyslog installed? [14:24] start: Unknown job: rsyslog [14:24] thumper: yes [14:24] thumper: and there's a /etc/rsyslog.d directory [14:24] thumper: containing a 25-juju-rog-local.conf file [14:24] rogpeppe: is there /etc/init/rsyslog.conf? [14:25] thumper: yes [14:25] plz run rsyslog [14:25] sudo start rsyslog [14:25] thumper: that doesn't work, as i pasted above [14:25] um... [14:25] bollocks [14:26] it is lying [14:26] thumper: i could try running rsyslogd directly, i suppose [14:26] I wouldn't [14:26] upstart should start it [14:26] actually [14:26] yes [14:26] run it manually [14:26] if it is failing to start, it should tell you why [14:26] but rsyslog should be running [14:27] thumper: rsyslogd is already running [14:28] but upstart doesn't think so? [14:28] that's problematic [14:28] thumper: initctl --list doesn't list it [14:28] thumper: but service --status-all does [14:28] you need help from someone that understands [14:28] * rogpeppe doesn't know how initctl (upstart) and service interact [14:29] the fundamental problem is that "sudo restart rsyslog" fails [14:29] thumper: yeah [14:30] * rogpeppe straces start rsyslog [14:32] i suppose it might just be trusty brokenness [14:33] rogpeppe: works for me on trusty, but maybe there's something else going on [14:34] ha, this is interesting: [14:34] % sudo initctl --system start rsyslog [14:34] initctl: Job is already running: rsyslog [14:34] % sudo initctl start rsyslog [14:35] initctl: Unknown job: rsyslog [14:35] *twilight zone music* [14:35] "initctl --system list" prints loads more jobs [14:36] i wonder what the default, without --system, is doing [14:37] perhaps i've got two /etc/init instances running [14:37] hmm, i have [14:38] /sbin/init and init --user [14:38] i bet that's the issue here [14:39] the init --user is started by lightdm, whatever that is [14:39] * rogpeppe googles it [14:40] i wonder if it's related to this: http://lwn.net/Articles/547422/ [14:42] natefinch: have you also got an "init --user" process running? [14:43] rogpeppe: looking [14:44] rogpeppe: how can I see what the actually command line was? [14:44] natefinch: i did "ps alxw | grep init" [14:44] rogpeppe: yep, I have both [14:45] natefinch: hmm, and "initctl list" and "initctl --system list" print the same thing for you? [14:46] rogpeppe: the --system one lists a hell of a lot more, if that's what you mean [14:46] natefinch: right [14:46] natefinch: what's the output of "initctl list" for you? [14:47] rogpeppe: http://pastebin.ubuntu.com/6867463/ [14:48] natefinch: and "initctl start rsyslog" works for you? [14:48] natefinch: sorry, sudo initctl start rsyslog, of course [14:48] rogpeppe: I was gonna say, not without sudo.... yes, with sudo it works fine [14:49] natefinch: weird [14:49] natefinch: what's the output of "sudo strace initctl start rsyslog" for you? [14:50] rogpeppe: http://pastebin.ubuntu.com/6867473/ [14:51] natefinch: thanks [14:51] rogpeppe: welcome. Gotta step away from the keyboard for a bit. [14:51] natefinch: k [14:54] natefinch: interesting, yours is opening a different unix socket from mine [14:54] natefinch: yours opens /com/ubuntu/upstart; mine opens /com/ubuntu/upstart-session/1000/3730 === vds` is now known as vds [15:12] natefinch: issue solved [15:13] local environment bootstrapped, phew [15:36] * rogpeppe gets lunch [16:15] natefinch: does the local provider work for you (on tip) ? [16:15] natefinch: i can bootstrap, but not call juju status after that [16:22] rogpeppe: lemme try [16:22] natefinch: thanks === Makyo is now known as Guest92118 [16:26] rogpeppe: ug, annoying.... evidently we now have a check to make sure mongod is in /usr/bin/mongod? That's not where my mongo is :/ [16:26] natefinch: ha ha [16:26] rogpeppe: I can symlink it, but still, annoying [16:26] natefinch: does it work if you symlink it [16:26] ? [16:26] rogpeppe: we'll see [16:32] rogpeppe: sonofa.... man, we gotta fix the local provider. It's so so so configuration specific. I forgot it always has problems building jujud because root doesn't have go in its path [16:32] natefinch: you shouldn't run it with sudo now [16:33] rogpeppe: tried that first - ERROR juju supercommand.go:282 bootstrapping a local environment must be done as root [16:34] natefinch: what revision are you using? [16:34] rogpeppe: tip.. just pulled and everything [16:34] natefinch: i suspect you haven't go installed everything [16:35] natefinch: because on my machine (rev 2291) it works ok [16:35] rogpeppe: what besides juju do I need to go install? [16:35] cmd/juju tha tis [16:35] natefinch: i generally do go install ./cmd/... [16:35] natefinch: or everything [16:36] rogpeppe: ok, good to know [16:37] rogpeppe: that'll probably fix the "can't build jujud" thing [16:37] natefinch: maybe [16:37] natefinch: the local provider has a very weird way of finding jujud [16:38] natefinch: it finds juju and then looks in the same directory as that for jujud [16:38] natefinch: so unless they're in the same directory, it won't work [16:38] rogpeppe: yeah that fixed the "need sudo" problem and thus it was able to build jujud, even though it shouldn't have needed to, since it's in the path [16:38] rogpeppe: spoke too soon... still ends with needs root [16:38] natefinch: so... can you run "juju status" successfully now? [16:39] rogpeppe: I can't bootstrap still [16:40] natefinch: are you absolutely sure you're running the right juju binary? (perhaps put a logger.Infof in localEnviron.Bootstrap to make sure) [16:40] natefinch: in the code i see, it calls ensureNotRoot to make sure that you are not running as root [16:40] rogpeppe: ahh, no, there's a juju in /bin/juju somehow [16:40] natefinch: right [16:40] rogpeppe: I don't know how that got there [16:41] natefinch: when was it created? [16:41] natefinch: hmm, /bin, not /usr/bin ? [16:41] rogpeppe: yeah, just /bin/juju .... created Dec 5th [16:42] natefinch: weird. [16:42] yep [16:42] natefinch: well, remove it :-) [16:43] wtf? Why is bash still trying to run juju from /bin/juju if which juju returns $GOPATH/bin/juju? [16:45] natefinch: run hash -r [16:45] natefinch: it's an ancient (and fucked up) shell misfeature [16:45] rogpeppe: yeah, I just made a new terminal and it's fine [16:45] natefinch: and the source of endless wtfs in the past [16:46] natefinch: it's a premature optimisation [16:46] man, that is dumb [16:46] rogpeppe: I mean, I get it, but.... yeah [16:47] natefinch: blame csh back in the 80s [16:47] rog ERROR juju.cmd supercommand.go:294 Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused [16:49] natefinch: you're best deleting any existing stuff. rm -r ~/.juju/environments/local.jenv ~/.juju/local [16:49] natefinch: that behaviour will get better, hopefully [16:49] natefinch: axw has a CL waiting [16:50] rogpeppe: and finally... it seems to work fine [16:50] rogpeppe: juju status that is .... er, agent state is down, hmm [16:50] natefinch: juju status works ok, not running as root? [16:51] rogpeppe: I was too quick for it, now it's up. Yes, not running as root [16:51] natefinch: i get this: ERROR failed getting all instances: error executing "lxc-ls": lxc: Permission denied - opendir on lxcpath; Traceback (most recent call last):; File "/usr/bin/lxc-ls", line 200, in ; for container_name in lxc.list_containers(config_path=lxcpath):; File "/usr/lib/python3/dist-packages/lxc/__init__.py", line 390, in list_containers; config_path=config_path); ValueError: failure to list containers [16:52] rogpeppe: what happens if you just run lxc-ls? [16:52] natefinch: yeah, just tried that - that fails too [16:52] rogpeppe: that works for me (well, returns with no output, since I have no containers yet) [16:53] natefinch: it would be wonderful if it actually printed the path in question :-) [16:54] rogpeppe: that's one of the things I like best about go... all those type of errors actually include the path [16:56] natefinch: ah, i guess i've found the reason [16:56] natefinch: /var/lib/lxc is mode 700 [16:57] rogpeppe: uhh.... that does seem like a problem :) [16:57] natefinch: and... now it works [16:57] natefinch: i wonder how that happened [16:58] rogpeppe: actually, mine is also 700 [16:58] natefinch: oh, maybe i shouldn't have chmodded mine then [16:58] sigh [17:02] WTFs/minute is running rather high currently === Guest92118 is now known as Makyo === manu is now known as seelaman [18:47] rogpeppe: got a second? I have a question about the simpleworker that you wrote... [18:47] natefinch: sure [18:47] * rogpeppe tries to remember what "simpleworker" was [18:47] rogpeppe: I can pastbin [18:47] natefinch: please [18:48] rogpeppe: http://pastebin.ubuntu.com/6868675/ [18:49] natefinch: ah yes, i remember now [18:49] natefinch: it is perhaps a little over-simplistic [18:49] natefinch: it might need to cache the error, for example [18:50] rogpeppe: the kill function, as written, doesn't compile, but I'm not clear on what is supposed to be there [18:50] natefinch: close(w.stopc) [18:51] rogpeppe: ok... I was trying to follow it, but it was all a little too self-referential and relying on the behavior of outside stuff that I didn't understand [18:52] natefinch: it's just a way of writing a lightweight worker without making a new type [18:52] natefinch: i should probably have written some comments :-) [18:54] rogpeppe: heh... [18:58] natefinch: this is probably a little better: http://play.golang.org/p/zGQUsdR5Yy [18:59] natefinch: (it makes both Wait and Kill idempotent) [19:05] rogpeppe: so in that code, the fact that done is a channel doesn't really matter, right? Since nothing is ever sent on it, it just makes Wait() block until done is closed [19:05] natefinch: that's right [19:06] natefinch: it's a fairly idiomatic use of a chan struct{} [19:08] rogpeppe: yeah. I [19:09] rogpeppe: I'm a little confused, because stopc is never used [19:09] rogpeppe: I mean, we send it to the function, but we don't send or receive on it ourselves [19:09] natefinch: that's the point [19:09] natefinch: the function can use it to find out when it's being stopped [19:10] rogpeppe: oh, I see, I missed that we're still closing it. ok [19:10] natefinch: and ISTR that the code i pasted to did [19:11] s/pasted to did/pasted did that/ [19:13] rogpeppe: yeah.... ok. It's making more sense now. your new code is a little easier for me to follow [19:13] natefinch: the comments help, right? [19:13] natefinch: (the code is actually more complex than it was before) [19:15] rogpeppe: I think it was mostly the w.done <- start(w.stopc) line of the old code that was confusing me... calling a function passed into this function in a goroutine, passing it a channel and sending what that function returns into another channel.... [19:16] rogpeppe: cognitively dense [19:17] rogpeppe: knowing that I can just ignore the channels except as signaling devices also helped [19:17] natefinch: good thing we're not using haskell :-) [19:17] rogpeppe: I'd be working somewhere else if we did :) [19:23] * rogpeppe finishes for the day [19:23] natefinch: g'night [19:24] rogpeppe: g'night. Thanks for the help. === adam_g` is now known as adam_g === BradCrittenden is now known as bac === _mup__ is now known as _mup_ === dspiteri is now known as DarrenS === 21WACCDQH is now known as bigjools === 5EXAAH0BV is now known as bradm