[12:27] yeah, it has that === j_ack_ [n=rudi@p508DA16C.dip0.t-ipconnect.de] has joined #upstart [12:31] Keybuk: I've been toying around a bit with r502 [12:31] And with minor updates to the job files it works fine. [12:32] I was just wondering, why the job files have all these "stop on shutdown|runlevel-x" stanzas [12:32] For scripts, stop is never really called, right? [12:33] well [12:33] because they're rc scripts [12:33] and sysv was never designed with running the rc6 (reboot) script while starting into rc2 [12:33] I have that so if you press Ctrl-Alt-Del while booting, it stops booting, and switches into reboot [12:33] which is roughly compatible [12:34] oh [12:34] you'll want the new job files [12:34] heh [12:35] well, i used the old ones compat job files and adapted them. [12:35] http://upstart.ubuntu.com/new-example-jobs/ [12:35] the main differences are [12:35] 1) "runlevel" is now a single event, with an argument specifying the new runlevel [12:35] 2) "shutdown" is no more [12:36] so things now just "stop on runlevel" (ie. kill the running rc script if the runlevel changes) [12:37] Cool, I'll try these ones. [12:49] they work for me [12:49] which isn't to say much [12:49] I found a pretty nasty error with logd in the process though [12:49] which is why they're console output for now [01:11] <_ion> pe011840 < Keybuk> I don't like "extensions" [01:11] <_ion> Amen to that. [01:20] ok [01:20] well [01:20] that's job_change_state () rewritten [01:21] which could be happily described as the most core function [01:21] it actually got a *lot* simpler [01:21] which I think is encouraging [01:22] <_ion> Nice. [01:35] of course, none of it *compiles* yet :p [01:35] <_ion> Naaah, having it compile isn't as important as they say. :-) [01:36] it's annoying that the tests don't compile either === j_ack [n=rudi@p508DA486.dip0.t-ipconnect.de] has joined #upstart [01:37] so I'm not sure if the changes I'm making to them are right :p [01:37] lots of things had assumptions about the state model [01:38] <_ion> Have you already implemented it as a lookup table (i think you mentioned something like that earlier), or are the state decisions still plain code? [01:41] plain code [01:41] much more efficient === int0x0c [n=ben@161.253.46.23] has joined #upstart [01:50] What is the status of Upstart on Gentoo? [01:51] Has there been any effort to write a backend for it? [01:52] it shouldn't need a "backend" ? [01:52] <_ion> He probably means a compatibility layer. [01:52] _ion, yep, thanks [01:52] wrong terminology [01:52] there's been a few efforts to write jobs that emulate the existing Gentoo init system [01:52] I haven't actually seen any completed ones yet though [01:53] hmm [01:53] alright [01:59] _ion: do you remember who was doing them? [02:00] <_ion> Sorry, nope. [02:00] <_ion> 2006-12-15 19:52:46 < steev64> as much as people are going to hate me for it (not necessarily *in here*), I am trying to get up [02:01] <_ion> start working on Gentoo [02:03] Sep 13 22:28:06 i am trying it on gentoo [02:03] Oct 04 17:12:15 Hi there. Did anybody of you try to install upstart on gentoo yet? [02:03] we should get these people together :p [02:04] <_ion> 2006-10-27 23:31:21 < phsdv> hi all, I just managed to get my gentoo system booted using upstart. === ..[topic/#upstart:Keybuk] : Upstart 0.3.2 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://upstart.ubuntu.com/wiki/UpstartOnGentoo [02:07] http://upstart.ubuntu.com/wiki/UpstartOnGentoo [02:07] :p [02:08] <_ion> :-) [02:12] I might try my hand this weekend at getting upstart going === Keybuk embarks on updating the job_change_state() test suite ... ouch [02:20] http://upstart.ubuntu.com/wiki/JobStates?action=AttachFile&do=get&target=states.png [02:20] I am *so* glad I did that ^ [02:22] <_ion> :-) [02:23] though I've added to it since then === mbiebl [n=michael@e180118088.adsl.alicedsl.de] has joined #upstart [02:31] mbiebl: re [02:36] Keybuk: yes? === wasabi_ [n=wasabi@ubuntu/member/wasabi] has joined #upstart [02:38] just hi [02:39] ah, thanks ;-) [02:40] About Md's question: [02:40] Seems as if in r502, dpkg-(old|new) files are not ignored. [02:41] uh, maybe I didn't push that yet [02:41] does nih/file.c have a nih_file_is_packaging ? [02:41] nope [02:46] ah [05:17] woo, she compiles again! === maro [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === baze [n=baze@c226184.adsl.hansenet.de] has joined #upstart === baze [n=baze@c226184.adsl.hansenet.de] has joined #upstart === phsdv [n=paul@dyn-83-156-76-96.ppp.tiscali.fr] has joined #upstart === Keybuk [n=scott@quest.netsplit.com] has joined #upstart [01:35] whee [02:02] I wasn't hallucinating last night; the test cases *do* pass [02:07] congrats! [02:28] am trying to decide whether to continue to allow "respawn COMMAND" as a shortcut for both "exec COMMAND" and "respawn" [02:29] yes. syntactical sugar is nice :-) [02:37] well, moment of truth === Keybuk starts it [02:40] http://rafb.net/p/s2LD5c17.html [02:40] sweeeeeeet; ^ new job life cycle [02:41] note that the "test" job doesn't get to start until "test2" finishes, because test2 is marked "start on starting test" [02:56] http://rafb.net/p/HtgNXP55.html [02:56] ^ example of a job that needs another running === baze [n=baze@c157038.adsl.hansenet.de] has joined #upstart [02:57] note how hal is started once dbus is running, but that when dbus is stopped, hal actually gets stopped first and dbus isn't stopped until hal is [02:57] http://rafb.net/p/eGZbr976.html [02:58] ^ and there's a counter-example of the opposite behaviour [02:58] tomcat is able to indicate that "apache needs it", so when you try and start apache, you get tomcat started *first* === giuseppe_ [n=giuseppe@213-140-11-128.fastres.net] has joined #upstart [03:10] hi, i'm building a smal linux distro for learning purpose, and i was searching for something dealing with dependencies between daemons. I see upstart has removed this feature (https://launchpad.net/upstart/+spec/remove-depends). Does anyone has suggestions? are there init implementations dealing with dependencies? [03:13] for what reason do you want dependencies? [03:13] there are (currently) four basic classes of init daemon, which all handle the problem differently: [03:13] 1) those that run scripts in order, so the order expresses "what must come first" [03:14] e.g. sysvinit [03:14] Keybuk: because i don't want to hardcode init scripts. I'm listening btw [03:14] 2) those that run everything at once, and expect the jobs to sort themselves out [03:14] e.g. launchd [03:14] 3) those that use a package-manager style dependency chain, when you start a daemon anything it "depends" on is started first (and likewise, when you stop a daemon, it's dependencies aren't stopped until afterwards) [03:15] e.g. Solaris SMF, init-NG [03:15] 4) those that use events; when you start or stop a daemon, it issues events; other daemons can be started or stopped by those events; and block the other [03:15] e.g. upstart [03:15] I assume that #1 is what you're already familar with, and #2 isn't useful [03:15] ok so basically you're telling me to read the upstart doc better :) [03:16] the upstart docs aren't that good :p [03:16] (yet) [03:16] my two usual examples are dbus/hal and apache/tomcat [03:16] hal needs dbus to be running while it is, if dbus is stopped, hal must be too [03:17] tomcat is needed by apache if installed, so apache is started, tomcat must be started first (and tomcat must not be stopped until apache is) [03:17] ok this is not possible with simple dependencies then.. you have to use events [03:17] from what i understand [03:17] in a dependency-based system you might try something like [03:17] hal depends dbus [03:17] and hal is a goal [03:17] so when you start hal, dbus is started first [03:18] the second one is more tricky in a dependency-based system because you don't want to edit the apache job description just because tomcat is installed [03:18] so you actually need something like [03:18] tomcat is-dependency-of apache [03:18] and apache is a goal [03:18] (the first being in the tomcat description) [03:18] ok very clear [03:18] thanks Keybuk [03:18] don't know whether initNG supports that [03:18] I know SMF doesn't [03:19] in a event-based system, like upstart, you instead hook the events generated by hal, dbus, apache, tomcat, etc. [03:19] so you might use something like [03:19] hal: start on starting dbus [03:19] err [03:19] sorry [03:19] hal: start on started dbus [03:19] hal: stop on stopping dbus [03:19] and for the tomcat case, it's easy [03:19] tomcat: start on starting apache [03:19] tomcat: stop on stopped apache [03:20] http://rafb.net/p/HtgNXP55.html [03:20] http://rafb.net/p/eGZbr976.html [03:20] (those two URLs given an example of both of those) [03:20] Keybuk: thank you very much i'm going to read [03:20] in theory, the event-based system requires less manual or semi-automatic configuration [03:20] you can ship job definitions that do the right thing [03:21] and you don't need to modify other jobs or goals when you install a new daemon === giuseppe_ [n=giuseppe@213-140-11-128.fastres.net] has joined #upstart === phsdv [n=paul@dyn-83-156-76-96.ppp.tiscali.fr] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === maro [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart === wasabi_ [n=wasabi@ubuntu/member/wasabi] has joined #upstart === int0x0c [n=ben@161.253.46.23] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === Seveas [n=seveas@ubuntu/member/seveas] has joined #upstart === wasabi [n=jhaltom@ubuntu/member/wasabi] has joined #upstart === Keybuk [n=scott@quest.netsplit.com] has joined #upstart === pkt [n=knoppel@85.75.153.158] has joined #upstart === AlexExtreme [n=AlexExtr@frugalware/developer/AlexExtreme] has joined #upstart === Keybuk makes yet another tweak to the state diagram === |phsdv| [n=paul@dyn-88-123-135-92.ppp.tiscali.fr] has joined #upstart === giuseppe_ [n=giuseppe@213-140-11-128.fastres.net] has joined #upstart [04:57] hi, i'm having troubles compiling upstart with gcc 3.3.5, is it a known issue? [04:58] child.c: In function `nih_child_poll': [04:58] child.c:141: error: `WEXITED' undeclared (first use in this function) [04:58] yes [04:59] upstart only compiles with 4.x afai [04:59] *afaik [04:59] :| [05:00] that's more likely an out of date libc [05:00] ah [05:00] upstart needs both kernel and libc support for the waitid() system call [05:00] yeah [05:01] i'm using debian's 2.3.2.ds1-22 [05:02] is there a particular libc version waitid() is available from? === int0x0c [n=ben@128.164.137.210] has joined #upstart [05:04] 2.4 seems fine [05:05] there's a Debian package already [05:05] http://packages.debian.org/experimental/admin/upstart [05:05] yep even 2.3.6 is ok [05:05] though it's a little out of date; if you have those build-deps, you should be fine [05:05] Have the upstart service files for the base ubuntu installation been developed yet (i.e. not the initrd wrapper) [05:06] int0x0c: they'll be available by monday [05:06] heh, wow, I picked quite a time to ask [05:06] woohoo :) [05:06] Are they in bzr at the moment? [05:07] Keybuk: yes the problem is i'm trying to maintain a cross toolchain.. :| [05:07] Keybuk, let me know when/where I can get them when they are released, I can't wait to try it :) [05:07] no; I have a bunch of them on my laptop, but they're a bit broken because I'm busy rewriting upstart :p [05:07] and keep changing things [05:08] Keybuk: i'm using this libc config: http://rafb.net/p/Kv1hho71.html, do you see problems with it? it is relative to glibc 2.3.6 [05:08] What is the bzr branch? [05:08] int0x0c: for? [05:08] the service files [05:09] giuseppe_: I don't really know libc compiles; I would imagine it's fine [05:09] int0x0c: there isn't one just yet [05:09] I'll get them published this weekend :) [05:09] bah, alright [05:09] thanks a ton [05:09] (I could publish them now, but they wouldn't work for you :p) [05:09] http://upstart.ubuntu.com/states.png [05:09] ^ now, isn't *that* neater [05:09] nice [05:10] don't you just love dot ;) [05:10] Keybuk, I'm running gentoo [05:10] Keybuk, and looking into writing a set of services [05:11] Keybuk, I just need something for reference [05:11] If you had a sec, I would love a tarball [05:11] but don't worry about it if not [05:11] as he said, they won't work right now :) [05:11] I understand that :) these just literally aren't ready right now [05:12] they're not even useful for reference [05:12] ahh, alright [05:12] fair enough === giuseppe_ [n=giuseppe@213-140-11-128.fastres.net] has joined #upstart [05:14] interesting; excluding tests, upstart 0.2.7 was 9,204 lines of code [05:14] since then (also excluding tests) [05:14] 36 files changed, 6899 insertions(+), 4654 deletions(-) [05:14] so I've changed roughly 50% of the code [05:14] that's kinda cool [05:14] yeah [05:15] test suites rock for this kind of mass-scale refactoring [05:16] a more odd stat ... [05:16] 0.3.5 has 11,360 lines of code ... but only 2,835 semi-colons [05:17] hah [05:17] I wish I could code as fast as this >< [05:18] the usual metric is 2.5 logical lines to a semi-colon [05:22] so for feisty do you reckon only the base services will be converted to upstart jobs for feisty's final release, seeing as feature freeze has started (it has, hasn't it?) ? [05:22] which makes upstart about 35% comments [05:23] hmm, just realised I said "for feisty" twice. ignore that :p [05:25] that's the plan [05:26] always has been, actually [05:26] mmm, k [05:26] most daemons will retain sysv init scripts for feisty [05:26] except the interesting ones [05:26] like dbus? [05:26] right [05:28] ok, that's config file deletion support pushed === Keybuk looks at his TODO list for what's next [06:03] I guess I should run valgrind over the new core :p [06:03] :P [06:04] shouldn't be any problems, since I didn't much around with memory stuff [06:05] all good === mbiebl [n=michael@e180066028.adsl.alicedsl.de] has joined #upstart === baze [n=baze@d031209.adsl.hansenet.de] has joined #upstart [07:00] <_ion> So you made "deleted" a state. That's good. [07:03] yeah, it made the most sense [07:03] it's the most trivial way of handling all the cases [07:04] - means it can't be started again, since it's not in the waiting state [07:04] - means that all deleted jobs can be quickly found and freed [07:04] - means that clients know that it's being deleted [07:04] etc. [07:07] <_ion> Indeed. [07:08] it even means the clients can detect when they tried to start a deleted job :p [07:08] start "foo" [07:08] foo (stop) deleted === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart [12:23] bloody ISP