[04:30] <nokia3510> hello
[04:31] <nokia3510> I'm having a luks issue and I don't know for sure if it's upstart related or not, maybe you could confirm my hunch
[04:33] <nokia3510> I'm testing luks in Vbox-Karmic, fstab and crypttab are setup properly, manual mount works just fine
[04:34] <nokia3510> however, when booting karmic, the boot process stops for a moment asking for luks password, yet it continues before I finish typing the pass and pressing enter, leaving the luks hdd unmounted
[04:36] <nokia3510> i've done similar tests in mandriva, opensuse and fedora - for learning purposes - discovered a few distro specific quirks but finally all's setup properly
[04:37] <nokia3510> in karmic however, I dunno now where's the problem really, since it reaches the pass entering state but automatically continues after a few seconds regardless of my input
[04:59] <sadmac2> nokia3510: that's an ubuntu question not an upstart question. even if upstart is involved the problem is specific to their configuration of upstart.
[05:00] <nokia3510> thanks sadmac2 for clarifying it for me
[05:00] <sadmac2> nokia3510: I'd try #ubuntu if you can, or the appropriate bug tracker
[05:01] <nokia3510>  the #ubuntu is full of "halp...my win7 has an ubuntu issue"
[05:01] <nokia3510> I use fedora on daily basis but never had much to do with upstart
[05:02] <nokia3510> also I'm more at leisure with fedora's cli, not debian
[05:03] <nokia3510> but thanks anyway, I'll find some way to digg more info about upstart configs in karmic
[06:42] <tauren> it seems that there is no value for $USER when processes in a user crontab file run. is that correct?
[06:42] <tauren> oops, wrong window. sorry.
[14:22] <edgecase1> Keybuk, hey what about upstart knowing state of system before it's started... ie netbooting leaves NIC configured when starting /sbin/init?
[14:22] <Keybuk> what about it? :)
[14:23] <edgecase1> does it do that now, or any plans to...
[14:23] <edgecase1> i see 2 options... pass the info to upstart, or probe the system to figure it out
[14:25] <edgecase1> i think one of the blueprints is talking about that
[14:25] <Keybuk> Upstart doesn't know anything about NICs ...
[14:25] <Keybuk> so why would it need to know about their state
[14:25] <edgecase1> that's just one use-case for the functionality of knowing system state
[14:25] <Keybuk> what other kind of system state?
[14:25] <Keybuk> all Upstart knows about is pids
[14:26] <edgecase1> the ifup/ifdown scripts know about NIC state
[14:26] <edgecase1> well vaguely i thought that nic state might be equal to started/starting state of the network.conf or similar jobs
[14:28] <edgecase1> ok I think i'll assume probing method, until i'm thinking clearly about it
[14:54] <Keybuk> it's definitely something to think about
[14:54] <Keybuk> transfer of state from initramfs
[14:54] <Keybuk> we have a sneaky hacky patch in ubuntu
[14:54] <Keybuk> for each file /dev/.initramfs/*.pid, if there is an equivalent /etc/init/*.conf then Upstart marks the job as running with the pid in the pid file
[15:10] <wasabi> hi edgecase1
[15:11] <wasabi> Keybuk, you have an infrastructure for inplace upgrades of upstart, right? :)
[15:12] <wasabi> Sounds dangerous, but use that to exchange state.
[15:12] <Keybuk> no
[15:12] <Keybuk> but that's one of the ideas
[15:12] <wasabi> Hmm. Thought there was a way to dump the state out of it and have it exec a new version of itself.
[15:12] <wasabi> Or something.
[15:12] <Keybuk> hasn't been for ages
[15:13] <Keybuk> it's hard to maintain it while redeveloping upstart
[15:13] <wasabi> I haven't paid attention for ages. =(
[15:19] <sadmac> Keybuk: wrt dumping object state, I had thoughts to implement an nih-json on top of nih-parse when it was done, and then produce a complimentary nih-serialize
[15:20] <Keybuk> json was my idea too
[15:20] <Keybuk> it's a nice format
[15:20] <Keybuk> you can read it quickly
[15:20] <Keybuk> you can debug it
[15:20] <Keybuk> etc.
[15:20] <sadmac> indeed
[15:21] <sadmac> nih-serialize is still a very rough idea I'm having. not sure what I would want it to be.
[15:22] <Keybuk> I'd vaguely thought as well that root should be able to get a dump of all init state this way
[15:22] <Keybuk> e.g. why a job hasn't started => get the json of the state to see
[15:24] <sadmac> Keybuk: I'd hope that'd be a last-resort measure. There should be more straightforward presentations of that information for hyoomans
[15:24] <sadmac> or at least most of them
[15:25] <Keybuk> a client could interpret that
[15:25] <Keybuk> ie. initctl
[15:25] <sadmac> I'd see a json state dump as being one step before a core dump in your debugging tool box
[15:25] <Keybuk> it just seemed like a nice way to transfer data
[15:25] <sadmac> ah
[15:25] <Keybuk> right
[15:25] <sadmac> yeah I could see that
[15:27] <sadmac> Keybuk: my only worry would be app writers would forego the much saner dbus ways of getting (some of) that information and start trying to do everything that way.
[15:28] <Keybuk> yeah that's true
[15:29] <sadmac> python programers lurve them some json
[15:31] <Keybuk> which is ironic really
[15:33] <sadmac> I'm a ruby programmer, so I lurve me some YAML. But its context-sensitive, so there's no fucking way I'm writing a parser for it.
[15:41] <edgecase1> wasabiiiiiiiiiII!
[15:51] <sadmac> Keybuk: a blog commenter suggested we use augeas to do config parsing
[15:51] <sadmac> just thought I'd mention it
[15:54] <Keybuk> what's that?
[15:54] <edgecase1> how many MB of unaudited code would that add :P
[15:55] <sadmac> Keybuk: its a general-purpose config file parser/editor tool. Its designed to give you a safe api to do things like update grub.conf. He's suggesting we use it to parse our own config files, with the added benefit that other tools can introspect our config files via the same grammar definition.
[15:55] <sadmac> Keybuk: its intriguing. edgecase1 has a big point though. Its kinda big afaict
[15:56] <notting> is the commenter dlutter himself?
[15:56] <sadmac> notting: I think it was. I remember he said "shameless plug" at the start
[15:56] <sadmac> notting: yep. it was.
[15:56] <Keybuk> sadmac: ask him what his test suite code coverage is :p
[15:59] <sadmac> Keybuk: done.
[16:05] <edgecase1> what's librt used for?
[16:05] <edgecase1> just async io?
[16:05] <Keybuk> sadmac: also, obviously, what his approach to NULL returns from malloc and realloc are :p
[16:07] <sadmac> Keybuk: if we seriously think its a good idea we could audit his code.
[16:10] <sadmac> Keybuk: the lenses themselves appear to have a builtin testing framework
[16:11] <Keybuk> without looking, I can't tell
[16:12] <edgecase1> what about an external utility to parse, that just connects like initctl cmd does, to feed in the objects
[16:12] <edgecase1> keep /sbin/init small
[16:12] <edgecase1> it links libc, librt, libdbus, libpthread now
[16:12] <edgecase1> is librt needed?
[16:13] <sadmac> why is it linking libpthread?
[16:13] <sadmac> librt might come with glibc in some cases
[16:13] <Keybuk> cause librt does
[16:14] <Keybuk> and I think libdbus does
[16:14] <sadmac> Keybuk: augeas.net
[16:14] <sadmac> if you want to look into that more
[16:15]  * sadmac can't really be the one to decide that he just wrote a parser for no good reason
[16:19] <ion> Erlang has an incredibly good facility for runtime upgrades of everything. It sort of depends on all the state being on the stack, though.
[16:20] <Keybuk> sadmac: will look in a bit
[16:20] <edgecase1> the trick is changing the in-core format on upgrade
[16:20] <Keybuk> currently debugging a plymouth issue that causes our beta installer to crash X :)
[17:03] <edgecase1> is anyone working on updating bridge and vlan networking to use upstart?
[17:04] <sadmac> edgecase1: in which distro? :)
[17:04] <edgecase1> ubuntu... but if any distro is, that'd be useful
[17:04] <sadmac> edgecase1: from fedora's side I'm pretty sure init is going to get out of that business altogether and let network manager take it over
[17:04] <edgecase1> for servers too?
[17:05] <sadmac> edgecase1: yep
[17:05] <sadmac> edgecase1: network manager is growing a command line in F13
[17:05] <edgecase1> ic
[17:06]  * sadmac needs to play with nmcli a little
[17:06] <edgecase1> i wonder what the target audience is... i suspect it will have a smaller scope than "anything linux networking can do"
[17:07] <edgecase1> nmcli might end up as clone of cisco, or quagga
[17:07] <sadmac> edgecase1: maybe at the moment. The idea is that it should replace everything you ever loved though.
[17:07] <edgecase1> maybe the networking "power-users" will just use bash scripts and be forced to rip out network-manager
[17:08] <edgecase1> running a BGP router makes me skeptical of things, i'll admit to bias
[17:11] <edgecase1> is network manager sending events to upstart already?
[17:13] <sadmac> edgecase1: no. that will come too. mostly to replace the old "dispatcher" stuff
[17:14] <edgecase1> i wonder if the economics are what keeps the advanced networking out of "nice" tools like network-manager... there are too few BGP routers vs webservers vs laptops to get developer interest
[17:15] <edgecase1> might be worth some thought about how quagga could leverage what NM does well
[17:15] <sadmac> edgecase1: the laptops needed it most. they got their features first./
[17:15] <sadmac> edgecase1: but its all coming
[17:15] <edgecase1> exactly
[17:15] <edgecase1> BGP routers are like Waiting for Gaudot though
[17:16] <sadmac> edgecase1: that's why fedora does things like rip out all the old bash scripts (not that we're doing that yet). sure its a pain in the ass and people will flame and things will break. But that's what will make it work :)
[17:16] <edgecase1> reasonable compromise might be to fine some mutual agreement so NM doesn't trample quagga and vice-versa
[17:17] <edgecase1> netlink is pretty good for sharing network stuff
[17:18] <edgecase1> only conflict is if 2 daemons want to set the IP addrs of the same interface
[17:18] <edgecase1> there is no arbiter saying NM or quagga or bash scripts "own" a certain interface
[17:19] <edgecase1> i immagine there's #network-manager for that discussion?
[17:20] <sadmac> edgecase1: I'm guessing
[17:20] <sadmac> edgecase1: You should talk to Dan Williams about this stuff
[17:21] <edgecase1> he at ubuntu or redhat or ?
[17:21] <sadmac> edgecase1: red hat
[17:21] <sadmac> edgecase1: he's upstream for network manager though
[17:21] <edgecase1> how can i reach him?
[17:22] <edgecase1> upstream, what's the significance of that?
[17:22] <edgecase1> distro agnostic?
[17:22] <Keybuk> ostensibly
[17:22] <Keybuk> when RH people say "upstream", they're either
[17:23] <Keybuk>  - complaining that Ubuntu didn't use RH's code
[17:23] <sadmac> edgecase1: dcbw
[17:23] <Keybuk>  - pretending that Fedora's packages maintained by RH developers aren't "authorative" :p
[17:23] <Keybuk>  - avoiding "patches welcome"

[17:23] <sadmac> edgecase1: dcbw on freenode
[17:23] <sadmac> edgecase1: but dunno if he's on
[17:24] <edgecase1> i'll check out #nm
[17:24] <sadmac> Keybuk: just because you guys are trying to make a proprietary linux by making nobody /want/ your patches....
[17:25] <Keybuk> sadmac: says the guys writing GNOME Shell ;-)
[17:26] <notting> dcbw works on the networking stack. makes 100% IRC availability tricky
[17:26] <edgecase1> physician heal thyself!
[17:27] <sadmac> Keybuk: that's going to be part of gnome 3.
[17:27] <Keybuk> sadmac: uh-huh :p
[17:27] <Keybuk> which is released when? :p
[17:27] <Keybuk> wasn't that supposed to be last week? :p
[17:27] <notting> no, that was upstart 1.0! (we all can play this game... ;) )
[17:28] <Keybuk> edgecase1: this is just inter-distro banter ;p  we like each other really
[17:28] <Keybuk> we all agree to hate Mandriva
[17:29] <sadmac> Keybuk: this is why I love that we /use/ upstart. Its the giant logical fallacy in your argument. Or maybe the fact that you take our patches is the giant logical fallacy in our argument. The point I'm trying to make is I have a giant logical phallus.
[17:29] <edgecase1> heh
[17:29] <Keybuk> sadmac: :D
[17:30] <Keybuk> if it wasn't for Fedora, we'd have to actually write our own code :-/
[17:30] <sadmac> and now its waaay past lunch time and I haven't found anyone to eat with. To the lonely food!
[17:31] <Keybuk> talking of which
[17:31]  * Keybuk goes back to debugging broken Fedora code
[17:31] <Keybuk> yay plymouth! :D
[18:03] <Keybuk> oh arse
[18:03] <Keybuk> see, I go and sarcastically accuse plymouth of being crap
[18:03] <Keybuk> but it turns out that the bug is actually in upstart!
[18:25] <notting> sadmac: did you ever make progress on the display manager starting weirdness?
[18:43] <sadmac> notting: which weirdness?
[18:45] <notting> where we were trying to have both generic and specific events, and have the specific one  1) start when the generic one is called with an argument 2) call 'stop <generic>' in its post-start
[18:45] <notting> it wasn't working 
[18:45] <sadmac> notting: oh yeah. the way I said to do it should have worked I believe. Keybuk suggested the bug may have already been filed.
[18:46] <Keybuk> I liked what halfline said
[18:46] <Keybuk> have a display manager task
[18:46] <Keybuk> gdm, kdm, etc. start on starting display-manager
[18:46] <Keybuk> check if they want to run, and if they do, stop display-manager so that fallback doesn't
[18:47] <notting> yeah. didn't work.
[18:47] <sadmac> Keybuk: right, that's what we were doing. We did the latter "if they do" part by putting stop display-manager in the post-start of gdm/kdm/etc
[18:47] <Keybuk> it didn't work?
[18:47] <sadmac> Keybuk: iirc display-manager remained running and the service killed itself
[18:47] <Keybuk> that's odd
[18:47] <Keybuk> it should work
[18:48] <Keybuk> we do tricks likat
[18:48] <Keybuk> like that
[18:48] <Keybuk> that's how our installer works, for example
[18:48] <sadmac> Keybuk: I mentioned it to you I think, and you said there was a filed bug from ubuntu, though I don't know if we were totally clear on what was happening.
[18:48] <notting> Keybuk: mail bounced.
[18:49] <sadmac> and I get all the launchpad mail, so I would have seen it I'd think
[18:50] <Keybuk> oh
[18:50] <Keybuk> bar.conf shouldn't be "task" no?
[18:51] <Keybuk> shouldn't make much difference tho
[18:51] <sadmac> notting: was it?
[18:52] <notting> i don't think that made a difference... it was just that way as it made testing it much simpler if it didn't respawn all the time
[18:52] <notting> but i can dig up a test rig and try again
[18:53] <halfline> for reference, previous discussion about this is here: http://rstrode.fedorapeople.org/quest_to_find_a_dm.txt
[18:54] <Keybuk> http://pastebin.ubuntu.com/396866/
[18:54] <notting> this also, for all i know, could have been fixed somewhere between 0.6.3 and 0.6.5
[18:54] <Keybuk> Mar 17 18:53:47 quest init: bar post-start process (30448) terminated with status 1
[18:55] <Keybuk> NO SUCH INSTANCE innit
[18:55] <sadmac> oh. that could explain it.
[18:55] <sadmac> why isn't it finding er then?
[18:55] <Keybuk> I think
[18:56] <Keybuk> hmm
[18:56] <notting> foo hasn't started enough yet for there to be something to stop?
[18:56] <Keybuk> shouldn't be, goal should still be same
[18:56] <sadmac> no it should still find the instance...
[18:56] <Keybuk> quest scott% cat /tmp/bar-ps.30475
[18:56] <Keybuk> initctl: invalid option: --no-wait
[18:56] <Keybuk> Try `initctl --help' for more information.
[18:57] <notting> ok, *that's* a 0.6.3 vs 0.6.5 difference :)
[18:57] <Keybuk> Mar 17 18:57:29 quest init: Connection from private client
[18:57] <Keybuk> Mar 17 18:57:30 quest init: foo goal changed from start to stop
[18:57] <Keybuk> no
[18:57] <Keybuk> --no-wait has to come after stop
[18:57] <Keybuk> initctl stop --no-wait foo
[18:57] <Keybuk> that's your bug
[18:58] <sadmac> wow. that was silly
[18:58] <notting> seriously? it's positional?
[18:58] <Keybuk> it follows the same convention as svn, git, etc.
[18:58] <Keybuk> initctl <global options> command <command or global options> ...
[18:58] <halfline> can't you just run "stop" instead of "initctl stop" ?
[18:58] <Keybuk> halfline: yes ;)
[18:59] <notting> i always wondered whether some other package shoved a start/stop command in $PATH, though. meh.
[18:59] <notting> can always pass the full path
[18:59] <Keybuk> plus Upstart always runs in sane PATH anyway
[18:59] <Keybuk> admittedly, /sbin is near the end
[19:00] <sadmac> notting: I wanted to recommend a patch also to unset UPSTART_JOB at the top of /etc/rc . If its set anything in the init scripts that runs "start" or "stop" without arguments will derail the whole runlevel transition. The oVirt guys managed to do this with a typo just the other day. Probably safer to make it go away.
[19:00]  * Keybuk goes back to fixing the upstart-takes-a-chainsaw-to-plymouth's-vt bug that's blocking Ubuntu β1 ;-)
[19:01] <Keybuk> surprised you guys haven't noticed that one yet <g>
[19:01] <Keybuk> maybe you have
[19:01] <Keybuk> maybe *that's* why plymouth sets the console to unbuffered mode before every write ;-)
[19:02] <sadmac> Keybuk: I've got one now where using the serial console makes us kernel panic. plautrba has an upstart patch that fixes it, but nhorman came back and said "wait, I don't know if upstart is where we should fix that one..."
[19:02] <Keybuk> what's the patch?
[19:04] <halfline> yea plymouth puts it back in unbuffered more for every write because for i did that there were cases where it'd get thrown back into cooked mode
[19:04] <halfline> i don't remember the details, that change went in a long time ago
[19:04] <Keybuk> halfline: like when you're starting X
[19:04] <sadmac> Keybuk: https://bugzilla.redhat.com/attachment.cgi?id=399621
[19:04] <Keybuk> and doing a transition
[19:04] <sadmac> doesn't look right to me
[19:04] <Keybuk> and it's very interesting
[19:04] <sadmac> oh, I don't know if you can even see that
[19:04] <halfline> Keybuk: nah, remember we quit plymouth before X starts right now
[19:04] <Keybuk> what happens when X has its VT changed back into raw mode
[19:04] <Keybuk> Enter looks a bit like C-\ <char>
[19:04] <Keybuk> it's amazing what C-\ does to X ;-)
[19:05] <Keybuk> halfline: :D
[19:05] <Keybuk> sadmac: You are not authorized to access bug #568418.
[19:05] <halfline> really? that's bizarre
[19:05] <sadmac> Keybuk: that makes sense. lemme pastebin that...
[19:05] <Keybuk> halfline: we took out the set_unbuffered a while back
[19:05] <Keybuk> but just had another occurance of a similar bug
[19:06] <Keybuk> plymouth sets console to uncooked
[19:06] <Keybuk> upstart resets it cooked
[19:06] <Keybuk> X resets it to uncooked
[19:06] <sadmac> notting: also why does plautrba have upstart in a git repo? I hate bzr too, but... come on.
[19:06] <Keybuk> plymouth resets it to cooked on its way out
[19:06] <notting> sadmac: i dunno
[19:06] <Keybuk> X dies when you press Enter ;-)
[19:06] <sadmac> Keybuk: http://pastebin.com/zu4n14gG
[19:06] <halfline> dies with SIGQUIT ?
[19:06] <sadmac> Keybuk: looks like he fixed it the way debian fixed those SSL warnings awhile back :)
[19:07] <Keybuk> halfline: yup
[19:07] <Keybuk> sadmac: no idea why that would avoid a panic
[19:07] <halfline> i wonder if plymouth's "put back in cooked mode" code is wrong...
[19:08] <Keybuk> sadmac: that's removing the code that guards against SysRq-K from killing upstart
[19:08] <Keybuk> halfline: no, it isn't - it's just inconveniently timed
[19:08] <halfline> it's hard for me to bridge "in cooked mode" to "enter sends sigquit"
[19:08] <Keybuk> well sorry
[19:08] <Keybuk> there is a small plymouth bug
[19:11] <Keybuk> but yeah, apparently enter and sigquit look very similar to X
[19:13] <halfline> hmm looking at the tcsetattr man page
[19:14] <halfline> it appears  picked my terminal settngs
[19:14] <halfline> by taking the cfmakeraw settings and invertng them
[19:14] <halfline> this was probably not the wisest move
[19:14] <Keybuk> heh
[19:15] <halfline> time to switch it to use the values from stty 's sane mode
[19:16]  * Keybuk is trying to remember why upstart sets terminal settings in the first place
[19:17] <sadmac> Keybuk: I remember a bug when we first used upstart where I think the gettys were set uncooked, and you couldn't actually hit enter to punch in your username
[19:17] <sadmac> forget what made that go away
[19:18] <sadmac> notting: do you have a quick reproduction environment for 568418?
[19:19]  * Keybuk afk for about an hour, will read scrollback
[19:21] <sadmac> notting: if not any tips on testing serial+kvm?
[19:36] <notting> sadmac: haven't seen it, but haven't tried to reproduce
[19:36] <notting> serial + kvm is a PITA
[19:37] <notting> dig up the magic qemu flags and start it by hand
[19:39] <halfline> virt-manager has a serial console display... isn't addng console=ttyS0 enough?
[19:39] <halfline> on kernel cmdline i mean
[19:45] <notting> halfline: i'm told due to perms it doesn't actually work in virt-manager yet
[19:51] <halfline> ah
[19:52] <halfline> i had some fun with virt manager permissions the other day.  i had to vim /usr/lib*/python*/site-packages/something-or-other and add a fchmod call to get to create a vm
[20:08] <sadmac> halfline: my option to switch to serial console is greyed out in the menu. guess that's the solution
[20:14] <notting> cole said it theoretically works if you run virt-manager as root. 
[20:16] <sadmac> hmm. might try that