[04:10] <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:14] <maro> EELMO?
[04:16] <Keybuk> elmo likes to build custom, module-less kernels
[04:18] <maro> oh, heh :)
[04:19] <_ion> Why not just run stock kernels on buildds?
[04:19] <Keybuk> because they scare him
[05:17] <wasabi> fear is a mind killer, or something
[05:22] <Keybuk> heh
[06:15] <wasabi> nice. on site interview next week.
[06:24] <Keybuk> wasabi: sweet
[06:48] <steev64> the Getting Started page link to example jobs is 404
[06:51] <Keybuk> fixed
[06:51] <steev64> thanks :)
[06:52] <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:56] <Keybuk> seems to be quite popular :)
[07:47] <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:48] <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:49] <AlexExtreme> oh?
[07:50] <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
[08:09] <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:10] <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:11] <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:12] <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:13] <AlexExtreme> hmm
[08:15] <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:23] <AlexExtreme> bbl
[09:30] <eMish> I have several questions about updtart
[09:30] <eMish> upstart
[09:31] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:56] <Keybuk> look in util at initctl :)
[09:58] <eMish> I made 'make install', am I screwed up now ? I see that /sbin/init is not replaced
[10:00] <Keybuk> it probably went to /usr/local/sbin ?
[10:00] <eMish> yea