| !alindeman:*! And, as always, if you have further questions, please feel free to message an on-duty staff member ( /stats p ) | 12:20 | |
| === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart | ||
| === johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #upstart | ||
| === mbiebl [n=michael@dialin-145-254-247-141.pools.arcor-ip.net] has joined #upstart | ||
| === maro_ [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart | ||
| maro_ | evening :) | 01:03 |
|---|---|---|
| === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === j_ack [n=rudi@p508D93F0.dip0.t-ipconnect.de] has joined #upstart | ||
| Steven_Shiau | is there anyone know how to move the login prompt after /etc/rc2.d/S99xxx service ? Since when I removed "quiet" and "splash" in grub kernel parameters, the output of those services of runlevel 2 is in a mess. | 03:33 |
| === j_ack_ [n=rudi@p508D93F0.dip0.t-ipconnect.de] has joined #upstart | ||
| Steven_Shiau | or is that possible to move the output of runlevel 2 services to console 2 or other consoles ? | 03:39 |
| === j_ack [n=rudi@p508D93F0.dip0.t-ipconnect.de] has joined #upstart | ||
| Steven_Shiau | forgot to say, I am using upstart 0.2.7-1 | 03:40 |
| Steven_Shiau | in Ubuntu Edgy alpha3 with updated packages | 03:40 |
| Steven_Shiau | oh, upstart 0.2.7-3 is released, I upgraded that, and now it's better | 03:50 |
| === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart | ||
| Steven_Shiau | The output of services in runlevel 2 now looks better | 03:51 |
| johnnybuoy | hmm | 05:08 |
| johnnybuoy | there is a problem in edgy mdadm-raid script... | 05:08 |
| johnnybuoy | anyone know about upstart scripts? | 05:09 |
| !alindeman:*! Regional server split; we're looking into it | 05:21 | |
| === j_ack [n=rudi@p508D93F0.dip0.t-ipconnect.de] has joined #upstart | ||
| === j_ack_ [n=rudi@p508D8D39.dip0.t-ipconnect.de] has joined #upstart | ||
| === DazWiLLiE [n=WiLLiE@81-235-146-18-no33.tbcn.telia.com] has joined #upstart | ||
| === DazWiLLiE [n=WiLLiE@81-235-146-18-no33.tbcn.telia.com] has left #upstart [] | ||
| === j_ack [n=rudi@p508D8D39.dip0.t-ipconnect.de] has joined #upstart | ||
| === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart | ||
| === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === maro_ [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart | ||
| === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart | ||
| === Seveas [n=seveas@ubuntu/member/seveas] has joined #upstart | ||
| === Artanicus [i=kuitunej@lehtori.cc.tut.fi] has joined #upstart | ||
| === pepsiman [n=malcolm@82-33-127-97.cable.ubr05.azte.blueyonder.co.uk] has joined #upstart | ||
| === fdoving [n=frode@ubuntu/member/frode] has joined #upstart | ||
| === alp [n=alp@host-87-74-40-238.bulldogdsl.com] has joined #upstart | ||
| === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #upstart | ||
| === zx64 [n=zx64@freecnc/zx64] has joined #upstart | ||
| === neuralis [n=krstic@solarsail.hcs.harvard.edu] has joined #upstart | ||
| === mjg59 [n=mjg59@cavan.codon.org.uk] has joined #upstart | ||
| === thom [n=thom@195.54.228.42] has joined #upstart | ||
| === vvl [i=vvl@leviathan.hellfish.org] has joined #upstart | ||
| === zorglub [n=zorglub@wahe.diwi.org] has joined #upstart | ||
| === _ion [i=johan@kiviniemi.name] has joined #upstart | ||
| -ChanServ(ChanServ@services.)- [#ubuntu-server] Ubuntu Server Discussions (development and support) | 07:24 | |
| -ChanServ(ChanServ@services.)- [#ubuntu] Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there | 07:24 | |
| === sciboy [n=sciboy@unaffiliated/sciboy] has joined #upstart | ||
| sciboy | Hello fellas. | 07:30 |
| === sciboy [n=sciboy@unaffiliated/sciboy] has left #upstart ["Leaving"] | ||
| === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart | ||
| === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart | ||
| === Seveas [n=seveas@ubuntu/member/seveas] has joined #upstart | ||
| === Artanicus [i=kuitunej@lehtori.cc.tut.fi] has joined #upstart | ||
| === pepsiman [n=malcolm@82-33-127-97.cable.ubr05.azte.blueyonder.co.uk] has joined #upstart | ||
| === fdoving [n=frode@ubuntu/member/frode] has joined #upstart | ||
| === alp [n=alp@host-87-74-40-238.bulldogdsl.com] has joined #upstart | ||
| === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #upstart | ||
| === zx64 [n=zx64@freecnc/zx64] has joined #upstart | ||
| === neuralis [n=krstic@solarsail.hcs.harvard.edu] has joined #upstart | ||
| === mjg59 [n=mjg59@cavan.codon.org.uk] has joined #upstart | ||
| === thom [n=thom@195.54.228.42] has joined #upstart | ||
| === vvl [i=vvl@leviathan.hellfish.org] has joined #upstart | ||
| === zorglub [n=zorglub@wahe.diwi.org] has joined #upstart | ||
| === _ion [i=johan@kiviniemi.name] has joined #upstart | ||
| -ChanServ(ChanServ@services.)- [#ubuntu-server] Ubuntu Server Discussions (development and support) | 07:57 | |
| -ChanServ(ChanServ@services.)- [#ubuntu] Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there | 07:57 | |
| === matthew_i [n=matthew@pdpc/supporter/sustaining/MasterYoda] has joined #upstart | ||
| === matthew_i [n=matthew@pdpc/supporter/sustaining/MasterYoda] has joined #upstart | ||
| === Artanicus [i=kuitunej@lehtori.cc.tut.fi] has joined #upstart | ||
| === fdoving [n=frode@ubuntu/member/frode] has joined #upstart | ||
| === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #upstart | ||
| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === maro_ [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart | ||
| === juergbi [n=juerg@80-219-26-249.dclient.hispeed.ch] has joined #upstart | ||
| === maro_ [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart | ||
| maro_ | would it be possible to make a job for running update-pciids daily when the network is up? | 02:10 |
| Md | maro_: do you instert new PCI cards in your system every day? | 02:11 |
| Md | s/instert/insert/ | 02:11 |
| maro_ | that was just an example | 02:11 |
| Md | yes, you can | 02:11 |
| maro_ | it could be abstracted into "is it possible to do an action on a event if a condition is true" | 02:12 |
| maro_ | and a sample event.d file would trigger a huge "thank you!" | 02:13 |
| maro_ | or even better, a directory with sample event.d entries (other than the rc compat things) :) | 02:14 |
| _ion | upstart doesn't implement cron/at functionality yet. | 02:29 |
| maro_ | ah, I'll wait for the spiffy features then - thanks :) | 02:37 |
| _ion | Keybuk said he's hoping to start developing the 0.5 branch this weekend IIRC. I'm not sure whether the cron/at functionality is going to be in 0.5, though. | 02:39 |
| _ion | I hope so. :-) | 02:39 |
| maro_ | cool - me too :) | 02:39 |
| _ion | Perhaps i can even contribute some code, if my health allows. | 02:39 |
| maro_ | you're sick? :( | 02:39 |
| === johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #upstart | ||
| _ion | Well, i've been unable to work for almost two years. Very rarely i have enough energy to be able to concentrate enough to create a small, simple patch for some project. | 02:43 |
| maro_ | :/ | 02:48 |
| Keybuk | _ion: my vague thoughts are that 0.5 would be a "roughly feature complete" version | 03:09 |
| Keybuk | it may be a long cycle, as it's what we'd ship in edgy+1 eventually | 03:09 |
| Keybuk | and would be what I'd expect other distros to think about shipping | 03:10 |
| LarstiQ | sounds about perfect to hack up one weekend ;) | 03:12 |
| _ion | keybuk: Sounds good. | 03:13 |
| wasabi | Keybuk: We were talking yesterday about the event failure status chaining. I do think that the event's "exit" status shouldn't be known until the event, and all jobs that follow, directly or indirectly, is known... but that status doesnt' reflect on whether the system has "failed" to startup. | 03:38 |
| wasabi | Whether "startup" fails or not has no bearing on what services were started as a result of triggering it. | 03:38 |
| wasabi | They're still started. | 03:39 |
| Keybuk | wasabi: I'm not sure I follow what you mean | 03:43 |
| wasabi | Well, we were considering the idea of being able to wait for an event to be "done. | 03:43 |
| wasabi | So, something like initctl trigger foo && echo done | 03:44 |
| wasabi | can work. | 03:44 |
| wasabi | So it doesn't just finish immediatly. | 03:45 |
| wasabi | Also, to get the return fail/success of an event, delivered back over the control socket. | 03:45 |
| wasabi | ie you create an event, the socket tells you the id, then later tells you the success/fail of the id. | 03:45 |
| Keybuk | right | 03:45 |
| wasabi | Can an event really be considered completely handled if there are still processes running because of it? | 03:46 |
| Keybuk | it's an interesting question | 03:46 |
| Keybuk | depends on whether the process is a service or a task, I guess? | 03:47 |
| Keybuk | the ultimate goal of a service is just to be started | 03:47 |
| wasabi | Consider job2 with "start on job1 starting". When job1 moves to starting, upstart itself issues that event. Causing job1 to start. | 03:47 |
| Keybuk | but the ultimate goal of a task is to be started AND get back to stopped again | 03:47 |
| wasabi | Err, job2 to start. | 03:47 |
| wasabi | job2 may be something like a custom script an admni wanted to run BEFORE a given service starts. | 03:47 |
| wasabi | I think in most cases you would desire job2 to complete before job1 proceeds. | 03:48 |
| Keybuk | I disagree | 03:48 |
| Keybuk | the admin should modify job1, no? | 03:48 |
| Keybuk | they're adding a new pre-requisite to it? | 03:48 |
| wasabi | Well, you might say that, but I see that it's a bit non ideal because it makes any upgrade to job1's job file require human interaction. | 03:49 |
| wasabi | That's not a big deal though. | 03:49 |
| wasabi | What if the "admin" is another package that desires to start before one? | 03:49 |
| wasabi | The other package can't modify job1's script in it's post-inst,t hat'd be messy. | 03:49 |
| Keybuk | if you can come up with a use case for that ... ? | 03:49 |
| wasabi | Impossible to revert, would screw up upgrades of job1. | 03:49 |
| wasabi | Yeah thinking. ;) | 03:49 |
| wasabi | I have a few ideas, but I can think of them being started in other ways. I'm just not sure which is better. Take xsp... the Mono web server. | 03:50 |
| wasabi | It's basically a stand alone daemon, which receives requests that originate thorugh apache. | 03:51 |
| _ion | Actually not being able to do a three-way merge is package manager's fault. | 03:51 |
| wasabi | Also, I guess tomcat is the same here. | 03:51 |
| _ion | Re: human interaction during upgrades. | 03:51 |
| wasabi | Those are services which ideally should be started BEFORE apache. | 03:51 |
| wasabi | But they are installed sepereatly, and apache doesnt' depend on them. | 03:52 |
| wasabi | In the normal case. | 03:52 |
| Keybuk | the problem is coming up with a model that isn't insane ;) | 03:52 |
| wasabi | If you install tomcat, you would desire, only if it's installed, for it to start before apache. | 03:52 |
| wasabi | Otherwise apache has no relation to it. | 03:52 |
| wasabi | So, you don't want the install for tomcat to have to modify apache's job file. | 03:53 |
| wasabi | For the previous reasons. =) | 03:53 |
| _ion | I think Gentoo has something like "after foo" and "before bar" | 03:53 |
| wasabi | Yeah. I think we have that too in our "job-starting apache" | 03:53 |
| Keybuk | after has been proposed | 03:53 |
| Keybuk | we could have "before" as well | 03:53 |
| wasabi | event.d/tomcat : "start on job-starting apache" | 03:53 |
| wasabi | Is that not before? | 03:53 |
| Keybuk | no, because that doesn't cause apache to wait | 03:53 |
| wasabi | Yeah, and that's the question. Should it. | 03:54 |
| _ion | And it shouldn't IMO. | 03:54 |
| wasabi | Why? | 03:54 |
| Keybuk | well, for a start you have to define what you're waiting for | 03:54 |
| _ion | Everything that causes apache to wait should be defined in the apache file IMO. | 03:54 |
| Keybuk | when do you release apache? | 03:54 |
| Keybuk | when you spawned the tomcat process (too early!) | 03:54 |
| _ion | Otherwise it's just confusing. | 03:54 |
| wasabi | No, this still works. | 03:55 |
| wasabi | Okay, you know how initctl will work? | 03:55 |
| wasabi | Event gets issued, all the jobs that upstart is going to change goals on are found, only when they have all successfully reached that goal, is the event considered finished. | 03:55 |
| Keybuk | I don't know how that will work yet | 03:56 |
| wasabi | Or, successfully failed, anyways. | 03:56 |
| Keybuk | because the goal is a wishy-washy bit <g> | 03:56 |
| wasabi | Well, they will be turned "unidle" by the event. | 03:56 |
| wasabi | At somepoint they'll be idle again. | 03:56 |
| Keybuk | unidle? | 03:56 |
| wasabi | No goal. | 03:56 |
| wasabi | Goal. | 03:56 |
| Keybuk | there's always a goal | 03:57 |
| wasabi | How so? | 03:57 |
| Keybuk | the goal is always either stop or start, no? | 03:57 |
| wasabi | If a service is started, and nothing has told it to stop, hasn't it reached it's goal? | 03:57 |
| _ion | Its goal is still "start". | 03:58 |
| wasabi | Hmm. | 03:58 |
| wasabi | Okay. I see what you mean then. | 03:58 |
| wasabi | The goal is start, but it's "done". | 03:58 |
| Keybuk | and when tomcat reaches started, it's not yet ready for apache to start | 03:58 |
| wasabi | There's an indicator for "done" someplace, so it doesn't get touched on the mainloop, surely. | 03:58 |
| wasabi | Keybuk: Yeah, it is. | 03:58 |
| Keybuk | no it's not | 03:58 |
| Keybuk | tomcat isn't listening yet | 03:58 |
| wasabi | Keybuk: Since we moved post-start into starting. ;) | 03:58 |
| Keybuk | we did ?! | 03:59 |
| _ion | :-D | 03:59 |
| === Keybuk must keep up | ||
| === wasabi checks wiki | ||
| wasabi | I did in my head anyways. | 03:59 |
| Keybuk | post-start being before started seems ... odd :p | 03:59 |
| wasabi | Well, maybe the script names are unappropiate. | 03:59 |
| wasabi | post-exec | 03:59 |
| wasabi | pre-exec | 03:59 |
| wasabi | "started" | 03:59 |
| wasabi | man the wiki is always so slow | 03:59 |
| wasabi | Yeah. | 04:00 |
| wasabi | I made those changes ages ago. Thought you read em. | 04:00 |
| wasabi | Putting the post-start, whatever we call it, script in starting, makes the most sense. | 04:01 |
| _ion | Agreed. | 04:01 |
| wasabi | Then "started" gets properlly emitted when it's really done. | 04:01 |
| Keybuk | I get vaguely dyslexic with long prose paragraphs; which is why I turn things into bullet points when I think I understand them | 04:01 |
| wasabi | Yeah. | 04:02 |
| wasabi | I was braindumping. | 04:02 |
| Keybuk | I probably missed the change :p | 04:02 |
| wasabi | I don't want to shove that change on you, btw. But think about it. :) | 04:02 |
| wasabi | Anyways, so, initctl trigger foo, causes all the jobs to be enumerated, they all go into some sort of "work" state, as they attempt to move to whatever they should. Some of them get there and then immediatly go back to stopped again, eventually they all go idle. | 04:03 |
| _ion | Having "pre-start, exec and post-start" in "starting" and "sted" after running those successfully is intuitive IMO. | 04:03 |
| _ion | s/sted/started/ | 04:04 |
| wasabi | At the point they're idle, the result code is returned to the issuer of the starting event. | 04:04 |
| Keybuk | right | 04:04 |
| Keybuk | here's a question then | 04:04 |
| wasabi | But that can be recursive. A job may itself run initctl trigger. | 04:04 |
| Keybuk | a service's goal is to reach the start state | 04:04 |
| wasabi | In which case that job's PID is blocking on initctl, and the issuer of the original event is blocking on that job. | 04:04 |
| Keybuk | but a task's goal is to reach the start state and then get back to the stop state | 04:04 |
| wasabi | Eventually that unwinds. | 04:04 |
| wasabi | I'd say there's not much difference between a service and a task. | 04:05 |
| wasabi | Programatically. | 04:05 |
| wasabi | One just doesn't have anything to run long term. | 04:05 |
| Keybuk | there's no programatically | 04:05 |
| Keybuk | +ne | 04:05 |
| Keybuk | but there might be a desire to distinguish their behaviour for jobs | 04:05 |
| Keybuk | e.g. if I have a short task (like, say, check the root filesystem) | 04:05 |
| Keybuk | and I trigger that event with initctl | 04:05 |
| Keybuk | should it wait for the root filesystem to be checked | 04:05 |
| Keybuk | or for the check to begin? | 04:05 |
| wasabi | I think it should have the potential to wait. | 04:06 |
| _ion | The first impression is that it should wait for fsck's completion. | 04:06 |
| wasabi | I think not waiting is an acceptable option for initctl though | 04:06 |
| wasabi | initctl -n trigger whatever | 04:06 |
| wasabi | Whether that's default one way or another is totally open. | 04:07 |
| _ion | Or perhaps alternatively something like this: "start footask" waits for its completion, "initctl trigger footask" doesn't. | 04:07 |
| wasabi | initctl can put the event on the socket, and then just close it and exit, without waiting for upstart to return the result. | 04:07 |
| Keybuk | I was thinking about the failed example | 04:07 |
| Keybuk | on job-failed check-root | 04:07 |
| Keybuk | should that be issued if check-root fails to finish, or just when it fails to start? | 04:07 |
| _ion | Both. | 04:08 |
| wasabi | What's the diff? | 04:08 |
| Keybuk | when do you decide a job has failed? | 04:08 |
| wasabi | When it has been determined it is unable to reach it's goal. | 04:08 |
| Keybuk | but what's it's goal? | 04:08 |
| === j_ack [n=rudi@p508D8B75.dip0.t-ipconnect.de] has joined #upstart | ||
| Keybuk | is the goal to begin checking the root filesystem, or to have completed the check? | 04:09 |
| wasabi | Good interesting question. | 04:09 |
| wasabi | I can't see much of a use for the goal being to begin it. | 04:09 |
| _ion | How about this? A task has failed if anything (pre-start, exec, post-start, pre-stop, post-stop) returns a non-zero value. A service has failed if pre-start, exec or post-start returns a non-zero value. | 04:09 |
| wasabi | _ion: That's why I talk about "idle". A task is only "idle" after it's back at stopped. | 04:10 |
| wasabi | A service goes idle at "started". | 04:10 |
| wasabi | Basically, an iteration of the mainloop has determined that there's nothing being waited on, and it's at the current goal. | 04:11 |
| wasabi | For a task, when it reaches "started", the iteration realizes there's nothing that's running, and sets the goal back to stopped, and keeps going. | 04:11 |
| wasabi | But it's not idle. | 04:11 |
| wasabi | for a serivice, the iteration realies that it's waiting on a running process. | 04:12 |
| wasabi | i'm totaly late for work now. | 04:12 |
| wasabi | I gotta jet. Bbl. | 04:12 |
| Keybuk | have fun | 04:12 |
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === stevenshiau [n=c00jhs00@jfhsiau-NCHC.ADSL.NCTU.edu.tw] has joined #upstart | ||
| === stevenshiau [n=c00jhs00@jfhsiau-NCHC.ADSL.NCTU.edu.tw] has left #upstart [] | ||
| === cortana [n=sam@pc-62-31-146-25-ga.blueyonder.co.uk] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === j_ack [n=rudi@p508D8B75.dip0.t-ipconnect.de] has joined #upstart | ||
| === cortana [n=sam@pc-62-31-146-25-ga.blueyonder.co.uk] has joined #upstart | ||
| === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart | ||
| === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart | ||
| === j_ack [n=rudi@p508D8B75.dip0.t-ipconnect.de] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!