=== robbiew is now known as robbiew_ [14:04] ion: vague zany idea, remove some of the need for stanzas in the job format [14:04] e.g. instead of [14:04] env FOO="some value" [14:04] just have [14:04] FOO="some value" [14:04] could introduce some nice features that way [14:04] while apache [14:05] every hour [14:05] exec log-rotate [14:05] restart apache [14:05] -- [14:05] where "restart" is exactly equivalent to [14:05] script [14:05] exec log-rotate [14:05] restart apache [14:05] end script [14:05] type things [14:05] except obviously without the exec there :p [14:05] Sounds good [14:06] then I was thinking that things like "on" could bind to whatever follows [14:06] while apache [14:06] [14:06] every hour [14:06] exec log-rotate [14:06] [14:06] every day [14:06] exec log-rotate --force [14:06] [14:06] on omg-the-world-is-over [14:07] restart apache [14:07] 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] should be ok.... [14:07] sadmac: it was reading your parser code that made me think about it [14:07] Keybuk: ah, cool [14:08] as can be more flexible [14:09] I've been working on nih_parse_tool, which will work like yacc and turn a DSL into a C code parser [14:10] Nice [14:10] 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] and it'll get rid of the need to specify charsets manually, which normally requires a calculator and causes anneurisms. [14:16] so nobody hates the idea that on would bind like that? [14:16] Keybuk: I wouldn't mind playing with it [14:17] As long as how other things such as env, instance etc. are clearly defined. [14:17] 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] sadmac: 0.6 doesn't support bare "on" - so it should be fine [14:19] 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] Keybuk: this way we might need two separate parsers. [14:19] Keybuk: oh, I see what you're saying though... yeah could be. [14:20] ie. using "on", "every", "at" type keywords, everything after that is strict 1.0 grammar [14:20] but up until then, you can get away with some older grammar [14:22] so it'd be jobfile = stanzas06* stanzas10* [14:22] right [14:22] 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] since the point of the compatibility is to make sure existing jobs work [14:23] jobfile = stanzas06* EOF | stanzas10* EOF [14:23] right [14:24] the only really ambiguous bit is the double stanzas crap [14:24] a file containing just: [14:24] 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] exec foo [14:24] exec bar [14:24] 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] that works too. [14:26] parse errors can even be tagged "but might work on 0.6" [14:26] e.g. [14:26] the second exec there would be a parse error tagged "but try 0.6" [14:28] that's the last thing I'll need to go back and do is the error reporting [15:49] 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] entirely possibly [15:50] first I want to figure out what they mean [15:50] I still don't know where the whole M{oblin,aemo,eego} thing is going [16:07] 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] ... 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] http://upstart.ubuntu.com/wiki/Resources [16:08] written in 1882 or something [16:08] Ah, i didn’t even remember about that one. [16:10] 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] So ‘contends-io sda sdb; contends-cpu sda sdb’ would do both IO and niceness priorization. [16:11] makes sense [17:23] 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] the code is still ick [17:24] I don't like giant macros like that [17:25] you're from North Carolina [17:25] we have to assume that, at some point over the next couple of years, you are going to get murderer [17:25] or at least shot [17:25] so it has to be maintainable once you're gone :p [17:25] Keybuk: I get murderer and murderer every day. [17:26] 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] that would be yay [17:32] 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. === rberger_ is now known as rberger === rberger_ is now known as rberger === rberger_ is now known as rberger [22:13] 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] 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] the channel says Upstart 0.6.5 "Our last, best hope for victory" ... should I try this version? is it dangerous? [22:19] 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] any ideas? [22:28] Can I replace upstart with the old init package? [22:35] anybody? [22:46] NoReflex: I don't think you can. [22:46] Most of the core init scripts (rcS stage) have been converted to upstart-only [22:48] I don't see, why starting sysv init scripts for runlevel 2 should be a problem. [22:48] do you have a bug report maybe?