| === wasabi_ [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === mbiebl [n=michael@e180125108.adsl.alicedsl.de] has joined #upstart | ||
| === Amaranth_ [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === Amaranth_ is now known as Amaranth | ||
| === mbiebl [n=michael@e180125108.adsl.alicedsl.de] has joined #upstart | ||
| === wasabi_ [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| !alindeman:*! Regional server split, looking into it | 02:15 | |
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === j_ack [n=rudi@p508DA28C.dip0.t-ipconnect.de] has joined #upstart | ||
| === wasabi_ [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === j_ack_ [n=rudi@p508D92D5.dip0.t-ipconnect.de] has joined #upstart | ||
| === j_ack__ [n=rudi@p508D897B.dip0.t-ipconnect.de] has joined #upstart | ||
| === Keybuk [i=scott@conference/canonical/x-20ecf65e61c799f5] has joined #upstart | ||
| === wasabi_ [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === yankees26 [n=james@ool-43575023.dyn.optonline.net] has left #upstart [] | ||
| === mbiebl [n=michael@e180085146.adsl.alicedsl.de] has joined #upstart | ||
| === wasabi__ [n=wasabi@cpe-76-184-95-8.tx.res.rr.com] has joined #upstart | ||
| === johnnybuoy [n=johnny@unaffiliated/johnnybuoy] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === mbiebl [n=michael@e180104034.adsl.alicedsl.de] has joined #upstart | ||
| === fx|RabBit [n=rabbit@cm166-191.liwest.at] has joined #upstart | ||
| fx|RabBit | hmm.. hi | 03:32 |
|---|---|---|
| === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| === Keybuk [i=scott@conference/canonical/x-04efab55d890e8b0] has joined #upstart | ||
| === j_ack [n=rudi@p508DB593.dip0.t-ipconnect.de] has joined #upstart | ||
| wasabi | Random knowledge from Windows: Windows Services are .exe files which use a messaging API to the service host. The service host does the normal respawn stuff, but it can also detect when the service "fails to start". It does so because when the service is successfully started, it should send a message. | 07:13 |
| wasabi | And after a timeout, it hasn't yet happened. The API lets the service "request more time". | 07:13 |
| wasabi | Interesting concept. | 07:13 |
| wasabi | This allows the GUI to act a bit more reasonably... it can basically say "Starting...", and only remove the box when everything is in fact properlly started. | 07:16 |
| wasabi | We can do the same with creative uses of post-start though. | 07:16 |
| === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| === mbiebl [n=michael@e180104034.adsl.alicedsl.de] has joined #upstart | ||
| === phsdv [n=paul@83.156.71.133] has joined #upstart | ||
| myren | its a watchdog timer | 08:11 |
| myren | ping the system to make sure its responsive | 08:11 |
| myren | if you dont get a ping back, assume the worst | 08:11 |
| myren | how would you do that with post-start? | 08:11 |
| myren | you'd need to ddo a dbus ping or something | 08:11 |
| myren | i cant think of how else you'd query/ping | 08:11 |
| Keybuk | wasabi: launchd uses a similar system | 08:23 |
| Keybuk | I was talking to the Nokia guys about having some kind of upstart/service communication as well | 08:23 |
| wasabi | myren: Well, post-start is up to the service to implement however it feels like it. For apache, it could actually issue a GET. | 08:24 |
| myren | right | 08:24 |
| myren | i was thinking about just portscanning | 08:25 |
| myren | lookup the pid in netstat and see if its listening | 08:25 |
| wasabi | Sure, it just connect to it to see if it answers. | 08:26 |
| wasabi | Anything. | 08:26 |
| myren | launchd is osx right? | 08:26 |
| === myren nods | ||
| myren | yup | 08:26 |
| wasabi | My dislike with having the service talk to upstart itself is one of politics. | 08:26 |
| wasabi | You'd have to introduce basically a binary dependency to upstart from Apache. | 08:27 |
| wasabi | Which wouldn't go over so well. | 08:27 |
| Keybuk | right | 08:27 |
| Keybuk | it's useful in things like the 770 though | 08:27 |
| wasabi | Yeah. | 08:27 |
| wasabi | You also could accomplish the same thing with post-start itself pretty easily. | 08:28 |
| wasabi | post-start would start "apache-watcher" or something, a binary, which could talk to apache however it wanted to. | 08:28 |
| Keybuk | right | 08:28 |
| myren | it makes sense with dbus | 08:29 |
| myren | check to see if it has a com.ubuntu.upstart.ping or something | 08:29 |
| myren | and if it has the service, hit it | 08:29 |
| myren | no dependencies | 08:29 |
| wasabi | Sure, but dbus is itself a dependency most don't want in that place. | 08:30 |
| Keybuk | right | 08:30 |
| myren | what, upstart or the app? | 08:30 |
| wasabi | both. | 08:30 |
| myren | oh, well then you got nothing | 08:30 |
| myren | if you dont want to add functionality you wont get functionality | 08:30 |
| myren | which is fine | 08:30 |
| wasabi | I doubt the apache guys want to build in dbus to apache. :0 | 08:30 |
| wasabi | A helper? Sure. | 08:30 |
| Keybuk | I like the optional functionality idea | 08:30 |
| wasabi | But apache runs on windows too. | 08:30 |
| myren | build yourself a 3 line dbus script | 08:30 |
| myren | that it can optionally use | 08:31 |
| myren | the real issue is with dbus, there's not a particularly good way to dbus a process by its process id | 08:31 |
| myren | i really think dbus is the way to go here | 08:31 |
| myren | its the only quasi standard communication system you've got | 08:31 |
| wasabi | You mean other than unix sockets. | 08:32 |
| myren | a wget ping will help apache and no one else | 08:32 |
| wasabi | Heh. | 08:32 |
| myren | but you'd need a ping protocol for unix sockets | 08:32 |
| wasabi | You'd need the same for dbus. | 08:32 |
| wasabi | And a ping protocol is nothing more than a if (!connect()) | 08:32 |
| myren | uh, is that applicable for unix sockets | 08:32 |
| wasabi | Either way, I don't think it needs to be part of upstart prime. Simply dispatching to an external helper imo is hte best. | 08:33 |
| myren | its definately a great idea | 08:33 |
| myren | i like dbus because its functional | 08:33 |
| myren | if you ping something | 08:33 |
| myren | and you get a reply, you can be just about certain its not totally hung | 08:33 |
| myren | it negotiated itself basically beyond reproach | 08:34 |
| myren | no ones going to just happen to answer it | 08:34 |
| myren | unless they mean to | 08:34 |
| wasabi | Sillyness | 08:34 |
| myren | i dunno, it seems like a much more contractual garuntee than seeing if a socket is open | 08:34 |
| myren | that seems, i dunno, antiquated | 08:35 |
| wasabi | "Seems antiquated" isn't a very compelling argument. | 08:35 |
| wasabi | dbus is massively complicated for something in PID1. | 08:36 |
| myren | as a system wide eventing daemon | 08:36 |
| myren | it better fucking support dbus | 08:36 |
| myren | um | 08:36 |
| myren | i'm no one, ps | 08:36 |
| wasabi | It will, with a proxy. | 08:36 |
| wasabi | Upstart itself uses a plain unix socket. | 08:36 |
| myren | i have absolutely zero say in this project | 08:36 |
| myren | but personally i think dbus is the only acceptable IPC | 08:37 |
| wasabi | On what grounds? | 08:37 |
| myren | its a protocol | 08:37 |
| myren | thats it | 08:37 |
| wasabi | Huh? | 08:37 |
| myren | its not a socket | 08:37 |
| wasabi | Yes it is. ;) | 08:37 |
| myren | a protocol defines ways of talking with each other | 08:37 |
| myren | you can scream anything and everything into a socket | 08:38 |
| wasabi | DBUS is a very large complicated messaging API, implemented on top of a socket. | 08:38 |
| myren | which is why its useful | 08:38 |
| myren | its an API for IPC | 08:38 |
| myren | anyone can open up dbus | 08:38 |
| wasabi | I suspect you have conflicting goals. | 08:38 |
| myren | and start communicating | 08:38 |
| myren | discovering | 08:38 |
| myren | eventing | 08:38 |
| myren | knowing nothing about hte system | 08:39 |
| wasabi | 1: A user space friendly GUI application managing services. DBUS is nice for that. | 08:39 |
| myren | its a machine to machine communication language | 08:39 |
| wasabi | 2: PID 1 | 08:39 |
| _ion | We should use XML for IPC! Upstart doesn't have a sufficient amount of enterprise yet. | 08:39 |
| myren | upstart is not just another pid 1 replacement | 08:39 |
| wasabi | Hmm. Yes it is. ;) | 08:39 |
| myren | it seems to me like the goal is much larger than simply initializing programs | 08:40 |
| wasabi | jhaltom@station-1:~$ ls -al /sbin/init | 08:40 |
| wasabi | -rwxr-xr-x 1 root root 57696 2006-10-10 05:42 /sbin/init | 08:40 |
| myren | that there's a strong eventing componenet too | 08:40 |
| wasabi | jhaltom@station-1:~$ ls -al /usr/lib/libdbus-1.so.3.0.0 | 08:40 |
| wasabi | -rw-r--r-- 1 root root 195484 2006-10-20 06:46 /usr/lib/libdbus-1.so.3.0.0 | 08:40 |
| wasabi | dbus is almost *4* times larger than upstart. | 08:40 |
| myren | whats an order of magnitude or two between friends | 08:40 |
| wasabi | Excluding dependencies of dbus. | 08:40 |
| myren | ok, size asize | 08:41 |
| myren | aside | 08:41 |
| myren | practicality aside | 08:41 |
| myren | just for a second | 08:41 |
| wasabi | Why put it aside? It's are core argument. | 08:41 |
| wasabi | It's PID1. | 08:41 |
| myren | because its your only reply to everything i say | 08:41 |
| wasabi | If it crashes, your system turns off. | 08:41 |
| myren | and you ignore every point i make simply on that ground | 08:41 |
| myren | just bear with me for a second | 08:41 |
| _ion | I don't really see moving from 60k to 200k as a problem with any hardware upstart is running on. Oh, and: | 08:42 |
| _ion | -rwxr-xr-x 1 root root 1166796 2006-10-10 17:46 /lib/libc.so.6 | 08:42 |
| wasabi | Sure. | 08:42 |
| myren | sorry work for a second | 08:43 |
| _ion | I don't have a strong opinion either way. I guess dbus is as good protocol for IPC as any. | 08:43 |
| myren | v. sorry | 08:43 |
| myren | ok back | 08:43 |
| myren | the thing is, most pid1's play a passive role in the system | 08:44 |
| myren | they launch a bunch of shit and then go to sleep and become obsolete | 08:44 |
| myren | upstart, to me, signifies very much more of an event based process management system | 08:44 |
| myren | rather than simply an init script | 08:44 |
| myren | i could be misconstruing the goals, but it seems to be something that continues doing useful work as the system stays up | 08:45 |
| myren | to really effectively do that, it needs to be capable of eventing with other subsystems | 08:45 |
| myren | it needs IPC | 08:45 |
| myren | i could be totally misconstruing the goals purpose & design here | 08:45 |
| myren | but i thought the idea was to make it functionally more complex | 08:45 |
| myren | thats it | 08:46 |
| wasabi | 1) Most inits continue doing useful work, such as switching runlevels, which can be considered "acting on events". | 08:46 |
| wasabi | 2) It is currently capable of IPC. It alrady has it. | 08:46 |
| myren | thats the main stimuli-response i see | 08:46 |
| wasabi | 3) The goal of software is never to make it more complex. | 08:47 |
| myren | no thats your goal | 08:50 |
| myren | The current version of Ubuntu, for example, includes sysvinit, atd, crond, | 08:50 |
| myren | anacron and netkit-inetd; all of which are congured dierently, yet are | 08:50 |
| myren | arguably performing the same kind of job. | 08:50 |
| myren | jobs such as starting and stopping services and run- | 08:50 |
| myren | ning user scripts are also performed by packages such as udev, acpid, apmd, | 08:51 |
| myren | ifupdown and even module-init-tools | 08:51 |
| myren | your goal is to replace that with something complex & functional enough to serve as a replacement | 08:51 |
| myren | upstart is a single replacement for the standard UNIX services, combining their | 08:51 |
| myren | functionality into a single daemon which can be easily congu | 08:51 |
| myren | me: your goal is to replace that with something complex & functional enough to serve as a replacement | 08:51 |
| wasabi | No, my goal is to replace it with something functional enough to serve as a replacement, not neccassarily complex. | 08:51 |
| myren | i'll do more real digging into upstart & get back to you | 08:52 |
| myren | i dont really know your functional capabilities yet | 08:52 |
| myren | just scares me when codesize is the big bad voodoo monster threat | 08:52 |
| wasabi | I used codesize as a poor example. | 08:53 |
| wasabi | Should have picked a figure to more accurately represent complexity. | 08:53 |
| myren | and i just hyperbolized rather injurously | 08:53 |
| wasabi | DBUS is complicated. It has all sorts of cool things which are very useful, but few of which are neccassary for a system seemingly requriing only the sending of events and starting of named jobs. | 08:54 |
| wasabi | Not to say we don't want a DBUS API to those, we do. | 08:54 |
| wasabi | Just that it's not likely to be implemented in PID1, but likely as an out of process proxy. | 08:54 |
| wasabi | Personally I think simply invoking an executable and waiting for a return value ==0 is simplier than introducing DBUS in both init and apache. | 08:57 |
| wasabi | Which is where all this started. | 08:57 |
| myren | no i agree with you a lot more now, dbus in upstart proper is a bad idea | 09:07 |
| myren | i need to see how hard it'll be to make a proxy | 09:08 |
| myren | aka try and make one | 09:08 |
| === yankees26 [n=yankees2@ool-182c6007.dyn.optonline.net] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === yankees26 [n=james@ool-182c6007.dyn.optonline.net] has joined #upstart | ||
| === yankees26 [n=james@ool-182c6007.dyn.optonline.net] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!