=== tck_ [n=tck@212.2.165.61] has joined #upstart === tck [n=tck@212.2.165.61] has joined #upstart === Amaranth_ [n=travis@ubuntu/member/Amaranth] has joined #upstart === jonib1 [n=jonas@ua-83-227-144-18.cust.bredbandsbolaget.se] has joined #upstart === juergbi [n=juerg@80-219-19-183.dclient.hispeed.ch] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Keybuk [n=scott@quest.netsplit.com] has joined #upstart === sadleder [n=sadleder@p50814476.dip0.t-ipconnect.de] has joined #upstart === sadleder [n=sadleder@p50814476.dip0.t-ipconnect.de] has left #upstart [] === jk44 [n=laugeai@fe2adsl-2.wyplay.net] has joined #upstart [11:18] hi, i have noticed a possible bug in upstart [11:19] i wrote this job : [11:19] console output [11:19] pre-start script [11:19] echo "**UPSTART : ************* launching RCS ********** " [11:19] end script [11:19] script [11:19] echo "avant exec" [11:19] exec /etc/init.d/rcS [11:19] echo "apres exec" [11:19] end script [11:19] post-start script [11:19] echo "will try to launch runlevel 3" [11:19] echo "done rlv 3" [11:19] [11:19] echo "gona launch rcS" [11:19] end script [11:19] and post start is executed before exec script [11:20] incorrect [11:20] post start is executed alongside the exec script [11:21] ok, it explain what i get [11:21] which wins is dependant on such matters as your kernel, and possibly the one that outputs first is running second, and it's the console buffer that's fooling you [11:21] post-start makes most sense when the process run by exec is not immediately redy [11:21] you can use the post-start script to poll the daemon until it's accepting connections [11:22] the job won't be marked running until the post-start script exits [11:22] ok, thk very much [11:22] another dub question : [11:23] when a job fail starting, how can i recover, (as it has not failed) [11:23] and start the other jobs ? [11:23] is "started failed or started" [11:23] the solution ? [11:24] i am trying that, but quite unsuccessfully [11:29] start on stopped JOB failed [11:30] the stopped event for the job will include the argument "failed", and will include arguments and environment saying what failed, etc. [11:30] http://upstart.ubuntu.com/wiki/JobFailedEvent [11:30] ^ see that [11:30] e.g. [11:30] stopped apache failed [11:30] EXIT_SIGNAL=SIGSEGV [11:31] ok, sorry for bothering with such uninterresting question ^^, i had not very well understood the doc (poor english :s) [11:34] that's ok [11:34] the docs aren't great yet === phoenix24 [i=uaa@ns37986.ovh.net] has joined #upstart === phoenix24 [i=xzznc@ns37986.ovh.net] has joined #upstart [02:38] hmm [02:38] this is weird [02:38] hmm? [02:39] i've got some native jobs written for LFS [02:39] (just playing around) [02:39] it boots fine [02:39] apart from somewhere a bash syntax error gets printed [02:39] it says the syntax error is in /dev/fd/7 every time [02:40] i can't figure out why [02:40] heh [02:40] /dev/fd/7 is the name of the shell script upstart executes if it's > 1024k or so [02:41] strange [02:42] why? [02:42] i have no job even 2kb [02:42] that's a little more unusual [02:42] oh, sorry, 1024 bytes [02:42] not K [02:42] I always do that [02:42] 1K [02:42] ah [02:42] that limits it to 2 jobs [02:44] (the /dev/fd thing is because upstart makes a pipe on which it arranges the script to be executed; and that's the trick to passing it to sh as a file) [02:44] k [02:44] the weird thing though, is that i get no "job failed" message from upstart [02:44] passing it on "standard input" would mean the script couldn't use exec < or things like that [02:44] and passing it in the arguments could exceed available space [02:49] ah, got it [02:49] stupid type [02:49] *typo [02:50] dunno why it doesn't fail [02:50] maybe you've got a set +e in there? or an ||/&&, or it's part of an if, etc. [02:51] yeah, it was part of a || === phoenix24 [i=yjlbe@ns37986.ovh.net] has joined #upstart === phoenix24 [i=endggnc@ns37986.ovh.net] has joined #upstart === tale [n=tale@207.235.54.1] has joined #upstart === phoenix24_ [i=ellksfi@ns37986.ovh.net] has joined #upstart === tck [n=tck@212.2.165.61] has joined #upstart === mbiebl [n=michael@e180070166.adsl.alicedsl.de] has joined #upstart === phoenix24 [i=irpa@ns37986.ovh.net] has joined #upstart === phoenix24 [i=rurdx@ns37986.ovh.net] has joined #upstart === phoenix24 [i=zopyqic@ns37986.ovh.net] has joined #upstart [06:35] now *that's* what i call optimization [06:35] http://www.alex-smith.me.uk/files/bootchart-ud.png [06:35] :D [06:37] :-) [07:38] AlexExtreme, I'm not an upstart expert, but that distro wouldn't do much, right? [07:39] the boot sequence does actually run more stuff, just it seems that bootchart missed some stuff [07:39] currently it boots to a text-based multiuser system with networking and ssh [07:40] ah [07:40] what are some of the fastest boot times you guys are getting with the latest development code? [07:41] that is the fastest boot i have ever got with any init system [07:44] but, what about a normal ubuntu install? [07:44] i haven't tried with ubuntu, since i don't use it ;) [07:44] what distro do you use? [07:44] I assumed ubuntu since most distros don't use upstart [07:45] frugalware atm === phoenix24 [i=xgifj@ns37986.ovh.net] has joined #upstart === mbiebl [n=michael@e180070166.adsl.alicedsl.de] has joined #upstart === phoenix24_ [i=yjktn@ns37986.ovh.net] has joined #upstart === thom [n=thom@amnesiac.heapspace.net] has joined #upstart