=== notting_ is now known as notting === notting_ is now known as notting [21:08] Keybuk: ping [21:08] evening [21:08] evening [21:09] Keybuk: when you said you weren't planning to start working on Upstart again until "Next Year," was that the next year that starts 2 weeks from now or the one 365 days away? [21:10] 2009 [21:10] Keybuk: somewhere between the two then? [21:11] right [21:12] releasable version of 0.10 targeted for ~October next year [21:12] which pretty much aligns it with DeviceKit as well [21:12] nice [21:13] Keybuk: I think I'm going to re-prototype the state machine. I can do it in python (which you can read) or I can do it in C (which can not only be read, but serve as copy-pasta for the actual system). [21:13] being able to read it would be handy [21:14] I don't really want to have to learn ruby just so I can see what you're doing differently to me (if anything) [21:14] yes :) [21:15] ruby is fairly easy to read usually, but the state machine I wrote is kinda asshole-ish [21:15] it does scary things. [21:15] ruby is only easy to read if you know ruby ;) [21:16] plus in describing the state machine I actually ended up improving it, so it isn't quite an accurate example anyway [21:16] its a subset of what I described, but its missing some properties [21:17] (and it will actually be simpler to implement taking those ideas into account) [22:11] is anyone here versed in upstart? i am trying to migrate a inittab line to upstart and it flat out wont work. [22:23] x:23:once:/bin/su root -l -c "/bin/bash --login -c startx >/dev/null 2>&1" <- this is the exact line [22:28] geiseri: what do you have so far? [22:29] one sec, let me copy it into pastebin [22:31] http://paste.ubuntu.com/88079/ [22:31] it just seems to fail silently [22:31] is there a place to look and debug it? [22:32] geiseri: silent failure is often due to a syntax error. [22:32] geiseri: I believe it will show up in /var/log/messages [22:32] ah, okay let me check there [22:34] what should i be looking for, i cant really see anything there [22:35] does my syntax i pasted look remotely correct? [22:36] geiseri: it looks about right [22:37] geiseri: you can try init=/sbin/init -v on your kernel command line to get lots of noisy output [22:37] sure, its an embedded box, so its a bit sluggish on startup :D [22:38] heh [22:41] that is interesting, i saw the ttys startup via the screen output, but my Xorg one was not started. [22:42] do i have to set the mode on it to a specific value? [22:43] oh wait syslog as something [22:44] Keybuk: what are your plans regarding upstart 0.5.x and the next ubuntu release? [22:45] sadmac: here is the output http://paste.ubuntu.com/88088/ [22:45] it looks like it keeps starting and stopping Xorg because its exiting? [22:47] Redirect the script’s output to a log. [22:48] just do a exec /bin/su detos -l -c "/usr/bin/startx" 2>&1 >> logfile? [22:48] Seems about right. [22:48] k [22:49] The 2>&1 probably should be after the >> [23:01] okay this is strange... it cannot seem to write the log file [23:05] ah, typo :P [23:09] http://paste.ubuntu.com/88110/ <- here is the log.. .its strange its identical to when i start it up manually except for line #48 [23:09] it looks like something it killing the server before it gets out of the gate [23:10] Did you try the entire script manually, including the su invocation? [23:11] yes, it works [23:11] Try setting PATH manually in the script. [23:12] Hm. Was there a stanza for path in Upstart? [23:12] did i miss that? [23:14] i still think its strange that it starts but then exits right away... you think if it was a failed library or something it would scream. [23:17] Also try startx -- -verbose 10 -logverbose 10 [23:17] (i pulled the 10 out of my ass) [23:19] http://paste.ubuntu.com/88117/ <- okay this looks interesting... [23:20] could not get file descriptor of the console? [23:23] Try adding ‘console owner’ to the job file. [23:25] just at the top of the job file? [23:25] Yeah, at any line. [23:25] okay testing it again :) [23:26] mbiebl: I don't think I have any [23:27] Keybuk: so no further "upstartification" of init scripts for jaunty? [23:27] What bits do you consider missing, for doing so? [23:28] mbiebl: indeed [23:28] well, the fact that upstart 0.5 doesn't work? [23:28] ion_: okay this is really strange, i can startx via the console as the detos user, but i get the "X: user not authorized to run the X server, aborting." message [23:30] Keybuk: could you be more specific? [23:30] mbiebl: it doesn't solve the problems that need to be solved to move init scripts to upstart [23:30] it's still a pain in the arse to express when they should be running [23:31] and common problems are almost impossible without changes [23:31] Even if you started with a top-down approach? [23:32] I don't think services like smartd, hald etc, need a complex start dependency [23:33] i.e. rc2 could be implemented using native upstart jobs imo [23:34] hal needs to be started by d-bus activiation but only while dbus is running [23:34] (and brought up automatically) [23:36] ion_: now if i set the Xwrapper.conf to allow anyone to start X it now works... why could that be? [23:36] I have no idea. [23:36] maybe hal was a bad example. [23:36] ion_: what was the console owner line suppose to do? [23:37] mbiebl: there is a bit more that could be done with it, but why? [23:37] * geiseri wonders if he needs to run something like mingetty to get a console before X starts. [23:37] mbiebl: its all going to have to be redone again once we fix the model [23:37] sadmac: service monitoring? [23:37] seeing, which service is running? [23:37] most init scripts have a "status" option [23:38] mbiebl: its a pretty high cost to convert any large number of scripts [23:38] Keybuk: but that is a hack, imho [23:38] sure, but it works okish [23:38] I can spend my time doing useful work to make Ubuntu boot faster, and improve upstart [23:38] or I can spend it converting things to upstart now [23:38] sadmac: what would we have to change (for a service like smartd)? [23:39] do you have plans to completely change the config format? [23:39] mbiebl: yes [23:39] oh [23:39] mbiebl: the changes will make upstart semantically different. the config format won't even be expressing the same meaning [23:40] well, that depends [23:40] sadmac: is there a summary / roadmap, what the current plans are? [23:40] not yet [23:41] I'm quite surprised by what you say [23:41] mbiebl: http://screwyouenterpriseedition.blogspot.com has some (still controvertial) details on things I've been thinking about (top 4 posts) [23:41] (you get an award if you can understand his blog posts [23:41] lit. you get to explain them to the rest of us :p) [23:41] Keybuk: take a look at the most recent of those. Events shouldn't have any surprises in store, but still. [23:42] ;-) [23:42] mbiebl: the summary of the change is actually quite simple [23:42] right now jobs are: [23:42] start on [23:42] stop on [23:42] this will change to: [23:43] while [23:43] geiseri: It opens /dev/console instead of /dev/null as std{in,out,err} for the job and does a magic TIOCSCTTY ioctl (not sure if it’s needed here). :-) [23:43] a good, simple, example would be a dbus apache service [23:43] start on started dbus and started apache [23:43] stop on stopping dbus or stopping apache [23:43] vs. [23:43] while dbus and apache [23:43] except, the big difference is that if you restart apache, your service will actually be restarted [23:44] with the start on/stop on model, your service would simply be stopped [23:44] ion_: it looks like really what i need to do is edit the XWrapper.config file... its an embedded system with no ttys so it shouldnt be a problem. [23:44] hm, right, as you would be waiting for the dbus started event [23:44] exactly [23:45] so, the new mantra is "states" not events anymore [23:46] well [23:46] states are still based on events [23:46] you'll get states for jobs for free [23:46] and you can define states based off other states [23:46] or off events [23:46] you can combine them in jobs too [23:46] on control-alt-delete [23:46] while multi-user [23:47] -- [23:47] on battery-low [23:47] while docked [23:47] etc. [23:47] jobs can't be started if their while clause is not true [23:47] any roadmap for this kind stuff? [23:47] or if their while clause cannot be made to be true [23:48] the latter gives us dependency behaviour [23:48] while apache and mysql [23:48] start foo [23:48] will start apache and mysql as well [23:48] ion_: thanks for the help anyway. [23:53] Keybuk: I think for the conf file format we should use a sort of python-style syntax [23:53] foostate(arg1: %arg): [23:53] while bar [23:53] on baz [23:54] Keybuk: this means we can do the break a state across files thing, and keeping states in one file only adds 1 line to the file [23:54] Keybuk: so it pushes the decision to distro maintainers [23:56] but I don't want to break a state across files [23:56] Keybuk: /you/ don't [23:56] that's the advantage of being the author :p [23:56] Keybuk: and this doesn't hurt you much if you choose not to [23:57] it hurts compatibility between distributions [23:57] there's no such thing [23:57] there should be [23:57] brb [23:58] distributions shouldn't *need* different upstart job files for the same service [23:58] upstream authors should feel confident in shipping them in their own tarballs [23:58] but they'll have them anyway [23:59] no two distributions even install apache in the same folder [23:59] (and oh dear lord help us if anyone put it where upstream says you should) [23:59] I thought we all put it in /usr [23:59] with the config in /etc/apache2 ? :) [23:59] you'd be surprised how much commonality there actually is these days [23:59] Keybuk: its in /etc/httpd here