[14:04] <Keybuk> ion: vague zany idea, remove some of the need for stanzas in the job format
[14:04] <Keybuk> e.g. instead of
[14:04] <Keybuk>     env FOO="some value"
[14:04] <Keybuk> just have
[14:04] <Keybuk>     FOO="some value"
[14:04] <Keybuk> could introduce some nice features that way
[14:04] <Keybuk> while apache
[14:05] <Keybuk> every hour
[14:05] <Keybuk> exec log-rotate
[14:05] <Keybuk> restart apache
[14:05] <Keybuk> -- 
[14:05] <Keybuk> where "restart" is exactly equivalent to
[14:05] <Keybuk>   script
[14:05] <Keybuk>     exec log-rotate
[14:05] <Keybuk>     restart apache
[14:05] <Keybuk>   end script
[14:05] <Keybuk> type things
[14:05] <Keybuk> except obviously without the exec there :p
[14:05] <ion> Sounds good
[14:06] <Keybuk> then I was thinking that things like "on" could bind to whatever follows
[14:06] <Keybuk>    while apache
[14:06] <Keybuk>  
[14:06] <Keybuk>     every hour
[14:06] <Keybuk>     exec log-rotate
[14:06] <Keybuk>  
[14:06] <Keybuk>     every day
[14:06] <Keybuk>     exec log-rotate --force
[14:06] <Keybuk>  
[14:06] <Keybuk>     on omg-the-world-is-over
[14:07] <Keybuk>     restart apache
[14:07] <Keybuk> which is kinda cute for sub-jobs without needing a block
[14:07]  * sadmac considers whether he has to do anything nasty to his parser now
[14:07] <sadmac> should be ok....
[14:07] <Keybuk> sadmac: it was reading your parser code that made me think about it
[14:07] <sadmac> Keybuk: ah, cool
[14:08] <Keybuk> as can be more flexible
[14:09] <sadmac> I've been working on nih_parse_tool, which will work like yacc and turn a DSL into a C code parser
[14:10] <ion> Nice
[14:10] <sadmac> starting to appreciate how much of a pain actually processing these parse trees can be, but I think the parse tool will make it pretty straightforward
[14:11] <sadmac> and it'll get rid of the need to specify charsets manually, which normally requires a calculator and causes anneurisms.
[14:16] <Keybuk> so nobody hates the idea that on would bind like that?
[14:16] <sadmac> Keybuk: I wouldn't mind playing with it
[14:17] <ion> As long as how other things such as env, instance etc. are clearly defined.
[14:17] <sadmac> Keybuk: it may mean that the next job format isn't a strict superset of 0.6, which means more acrobatics to do that backward compatibility thing you promised
[14:18] <Keybuk> sadmac: 0.6 doesn't support bare "on" - so it should be fine
[14:19] <sadmac> Keybuk: right, but as of now we can only have one job format and get away with everything. We just neglect to remove start on/stop on and the 0.6 grammar is a subset of the 1.0 grammar.
[14:19] <sadmac> Keybuk: this way we might need two separate parsers.
[14:19] <sadmac> Keybuk: oh, I see what you're saying though... yeah could be.
[14:20] <Keybuk> ie. using "on", "every", "at" type keywords, everything after that is strict 1.0 grammar
[14:20] <Keybuk> but up until then, you can get away with some older grammar
[14:22] <sadmac> so it'd be jobfile = stanzas06* stanzas10*
[14:22] <Keybuk> right
[14:22] <Keybuk> tbh, we can even get away with "as soon as you put any 1.0 format thing in there, then the entire file must be 1.0 not 0.6"
[14:23] <Keybuk> since the point of the compatibility is to make sure existing jobs work
[14:23] <sadmac> jobfile = stanzas06* EOF | stanzas10* EOF
[14:23] <Keybuk> right
[14:24] <Keybuk> the only really ambiguous bit is the double stanzas crap
[14:24] <Keybuk> a file containing just:
[14:24] <sadmac> ugh. that ends up being kinda slow because we parse as much of the file as we can as 0.6, until we find a 1.0 thing. then we start over
[14:24] <Keybuk>   exec foo
[14:24] <Keybuk>   exec bar
[14:24] <Keybuk> I'd do it the other way - parse as 1.0 until we fail, then go back and see if it parses as 0.6
[14:24] <sadmac> that works too.
[14:26] <Keybuk> parse errors can even be tagged "but might work on 0.6"
[14:26] <Keybuk> e.g.
[14:26] <Keybuk> the second exec there would be a parse error tagged "but try 0.6"
[14:28] <sadmac> that's the last thing I'll need to go back and do is the error reporting
[15:49] <ion> keybuk: Re: “implementing serialized startup sequence”: we talked about Upstart implementing similar priority stuff as what mountall is doing for fscks at the moment. I wonder if that would be useful for them as well?
[15:50] <Keybuk> entirely possibly
[15:50] <Keybuk> first I want to figure out what they mean
[15:50] <Keybuk> I still don't know where the whole M{oblin,aemo,eego} thing is going
[16:07] <ion> keybuk: An initial idea for the config syntax: ‘priority 1; locks sda sdb’: the job has internal exclusive locks named ‘sda’ and ‘sdb’ while running. Whenever a pending job is considered for getting to start next, consider the highest-priority ones first, the default priority being zero. ‘priority -5; contends-io sda sdb’: no actual locking, but the highest-priority one (falling back to first-come first-served) per “lock” names gets the IO ...
[16:07] <ion> ... priority at any given moment. Just like what mountall does, but with an optional priority integer. ‘contends-cpu foo bar baz’: same, but for niceness.
[16:08] <Keybuk> http://upstart.ubuntu.com/wiki/Resources
[16:08] <Keybuk> written in 1882 or something <g>
[16:08] <ion> Ah, i didn’t even remember about that one.
[16:10] <ion> As for what i wrote, the ‘locks X’, ‘contends-io Y’ and ‘contends-cpu Z’ tags should all be in their own namespaces, so foo.conf: ‘locks bla’ and bar.conf: ‘contends-io bla’ would not affect each other.
[16:11] <ion> So ‘contends-io sda sdb; contends-cpu sda sdb’ would do both IO and niceness priorization.
[16:11] <Keybuk> makes sense
[17:23] <sadmac> Keybuk: any other thoughts on nih-parse while you were looking at it? I guess its at least clean enough now that you can tell what the code does :)
[17:24] <Keybuk> the code is still ick
[17:24] <Keybuk> I don't like giant macros like that
[17:25] <Keybuk> you're from North Carolina
[17:25] <Keybuk> we have to assume that, at some point over the next couple of years, you are going to get murderer
[17:25] <Keybuk> or at least shot
[17:25] <Keybuk> so it has to be maintainable once you're gone :p
[17:25] <sadmac> Keybuk: I get murderer and murderer every day.
[17:26] <sadmac> Keybuk: I more or less agree. I know I can at least remove the per-function structs. After that some of the macros might even be able to become functions.
[17:27] <Keybuk> that would be yay
[17:32] <sadmac> Keybuk: I've spent a lot of time trying to figure out how I wrote it as easily as I did in the first place. It ran pretty much the first time.
[22:13] <NoReflex> hello! I'm having some problems with upstart in karmic server 64bit. It won't start postgresql. I tried http://superuser.com/questions/98702/how-to-make-postgresql-start-at-boot-time-in-ubuntu but it didn't work. can I remove upstart? I'm afraid to test it because the machine is at a remote location and if I mess it up I won't be able to connect to it anymore.
[22:14] <NoReflex> I can start postgresql using /etc/init.d/postgresql-8.4 manually after login. There are links in /etc/rc*.d to postgresql init script but for some reason it isn't started automatically after reboot
[22:18] <NoReflex> the channel says Upstart 0.6.5 "Our last, best hope for victory" ... should I try this version? is it dangerous?
[22:19] <NoReflex> I also searched for a logging possibility because I don't know why it won't start....and it's hard to "debug" a problem when you don't have the error message
[22:27] <NoReflex> any ideas?
[22:28] <NoReflex> Can I replace upstart with the old init package?
[22:35] <NoReflex> anybody?
[22:46] <mbiebl> NoReflex: I don't think you can.
[22:46] <mbiebl> Most of the core init scripts (rcS stage) have been converted to upstart-only
[22:48] <mbiebl> I don't see, why starting sysv init scripts for runlevel 2 should be a problem.
[22:48] <mbiebl> do you have a bug report maybe?