| === ..[topic/#upstart:theCore] : 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 | ||
| === maro [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart | ||
| === j_ack_ [n=rudi@p508DAC41.dip0.t-ipconnect.de] has joined #upstart | ||
| === j_ack [n=rudi@p508D8D74.dip0.t-ipconnect.de] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === jvtm [i=jvtm@atlantis.spoon.fi] has left #upstart ["poof"] | ||
| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| === jonibo [n=jonas@213.212.2.215] has joined #upstart | ||
| Keybuk | phew | 04:10 |
|---|---|---|
| Keybuk | it looks like the upstart test failures on the buildds is caused by EELMO | 04:10 |
| Keybuk | I suspect their kernels have inotify disabled | 04:10 |
| maro | EELMO? | 04:14 |
| Keybuk | elmo likes to build custom, module-less kernels | 04:16 |
| maro | oh, heh :) | 04:18 |
| _ion | Why not just run stock kernels on buildds? | 04:19 |
| Keybuk | because they scare him | 04:19 |
| wasabi | fear is a mind killer, or something | 05:17 |
| Keybuk | heh | 05:22 |
| === jonibo [n=jonas@213.212.2.215] has left #upstart [] | ||
| === theCore [n=alex@ubuntu/member/theCore] has joined #upstart | ||
| wasabi | nice. on site interview next week. | 06:15 |
| === wasabi cheer. | ||
| Keybuk | wasabi: sweet | 06:24 |
| steev64 | the Getting Started page link to example jobs is 404 | 06:48 |
| Keybuk | fixed | 06:51 |
| steev64 | thanks :) | 06:51 |
| steev64 | as much as people are going to hate me for it (not necessarily *in here*), I am trying to get upstart working on Gentoo | 06:52 |
| Keybuk | seems to be quite popular :) | 06:56 |
| === Keybuk peers at libdbus | ||
| === AlexExtreme prods at libdbus | ||
| AlexExtreme | not one of my favourite libs... | 07:47 |
| AlexExtreme | ;) | 07:47 |
| Keybuk | I like it about as much as implementing my own IPC | 07:47 |
| Keybuk | not very much | 07:47 |
| AlexExtreme | heh | 07:47 |
| Keybuk | trying to decide whether the init/initctl communication should be done with a peer-to-peer libdbus connection | 07:47 |
| Keybuk | and whether that'll make it easier on the code at each end | 07:48 |
| AlexExtreme | but still, upstart already has it's own IPC which works for the purpose intended, why change it? | 07:48 |
| Keybuk | because it's a pain in the arse | 07:48 |
| Keybuk | in fact, upstart has two different IPCs | 07:48 |
| AlexExtreme | oh? | 07:49 |
| Keybuk | the one it uses between init and initctl | 07:50 |
| Keybuk | and the one it uses when it re-execs itself after an upgrade to transfer job/event state | 07:50 |
| Keybuk | I'd rather there was just one | 07:50 |
| AlexExtreme | ah | 07:50 |
| Keybuk | and I'd rather that one was actually easy to deal with | 07:50 |
| Keybuk | e.g. right now, to send job information from one process to the oehter | 08:09 |
| Keybuk | upstart packs that into an UpstartMsg struct | 08:09 |
| Keybuk | which has a UpstartJobStatusMsg struct inside it | 08:09 |
| Keybuk | message->job-status.name = ... | 08:10 |
| Keybuk | and tags the UpstartMsg struct with the type | 08:10 |
| Keybuk | message->type = UPSTART_JOB_STATUS; | 08:10 |
| Keybuk | then has to arrange for that to be sent asynchronously to the requesting/subscribed process | 08:10 |
| Keybuk | so it has to _COPY_ that structure into a ControlMsg struct for each process that could receive it, a field at a time | 08:11 |
| Keybuk | when the socket is writable, it then grabs the info, and packs it into an iovec buffer | 08:11 |
| Keybuk | and writes it to the receiving process | 08:11 |
| Keybuk | which has to unpack the iovec buffer into an UpstartMsg struct | 08:11 |
| AlexExtreme | right, so the point you're trying to make is that is far too complex and also reinvents the wheel (doing something dbus already does) ? | 08:11 |
| Keybuk | examine the type to determine what message type it is | 08:11 |
| Keybuk | unpack the info from the message->job_status struct back into a Job | 08:12 |
| Keybuk | and only then decide whether *it* needs to send a reply | 08:12 |
| Keybuk | etc. | 08:12 |
| Keybuk | yeah | 08:12 |
| Keybuk | it's a pain in the arse :p | 08:12 |
| AlexExtreme | sounds like it :) | 08:12 |
| Keybuk | I'm not sure that something like libdbus is any better though | 08:12 |
| AlexExtreme | hmm | 08:13 |
| Keybuk | I suspect the problem is the method of IPC | 08:15 |
| Keybuk | e.g. "send me the status of job FOO" => "bulk reply of job foo" | 08:15 |
| AlexExtreme | bbl | 08:23 |
| === treepio [n=pine@88-212-90-121.vl20-cph.dhcp.clearwire.dk] has joined #upstart | ||
| === eMish [n=lerner@bzq-84-109-21-106.red.bezeqint.net] has joined #upstart | ||
| eMish | I have several questions about updtart | 09:30 |
| eMish | upstart | 09:30 |
| eMish | (1) Does it come without automatic convertor of inittab to it's /etc/event.d ? | 09:31 |
| eMish | (2) DO I need to convert all of /etc/init.d, /etc.rcN.d to /etc/event.d ? | 09:31 |
| eMish | (3) can upstart run alonside with old init ? | 09:31 |
| Keybuk | 1 - the ubuntu package has one that handles getty and control-alt-delete changes | 09:34 |
| eMish | not kuubuntu, the upstart itself | 09:34 |
| Keybuk | 2 - no, there are example jobs on the website that handle running the /etc/rcN.d directories alongside upstart jobs; therefore you can convert them at your leisure, or even not at all | 09:34 |
| Keybuk | 3 - what do you mean by "old init" ? | 09:35 |
| eMish | ok, actually I'd prefer (3), running it alongside existing init then. Can I ? | 09:35 |
| Keybuk | eMish: the tarball itself doesn't contain the perl script, mostly by omission at the moment | 09:35 |
| Keybuk | eMish: the existing /sbin/init -- or the existing /etc/init.d stuff? | 09:35 |
| eMish | yes | 09:35 |
| eMish | doesn't upstart want to overwrite it ? | 09:35 |
| Keybuk | yes to which? | 09:35 |
| eMish | i compiled upstart and saw that upstart contains init | 09:36 |
| eMish | is it supposed to be a replcement for /sbin/init and the inittab ? | 09:36 |
| eMish | can I run upstart alongside with existing /sbin/init ? | 09:37 |
| Keybuk | it's a replacement for /sbin/init | 09:37 |
| eMish | can I run upstart alongside with existing /sbin/init ? | 09:37 |
| Keybuk | so no, you cannot run it alongside the existing one | 09:37 |
| eMish | fuck | 09:37 |
| eMish | anyway | 09:37 |
| Keybuk | you can install it to a different location, and alternate between them at boot time | 09:37 |
| eMish | heh | 09:37 |
| eMish | it's OS | 09:38 |
| eMish | anyway | 09:38 |
| Keybuk | ie. --prefix=/opt/upstart then boot with init=/opt/upstart/sbin/init | 09:38 |
| eMish | no, that's irrelevant | 09:38 |
| eMish | i want old init and upstart together | 09:38 |
| Keybuk | what's the context for wanting to run it "along side" ? | 09:38 |
| eMish | heh | 09:38 |
| eMish | wait | 09:38 |
| eMish | does upstart has ability to specify, per job, a "health-checking script" that tells if process is ok or needs to be restarted ? | 09:39 |
| eMish | and that needs to be run periodically ? | 09:40 |
| Keybuk | it's a planned feature, yes | 09:40 |
| eMish | good | 09:40 |
| Keybuk | (upstart's still in development, so often the answer tends to be "yup, on the list") | 09:40 |
| eMish | why exactly it can't be run alongside old init ? | 09:40 |
| Keybuk | because it's process #1 | 09:41 |
| Keybuk | it's designed to be process #1 | 09:41 |
| eMish | why it can't be process # 123 ? | 09:41 |
| Keybuk | because then it wouldn't be the parent of all daemon processes | 09:41 |
| Keybuk | so couldn't supervise them | 09:41 |
| eMish | i want to invoke upstart-init from old init | 09:41 |
| eMish | ah, i see | 09:41 |
| Keybuk | by assuming it's process #1, it can take advantage of several tricks | 09:42 |
| eMish | why wouldn't it just understand old inittab format then | 09:42 |
| Keybuk | it's intended to be a complete replacement | 09:42 |
| eMish | to allow for gradual and smooth igration | 09:42 |
| eMish | revolution, yes | 09:42 |
| Keybuk | nobody in reality modifies /etc/inittab much | 09:42 |
| Keybuk | just old hands who know about it | 09:42 |
| eMish | i do all the time | 09:42 |
| Keybuk | most people believe that init starts at /etc/init.d | 09:42 |
| Keybuk | so we decided to begin compatibility there | 09:42 |
| eMish | i believe you made couple of mistakes forgetting about "backward compatibility" | 09:43 |
| Keybuk | an /etc/inittab parser can easily be written that registers jobs with upstart | 09:43 |
| Keybuk | such as? | 09:43 |
| eMish | such as not parsing old /etc/inittab format | 09:43 |
| eMish | so I could migrate tasks one by one by rewriting lines and sending -HUP 1 | 09:43 |
| Keybuk | why is that a mistake? | 09:43 |
| eMish | why forgetting about backward compat is what ? | 09:44 |
| Keybuk | seriously, you'll find that in 99% of Linux installations, /etc/inittab is unmodified from what the distro installed | 09:44 |
| eMish | i fall into 1% | 09:44 |
| eMish | i always fall into that 1% | 09:44 |
| Keybuk | I'm not disputing that | 09:44 |
| Keybuk | that 1%, however, is either | 09:45 |
| eMish | of course those 99% are happy with old init | 09:45 |
| Keybuk | a) set in their ways, so unlikely to switch | 09:45 |
| Keybuk | b) technically competent enough to switch by hand | 09:45 |
| eMish | look, you're the guy which can help me | 09:45 |
| eMish | we have small router appliance, linux0-based of course | 09:45 |
| eMish | and we have our own process management | 09:45 |
| eMish | written in C by some bum | 09:45 |
| Keybuk | heh | 09:46 |
| wasabi | I'm not following why you're using Upstart before you've ported your process. | 09:46 |
| eMish | i am fixinf bugs in it and the more i fix it the worse it looks | 09:46 |
| eMish | i'm looking for a comlpete repalcement | 09:46 |
| Keybuk | pretty much similar to our story; we had a small linux distribution and realised we needed some kind of process management, so we wrote Upstart | 09:46 |
| eMish | the big missing part is, we need to specify health-checking cripts for each process | 09:46 |
| eMish | actually now that i think about it, i think checking script can restart the process | 09:47 |
| eMish | but how would i schedule health-scheking script with upstart ? | 09:47 |
| eMish | but i don't understand the installation part. /etc/eventd.d is empty | 09:48 |
| Keybuk | in theory? (not yet implemented) | 09:48 |
| eMish | am I supposed to convert inittab manually myself ? | 09:48 |
| Keybuk | something like "hourly from started JOB until stopping JOB" | 09:48 |
| Keybuk | in the job definition of the checking script | 09:48 |
| eMish | i trid initng, doesn't ghave this, too | 09:48 |
| eMish | what do you think about initng | 09:48 |
| Keybuk | eMish: yes, or use the example jobs tarball which is based on Ubuntu's inittab | 09:49 |
| eMish | i don't understand | 09:49 |
| Keybuk | init-ng is an excellent implementation of a dependency-based init system | 09:49 |
| Keybuk | upstart and init-ng are so different, I don't really see them as competitors | 09:49 |
| eMish | not automatically converting your existing setup if the mistake initng have, too | 09:49 |
| eMish | different ? both try to replce your /sbin/init | 09:50 |
| Keybuk | yes, but both replace it with things that are fundamentally different | 09:50 |
| Keybuk | to the original /sbin/init, as well as to each other | 09:50 |
| Keybuk | so, first, to answer the converting the existing setup problem ... | 09:50 |
| Keybuk | upstart is still in development | 09:50 |
| Keybuk | we're releasing early, and often | 09:50 |
| Keybuk | and are not far past the "early" stage | 09:50 |
| eMish | I see | 09:51 |
| Keybuk | the 0.2 series was "get a daemon written that's good enough to do the job of sysvinit" | 09:51 |
| Keybuk | the 0.3 series is going to be "have something that's good enough to do a much better job" | 09:51 |
| eMish | i didn't realise it's early | 09:51 |
| Keybuk | by the time we reach 1.0, I fully suspect we'll have a suite of migration and compatibility tools for people to deploy | 09:51 |
| eMish | i want char-based (curses) service controller | 09:52 |
| eMish | so i can walk list of services and enable/disable them | 09:52 |
| eMish | stop/start | 09:52 |
| eMish | add services, too | 09:52 |
| Keybuk | (phone call, brb) | 09:52 |
| Keybuk | look in util at initctl :) | 09:56 |
| eMish | I made 'make install', am I screwed up now ? I see that /sbin/init is not replaced | 09:58 |
| Keybuk | it probably went to /usr/local/sbin ? | 10:00 |
| eMish | yea | 10:00 |
| === juergbi [n=juerg@80-219-26-249.dclient.hispeed.ch] has joined #upstart | ||
| === Amaranth [n=travis@ip68-229-188-84.om.om.cox.net] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!