#upstart 2006-12-03 <treepio> Can someone help me with a basuc (real basic) system with upstart? <treepio> I cant seem to find the example files "The requested URL /download/example-jobs.tar.gz was not found on this server." where can I find those ? <AlexExtreme> it's example-jobs-2.tar.gz <treepio> AlexExtreme: thank you, I will try that <treepio> AlexExtreme: perfect, thank you. <Keybuk> evening <_ion> That. <Keybuk> that? <_ion> Yes, evening. :-) <Keybuk> heh <yankees26> that was genius <yankees26> :p <theCore> is it just me or upstart haven't been updated for a while? <theCore> is it done? <theCore> :P <AlexExtreme> no, there's just a lack of coding :p <theCore> ah <AlexExtreme> and yay, i broke gnome-session! <AlexExtreme> neither the panel nor metacity came up :P <yankees26> nice job alex <_ion> thecore: There's been a lot of planning, see the wiki at the upstart website. <theCore> oh, there's a wiki now? nice <theCore> _ion, thanks for the info <yankees26> sorry to report i wont be using upstart in LFS guys 'cause i've become too lazy to do LFS :P and my package manager is also dead in that case :P <AlexExtreme> I got bored of LFS :P <AlexExtreme> I never get past about 5 packages of BLFS :) <yankees26> heh, i didnt even start <yankees26> and my previous attempts never got pasted binutils :P <Keybuk> theCore: as Johan said, mostly been planning out the new stuff for 0.3 <Keybuk> and been distracted by UDS and then the Canonical All Hands, and getting feisty open <Keybuk> next week is probably my first full week on upstart again :) <Keybuk> http://upstart.ubuntu.com/wiki/JobSerialisation <Keybuk> ^ new sexyness :p <AlexExtreme> nooo <AlexExtreme> http://upstart.ubuntu.com/wiki/SplashIntegration <AlexExtreme> ^ that's sexyness! :p <theCore> sweet <Keybuk> SI: that was originally what logd was going to do -- subscribe to job notifications from upstart and send stuff to usplash <Keybuk> never did that though <theCore> Keybuk, I got a question <Keybuk> theCore: what is your question? <AlexExtreme> brb <theCore> is the intended behaviour for upstart to send the output of the jobs to the "active" console? <Keybuk> if you have "console output", yes <Keybuk> it just sends it to /dev/console <Keybuk> which is the active console <theCore> personally, I find this quite annoying <AlexExtreme> the default is to be logged though <Keybuk> right, the default is to send it to a daemon that knows better how to do with it <Keybuk> if you wanted the messages in a file, or on a particular VT, or sent to a daemon or serial port, etc. you could do that with the daemon <theCore> would I need to edit all the jobs, or I could set that in the upstart conf (if there's one) <theCore> ? <_ion> Sigh, i don't seem to get a freaking Hello World done. <Keybuk> theCore: it's the default to send it to the daemon <_ion> Today i thought i'd write an upstart job parser (with support for complex-event-config and emits stanzas, as in the specifications) in ruby and then make it output a graphviz dot file, but just couldn't concentrate. <theCore> does logd only write the job's output to /var/log/boot? <_ion> Currently yes. <theCore> ok, that's what thought #upstart 2006-12-04 <vernes> How do I add my own runlevel to the upstart system? A quick glance shows that /etc/init.d/rc is called with the runlevel as argument, do I have to edit rc to add my own runlevel? <AlexExtreme> How nice of you. <treepio> Do you know a guide to make a working system with upstart?, I want to learn. <treepio> You can private message me if you do please, yould help me alot. <treepio> And eventually help upstart :) <treepio> Too bad, would have been great to have some reference. #upstart 2006-12-05 <Squido> How does one pass a variable from the grub <Squido> boot line to a script? <_ion> /proc/cmdline * Starting logfile irclogs/upstart.log * Starting logfile irclogs/upstart.log <Keybuk> afternoon <_ion> Hi <AlexExtreme> hey <Keybuk> Testing nih_alloc_using() <Keybuk> ...with realloc <Keybuk> ...with failing realloc <Keybuk> BAD: wrong value for ptr, expected 0x401a7d got (nil) <Keybuk> at tests/test_alloc.c:103 (test_alloc_using). <Keybuk> zsh: abort (core dumped) ./test_alloc <Keybuk> \o/ <Keybuk> much more useful test case output <_ion> Cool. <_ion> And yay for using zsh. ;-) <Keybuk> heh, I've always used zsh <_ion> There was a long period of time i had to suffer from bash, because zsh didn't support UTF-8. <Keybuk> how often did you need utf-8 on the shell? :) <_ion> Quite rarely, but when you do need it (remember i'm Finnish, non-ASCII letters are used in our language), it's nice if it works. :-) <zod> i wanted to test upstart on archlinux but if i use a different prefix to build the package it fails with the following error <zod> libtool: install: error: cannot install `libupstart.la' to a directory not ending in /usr/lib <Keybuk> zod: how did you compile it? <zod> ./configure --prefix=/opt/upstart --sysconfdir=/etc <zod> and it fails on make install <Keybuk> odd <Keybuk> which version? <zod> 0.3.0 <zod> i use "make DESTDIR=$startdir/pkg install" to build a package <Keybuk> startdir? <zod> the directory where the files should go so i can build the package <Keybuk> can you copy everything out of your terminal into npaste? <Keybuk> it worked for me <Keybuk> (ie everything from the configure line through to the failed bit) <zod> http://nopaste.php-q.net/259171 <Keybuk> you ran "make" before you ran "configure" ? <zod> ehm nope <Keybuk> there's no "make" output in that paste <zod> oh my fault :( <zod> i used ./configure, ran make, changed ./configure without cleaning up <Keybuk> so you built it with /usr/lib as the prefix :) <Keybuk> which is why it failed <zod> damn stupid ;) <Keybuk> nih/tests/test_list.c | 790 +++++++++++++++----------------------------------- <Keybuk> sweet <Keybuk> new test framework makes the test files much smaller #upstart 2006-12-06 <Keybuk> 2 files changed, 232 insertions(+), 619 deletions(-) <Keybuk> muahaha <_ion> :-) <Malte> can someone read what i am typing? <_ion> Nope. <_erebos> hello, someone available for a question? - maybe i found a bug. <_ion> Well, you've already asked two questions. Feel free to ask more. :-) <_erebos> when starting a job there is a message stating the process id (eg 13788) but when ich ckeck with "ps -ef" i see that the PID of that job actually is the one stated incremented by 1 (13789) ... <_ion> The first guess that comes to mind is that it forked. <_erebos> that's why i think that "stop <job>" doesn't work because the PID is wrong ... the process is never killed <_ion> IIRC upstart doesn't know how to find the pid of a forked process just yet (please correct me if i'm wrong). <_erebos> forked ... well i have to look it up (i am from germany and new to linux) <Keybuk> _ion: that's correct <_erebos> oh well ... maybe u mean that the program (in my case proftpd) is started by upstart and then starts a subprocess, am i right <Keybuk> it's a planned feature; but for now, processes must remain the foreground to be supervised <_erebos> kk <Keybuk> (this is true of other init systems as well) <_erebos> then i#ll wait for future releases ... <_ion> erebos: Look at the program's man page, there might be a switch for not forking. <Keybuk> you can start proftpd with the -n switch <_erebos> kk thx ... i'll try that ... <Keybuk> respawn /usr/sbin/proftpd -n <_erebos> worked .. :) thx * Starting logfile irclogs/upstart.log <_erebos> is there a list of yet recognized events? <_erebos> okay ... according to the code there are currently NO other events than the 5 basic events ... :( <Keybuk> make up your own <Keybuk> initctl emit EVENT-NAME <_erebos> worked ... :) but you meant initctl trigger EVENT-NAME <Keybuk> depends on the version of upstart <_erebos> kk ... i have 0.27 and you are probably ahead with 0.30+ ;) <Keybuk> yes <treepio> Anyone got a great guilde for a minimal working system?. I want to make it but using upstart instead of normal sysvinit #upstart 2006-12-07 <quappa> hello. is there a way to know if I upstart is ok after upgrade to Edgy? I don't see any change in startup time. People on forums say it's dramatic. <quappa> s/if I/if/ <_ion> In edgy, upstart just launches the same old sysvrc scripts. It doesn't affect startup time until the whole bootup process is migrated to upstart jobs (that's going to happen in feisty). Edgy has other changes that may decrease startup time, though. <quappa> oh. thanks. <quappa> probably those other changes didn't affect my setup. <Keybuk> Md: you'll probably like the plan to take over the world that the Ubuntu Kernel Team and I are cooking up :p <Md> Keybuk: --verbose <Keybuk> Md: moving the decision about which devices get bound to which drivers to userspace <Keybuk> so udev is responsible for it <Md> how? <Keybuk> first, with .20 and a couple of patches, ensure that drivers are first class sysfs objects with uevents, etc. <Keybuk> then modify the module information so that a module announces which drivers it contains, and maps modaliases to driver names instead of module names <Keybuk> alias pci:blahblah pci:drivername <Keybuk> alias pci:drivername modulename <Md> but is this needed for every driver? <Keybuk> finally merge modprobe into udev (using kay's patch) so we can lookup this in udev <Keybuk> I think that the first two are very useful for every driver <Keybuk> the third bit is also useful, because you can use udev to force a bind or unbind <Keybuk> as to which drivers we make the decision for, I don't think it makes much difference; we could leave the easy decisions up to the kernel, and just do the hard ones in userspace <Keybuk> but I don't think there's any drawback to doing it all in userspace <Md> performance? <Keybuk> I don't think that the bind between a device and driver is ms critical? <Md> no, but when you load 30 drivers at boot time maybe it starts to be noticeable <Keybuk> udev is going to get called out anyway for those 30 devices #upstart 2006-12-08 <wasabi__> Keybuk: you around? <Keybuk> yup <Keybuk> what's up? <wasabi__> initramfs questions. Trying to boot a system, which seems to be fairly broken. At some point during the initram, the HD's get probed... repeatidly (as indicated by lights blinking on then off for 1 sec on the drives) <wasabi__> Trying to pinpoint it <wasabi__> break seems to get me there. <wasabi__> can I continue after breaking? <Keybuk> yeah, just exit the shell <wasabi__> hmm. gave me a panic last time I tried thta <Keybuk> which release? <wasabi__> feisty <wasabi__> looks like udev isn't kicking off. <wasabi__> it's um... the latest daily. I have this wonderful system here which has an intel d965. <wasabi__> So, nothing less than 2.6.18 works on it. ;0 <wasabi__> The problem i was having is the device nodes weren't being created before mdadm ran <wasabi__> I ran udevd --daemon;udevtrigger;pkill udevd manually during premount <wasabi__> and then exit 0, and it continued, and worked. <_ion> There used to a problem with the run order of udev, lvm and md stuff, but i thought it was already fixed. <wasabi_> yay new working system <wasabi_> sorta. <Keybuk> oh <Keybuk> anything to do with lvm, md, evms, etc. is totally busted in feisty :p <wasabi_> nice. <wasabi_> well, got it working by hand... until i reboot again * wasabi_ sticks udevd --daemon; udevtrigger; pkill udevd into local-top/mdadm * wasabi_ snicker <Keybuk> doesn't it PREREQ="udev" ? <wasabi_> Yeah <wasabi_> Which doesn't exist in local-top <Keybuk> weird <wasabi_> Ahhhh. <wasabi_> udev is now in init-bottom and init-premount. <wasabi_> and not in local-top. <Keybuk> right <Keybuk> those happen first <Keybuk> well, premount does <wasabi_> how do the prereq's work though? <wasabi_> Aren't they only within the one script subdir <Keybuk> wonder if it's looping because udev doesn't exist :p <Keybuk> yeah <wasabi_> so, the prereq "udev" is unfulfillable. <wasabi_> ahh, yeah. <wasabi_> it's looping. <wasabi_> hence the HD noise. ;0 <Keybuk> right <Keybuk> that's the bug then <treepio> Trying to make upstart-0.3.0 but I get alot of errors with: ./configure --prefix=/tree/temp/upstart --sysconfdir=/tree/etc -->some of my errors: make[2] : ***[cfgfile.o] error 1, + alot of cfgfile errors <Keybuk> treepio: we'd need to see the actual errors <treepio> on another system, I hatve to type em all :) <Keybuk> unfortunately we can't see the other system's console, so don't know what they are unless you type them :-/ <treepio> ../nih/io.h:221: warning: 'warn_unused_result' attribute directory ignored <Keybuk> that's just a warning <treepio> cfgfile.c:880: error: 'RLIMIT_NICE' undeclared (first use in this function) <treepio> cfgfile.c:880: error: 'each undeclared identifier is reported only once), cfgfile.c:880: error: for each function it appears in), <treepio> cfgfile.c:880: error: 'RLIMIT_RTPRIO' undeclared (first use in this function) <AlexExtreme> missing include? <treepio> those are my 4 errors. Looks like I have made some basic mistake somewhere. alot of warnings and stuff <Keybuk> hmm <AlexExtreme> hmm <Keybuk> which version of kernel, glibc and gcc are you using? <AlexExtreme> does /usr/include/bits/resource.h exist for you? <Keybuk> those two limits were added in ~2.6.12 and I guess glibc 2.3.6 <treepio> resource.h exist <treepio> kernel 2.4.31, gcc 3.3.6 .. checking glibc. <AlexExtreme> ah <AlexExtreme> 2.4.31 probably won't work, if they were added in 2.6.12 <Keybuk> yeah, wayyyyy too old version of Linux :) <treepio> glibc: 2.3.5 <AlexExtreme> definitely too old :) <treepio> bah :).. I'll boot into another system and try :) <AlexExtreme> what distro are you using, out of curiousity? <treepio> this isslackware <AlexExtreme> which ver? <AlexExtreme> 10.0? <treepio> 10.2 <AlexExtreme> ah <Keybuk> upstart needs 2.6.12 or later, gcc 4, glibc 2.4 etc. <Keybuk> slackware still ships with 2.4 kernel?! <treepio> ok, let me see what fedora has <AlexExtreme> 11 ships with 2.6 afaik <AlexExtreme> but patrick really didn't want to have 2.6, don't ask me why :/ <Keybuk> upstart isn't much use without 2.6 anyway <treepio> probably because he had to do alot of work :) <Keybuk> the entire point is that you'd want to use it with udev <treepio> I just want to try and build a system, and decided upstart looked nice, ruby and all. <Keybuk> most recent version of Ubuntu, Fedora and SuSE are all suitable <Keybuk> Debian etch should be as well I believe <treepio> I have FC5 on the comp I'm testing with <AlexExtreme> btw Keybuk, when will development on all these fancy new upstart features start? ;) <Keybuk> AlexExtreme: I'm working on some of the lower level library changes at the moment <AlexExtreme> cool <Keybuk> I imagine I'll get to upstart next week, and probably do the bulk of them over december <AlexExtreme> sounds good <treepio> kernel: 2.6.18xxx, glibc: 2.4, gcc: 4.1.0 <AlexExtreme> also, how do you get udev to emit events upon device additions/changes? add calls to initctl in the rules files? <AlexExtreme> treepio: that should work <treepio> AlexExtreme: thanks, I will try again <Keybuk> AlexExtreme: yeah <Keybuk> I plan to patch udev to do it directly as well <AlexExtreme> ok <AlexExtreme> and one last question: will the development of the replacement initscripts take place in the respective packages themselves or in a bazaar/cvs/svn/whatever repo? <Keybuk> depends for which packages? <Keybuk> they'll certainly be shipped inside those <AlexExtreme> hmm <AlexExtreme> ok <Keybuk> but I suspect it'll be sensible to have a bazaar repository of them for people to use <AlexExtreme> yes, definitely <treepio> It's hard to learn the basics of linux.. <treepio> No errors this time though, thanks. <AlexExtreme> :) <treepio> can I jsut take the example files and throw in event.d and just change the disk layout? <AlexExtreme> no <AlexExtreme> the example files are for ubuntu <treepio> oo <treepio> :/ <Keybuk> replacing the init daemon of your system is quite a big undertaking for a novice <treepio> I have made my disk layout, fstab and inittab. now I decided to try upstart(looks nice). do I have to reqrite everything ? <treepio> Keybuk: you got it right. I am a nivice in this field.. so I decided to learn it.. Have to start somewhere <Keybuk> to do upstart properly, you'd need to write everything to boot your machine, yes <Keybuk> (in particular, upstart doesn't use inittab) <treepio> Problem is that upstart is so new, it's hard to find any info on it. <Keybuk> right <Keybuk> it's still being developed <treepio> hmm. <Keybuk> we're only just at the point where we're about to begin replacing init scripts with upstart jobs <treepio> Will I need to change much to have it work on my new system?. or should I just get the old unix or messy sysvinit stuff? (I will have to learn that too, so why not learn the good looking upstart) <treepio> Wouldn't it be nice to have 17 people in here instead of 16 ;) <treepio> Especially because I want to learn ruby too <Keybuk> if you're installing a Linux machine from scratch, without any distribution, I'd definitely start with upstart <Keybuk> it's just as useful as sysvinit today <treepio> Keybuk: the other inits got alot of help and howtos. Can you help me with the files I will need to change ? <treepio> For a start maby help me to find out how many and what files need changing <Keybuk> I'm confused a little <treepio> About what <Keybuk> are you taking an existing installation of Linux and attempting to modify it to use upstart <treepio> no <Keybuk> or are you trying to build a Linux install from scratch? <treepio> I'm using an existing distro to make a new <Keybuk> right, so you're modifying an existing installation? <treepio> no, I have made a seperate partition with empty dirs added fstab inittab and so. <Keybuk> ah I see <Keybuk> the first thing is you need to throw away that inittab file <Keybuk> instead you'd need to write /etc/event.d files to match what you originally put in there <treepio> I'm a pretty good sysadmin if I should say it myself.. but this, the basics are really hard. <treepio> Probably easy once I have made it work just once.. * AlexExtreme sits and waits while KDE SVN builds... <Keybuk> you'd need to write shell scripts to check and mount the disks, etc. <Keybuk> all the usual boot-time tasks <treepio> Keybuk: I can just change a few parameters in the example jobs right. I don't need something fancy. I just want to have it working and end up with a prompt someday.. then I can check and learn the scripts <Keybuk> right <Keybuk> the example jobs are based on the Debian / Ubuntu inittab <Keybuk> you'd need to tweak them to match a different distribution (init is gloriously inconsistent) <Keybuk> that'd make sure that the existing SysV scripts (/etc/rc*.d and /etc/init.d) are still run <treepio> I will try to look up an inittab from debian/ubuntu <treepio> Do I need those?, just removed the rc.d folder I had set up .. :) <Keybuk> you don't need them <Keybuk> but you do need what they did <Keybuk> if you don't want the rc.d scripts, you'd need to rewrite them as /etc/event.d jobs <treepio> Thanks, I want it real basic. don't care about compatibility . <Keybuk> tbh, if you wanted a REALLY quick start ... <Keybuk> you only need one file in /etc/event.d <Keybuk> :) <Keybuk> ----8<--------8<--------8<--------8<---- <Keybuk> on startup <Keybuk> respawn /bin/bash <Keybuk> ---->8-------->8-------->8-------->8---- <Keybuk> :p <AlexExtreme> pff :) <treepio> huh? :) <Keybuk> that'd give you a root shell, and keep it running <treepio> hehe <treepio> I want that. <AlexExtreme> you can just put init=/bin/bash on the kernel command line for that! <Keybuk> AlexExtreme: true, but then it wouldn't be upstart supervised <AlexExtreme> although, that wouldn't respawn it and it would kernel panic when the shell exits :p <AlexExtreme> oh, and you'd need console owner ;) <_ion> ;-) <treepio> No more panics, got enough problems with my cpu fan I died up with speaker cables.. the retention bracket is broken in all 4 corners :) so I tied it up with wires.. complains about heat problems.. hehe <_ion> treepio: Upstart isn't made in Ruby, it's C code. <Keybuk> _ion: cute <_ion> Wouldn't that example also need 'console owner', btw? :-) <Keybuk> yes <Keybuk> heh <AlexExtreme> i said that ;) * _ion is blind. <treepio> rebuilding upstart to the right location dunno why I made it in /tree/temp. :) <Keybuk> use --prefix=usr/ --exec-prefix=/ --sysconfdir=/etc <Keybuk> then install with make DESTDIR=/tree install <Keybuk> that'll do the right thing <treepio> ok built and ready. <_ion> /usr <Keybuk> likewise for things like libc, etc. <Keybuk> (admittedly, if I were building a Linux from scratch, I would do away with /usr <g>) <treepio> I did: ./configure prefix=/tree/usr sysconfdir=/tree/etc (where /tree is a mounted partition) <Keybuk> treepio: the problem with that is that upstart will be looking for /tree when it boots <Keybuk> which won't exist if you mount that partition as the root <Keybuk> (/tree/usr will become /usr) <treepio> auch. <AlexExtreme> ./configure --prefix=/usr --sysconfdir=/etc --exec-prefix=/ && make clean && make && make DESTDIR=/tree install <treepio> I will just rm -rf stuff again <treepio> AlexExtreme, Thanks <treepio> I will get on to installing bash, etc etc. Thanks for all your help so far. #upstart 2006-12-10 <eobanb> hi, what's the path to the upstart binary in edgy? <eobanb> i assumed it would be in /sbin/ but i dont see anything like that there. <cortana> eobanb: try dpkg --listfiles upstart <cortana> i think it might actually be /sbin/init <eobanb> oh okay * mode/#upstart [+o _ion] by ChanServ * mode/#upstart [-s] by _ion * mode/#upstart [-o _ion] by _ion <Termina> Could anyone help me out? I'm having trouble compiling upstart on slackware 11, gcc3.4.6 <Termina> I get the following error on make: <Md> upgrade gcc <Termina> cfgfile.c: In function `cfg_job_stanza': <Termina> cfgfile.c:880: error: `RLIMIT_NICE' undeclared (first use in this function) <Termina> cfgfile.c:880: error: (Each undeclared identifier is reported only once <Termina> cfgfile.c:880: error: for each function it appears in.) <Termina> cfgfile.c:888: error: `RLIMIT_RTPRIO' undeclared (first use in this function) <Termina> make[1] : *** [cfgfile.o] Error 1 <Termina> make[1] : Leaving directory `/home/will/Desktop/upstart-0.3.0/init' <Termina> make: *** [check-recursive] Error 1 <Md> upgrade your libc headers then <Termina> What version would you suggest? <AlexExtreme> upgrade gcc, glibc and kernel <Md> very recent <Termina> kernel is 2.6.18 <AlexExtreme> gcc 4.x, glibc 2.3.6 and kernel 2.6.18 <Termina> Ah, thanks :) #upstart 2006-12-12 * Starting logfile irclogs/upstart.log <Keybuk> Testing control_handle_event() <Keybuk> ==11675== Invalid read of size 4 <Keybuk> ==11675== at 0x40F3EC: control_watcher (control.c:377) <Keybuk> ==11675== by 0x407C53: test_handle_event (test_control.c:853) <Keybuk> ==11675== by 0x407D88: main (test_control.c:873) <Keybuk> ==11675== Address 0x4D92740 is 80 bytes inside a block of size 128 free'd <Keybuk> ==11675== at 0x4A20423: free (vg_replace_malloc.c:233) <Keybuk> ==11675== by 0x4A2089D: realloc (vg_replace_malloc.c:306) <Keybuk> ==11675== by 0x410A00: nih_free (alloc.c:340) <Keybuk> ==11675== by 0x41226E: nih_list_free (list.c:168) <Keybuk> ==11675== by 0x40F3D5: control_watcher (control.c:375) <Keybuk> ==11675== by 0x407C53: test_handle_event (test_control.c:853) <Keybuk> ==11675== by 0x407D88: main (test_control.c:873) <Keybuk> *sigh* <Keybuk> I hate valgrind <Keybuk> :p <AlexExtreme> :) <Keybuk> it keeps finding bugs * theCore smiles <AlexExtreme> heh <Keybuk> happily they're usually just bugs in the test suite <AlexExtreme> in other news, i just killed a box by accidentally using the wrong target when putting LinuxBIOS on it.... :p <Keybuk> oops :p <Keybuk> killed how badly? <AlexExtreme> let's just say it's my new doorstep ;) <AlexExtreme> doesn't even put anything out to the serial console <Keybuk> d'oh <Keybuk> oh, wow, that one was a real bug <AlexExtreme> uhh, Keybuk, you might wanna disable anonymous comments on your blog or something, 'cause it's insanely full of spam <AlexExtreme> :) <AlexExtreme> bbl, food <Keybuk> AlexExtreme: it doesn't have any concept of anonymous <theCore> Keybuk: http://www.netsplit.com/blog/articles/2006/11/27/slippery-slopes#comments <Keybuk> I tend to clear the feedback of spam every week or so <theCore> maybe you should add a mini captcha <theCore> Like: "What is the sum of 4 + 2:" <Keybuk> no idea how to do that <theCore> http://sw-guide.de/wordpress/math-comment-spam-protection-plugin/ <Keybuk> it's not wordpress <Keybuk> it's typo <theCore> hmm... <theCore> typo seems to be abandoned <Keybuk> how do you figure? a new version came out not long ago <theCore> well, their website is http://typosphere.org/ <Keybuk> that's not abandoned, that's "doing a new website" <theCore> click a link <Keybuk> *shrug* <theCore> it been flagged "under construction" for about 6 months now <Keybuk> do you have a better blog hosting suggestion <Keybuk> ideally Python or Ruby and MySQL <theCore> the best with Python would be to use Django, but it would a lot effort for a blog <theCore> Wordpress is really the best right now <Keybuk> Wordpress is PHP <Keybuk> the guy who hosts my website won't run PHP <theCore> ah <Keybuk> he prefers his box to not get hacked a few times a week <theCore> hehe <_ion> http://tnx.nl/php.jpg <Keybuk> I don't have the money or motiviation to have my own CoLo box <Keybuk> and certainly don't have the time to admin it <theCore> well, I could host it... <theCore> I got paid hosting <Keybuk> that wouldn't make the situation much different, I'd be still relying on someone else, and what they can provide -- and I'd be a bit stuck if I lost contact with you <Keybuk> at least thom is a close friend :) <theCore> Keybuk: I would give you the full ssh access <theCore> so, you wouldn't rely on me <Keybuk> <Keybuk> and certainly don't have the time to admin it <Keybuk> :p <theCore> hehe <theCore> ah well <Keybuk> I have ssh access now <thom> heh <theCore> Keybuk: would you like to support me for the membership? <thom> Keybuk: disallowing non-ajax comments has killed a lot of my spam <Keybuk> theCore: of ubuntu-dev ? <theCore> Keybuk: no, just ubuntumember <theCore> I going to next, in #ubuntu-meeting <Keybuk> thom: yeah, I've enabled that and "max links" <theCore> to be the* <Keybuk> meh, CC week <Keybuk> theCore: sure <theCore> thanks <theCore> hopefully, I won't cut by everyone else ... <thom> Keybuk: nods <AlexExtreme> back <Keybuk> do I need to say anything? :p * Keybuk isn't sure how these things work <g> <theCore> Keybuk: thanks <Keybuk> theCore, Amaranth: congrats <theCore> thanks <Amaranth> thanks #upstart 2006-12-13 <Keybuk> thom: no new spam since requiring ajax comments <Keybuk> sweet <thom> noice <Keybuk> now I just have to delete the 50 pages of spam that appeared in the last week <g> * Keybuk wishes there were a way to increase the page size <thom> heh, yeah, did that for trackback spam yesterday <thom> presumably page size is template dependent? <Keybuk> no idea <Keybuk> I mean the size of the feedback admin page <Keybuk> 40 is too low <thom> ah, right <thom> yeah <Keybuk> thom: (re: laptops) I'd guess you'd be championing the Lenovo still? <thom> yep, my x60s is awesome love <thom> (and core 2 duo parts should be available soon) <Keybuk> still no touchpad though <thom> feature not bug <Keybuk> for you maybe <Keybuk> I can't use the nipples <thom> that explains a lot *g* <Keybuk> the Dell D420 looks nice <thom> but Dull. <Keybuk> why Dull? <thom> generic term for dell, innit. i've never been impressed with their build quality <Keybuk> the build quality of the new Lenovos some people had at UDS didn't look great either, tbh <thom> and i know what you do to laptops <Keybuk> the new HPs looked fairly rugged <thom> yeah? not seen one <Keybuk> and jdub's Dell looked pretty rugged too <thom> the lenovos around here have taken some pretty hefty battering <Keybuk> someone had one of the new T? series Lenovo - 15" thing <Keybuk> the case had already cracked, and they'd only had it a month or two <Keybuk> I don't really want a 14" laptop though, 12" is what I'm after, and Lenovo don't have a good range <Keybuk> very few options, underpowered comparatively to others in the same range, no touchpad, etc. <Keybuk> screen is somewhat small now too <Keybuk> somewhat low-res, I should say <thom> yeah, 1024x768 is about my only complaint <Keybuk> everyone with an X60 at UDS/AllHands had severe problems getting them to work with projectors <Keybuk> have you had that? <thom> never tried <thom> i'm pretty sure ross has his working though <Keybuk> AlexExtreme: ping <AlexExtreme> Keybuk, pong <Keybuk> AlexExtreme: need an e-mail address for the ChangeLog <Keybuk> is rodriguezcrystal@example.org ok? <AlexExtreme> yes, that's the right one :) <Keybuk> thanks <_ion> keybuk: Shouldn't TEST_FILE_RESET in nih/test.h have do { } while (0) around the definition? <Keybuk> _ion: yes, probably <_ion> http://johan.kiviniemi.name/tmp/nih_test.h.diff <Keybuk> thanks * Keybuk is particularly proud of TEST_CHILD <g> <_ion> Yeah, it's neat. :-) <Keybuk> TEST_FILENAME needs a do { } while (0) too <Keybuk> AlexExtreme: did you ever solve bug #69950 ? <AlexExtreme> it's a splashy bug I think <AlexExtreme> so close it if you want * ..[topic/#upstart:Keybuk] : Upstart 0.3.1 | 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 <AlexExtreme> whoo, 0.3.1 ;) <Keybuk> 28 files changed, 3020 insertions(+), 5350 deletions(-) <Keybuk> 26 files changed, 4891 insertions(+), 7806 deletions(-) <Keybuk> (upstart and nih) <AlexExtreme> cool <Keybuk> quite an impressive code changage, mostly confirmed to the unit tests :p <Keybuk> confined, even, not confirmed <Keybuk> heh <AlexExtreme> :) * AlexExtreme tests 0.3.1 <AlexExtreme> brb <AlexExtreme> seems to work ok <Keybuk> :-) <Keybuk> it's not much different from 0.3.0, other than the minor bug fixes <AlexExtreme> yeah <AlexExtreme> now, i can play with syslog-ng sometime <AlexExtreme> bbl <Keybuk> hmm <Keybuk> my machine doesn't boot <Keybuk> I'm sure upgrading to 0.3.1 is a mere coincidence <Keybuk> la la la <Keybuk> *shrug* fine that time <Keybuk> weird <AlexExtreme> back * maro reboots :) <AlexExtreme> heh, that's just annoying <AlexExtreme> i just bumped the gdm package, then a new gdm version gets release <AlexExtreme> *released <Keybuk> always the way <Keybuk> http://upstart.ubuntu.com/wiki/JobStates <Keybuk> ^ Would appreciate some eyes on that <Keybuk> I think it's finally stable and actually correct * AlexExtreme looks <maro> ah, nice, initctl list looks normal again :) <AlexExtreme> Keybuk, looks fine to me <AlexExtreme> (nice diagram, btw ;)) <Keybuk> wasabi: ^ <wasabi> hi <wasabi> oh ok <Keybuk> does that look right? <wasabi> reading <_ion> keybuk: Looks good. <wasabi> Keybuk: Random little thought I had while falling asleep. How does the system shutdown right now? <wasabi> And how should it shutdown? We've talked a lot about starting, but what about system teardown? <wasabi> There are two things I see, the teardown of existing jobs, then the execution of new jobs to put the machine into an off state <wasabi> There's obviously the shutdown signal? How should that be used appropiatly? <Keybuk> one moment <wasabi> I was just modeling it in my head... Say you have a "poweroff" task. Should that task be invoked on a signal named "shutdown"? Or is that task something which the user executes (by starting it using a control) <wasabi> s/signal/event/ <wasabi> If it was a task, it could do stuff like: for each mounted file system { emit file system unmounting; unmount; emit file system unmounted; } signal kernel to power off. <wasabi> The unmounting of every file system in turn obviously causes everything to stop. <Keybuk> right <Keybuk> so there's a couple of distinct parts to this <wasabi> And it can of course block on emitting both signals, causing it to wait until everything is shutdown. <wasabi> That introduces another interesting thing. Windows has this thing where some services consciously do not stop on poweroff. They don't go through the effort of anything. The system just powers off. <wasabi> They get the stop signal, but know it was caused by the system powering down, and so don't do any work. <wasabi> filesystem unmounted will be available to those jobs that start explicitly because of it, but it's also not a good indicator of the reason for the file system being unmounted. <wasabi> events being causes by other events, etc. Makes me wonder if $UPSTART_JOB should represent that stack. =) <wasabi> Err, $UPSTART_EVENT <wasabi> # The primary process is run when entering the start <wasabi> state. <wasabi> there's no "start" state defiend on the graph, just "exec process" <wasabi> minor inconsistency i suspect <wasabi> I really do feel that all events emitted internally should block though. <wasabi> perhaps just for consistency. <Keybuk> sorry, juggling a dozen things at once <wasabi> s'ok, me too <Keybuk> so right, two distinct parts <Keybuk> one is the services that are running; those I think will be defined in terms of other things <Keybuk> we can largely ignore them from a startup pov. because they're started as a side effect of things like "fhs filesystem", "networking", etc. <Keybuk> likewise I think we can ignore them from a shutdown pov, because they're stopped as a side effect of the same things going away <wasabi> yup <Keybuk> the side effect here is that it'd negate teardown a little <Keybuk> otoh, they'd all happen in parallel and most wouldn't have post-stop scripts <Keybuk> the goal of teardown was to avoid shell scripts that just did kill -TERM with some time-wasting stuff <Keybuk> we did the kill -TERM *anyway* since we sent kill signals <Keybuk> the real problem is the shutdown tasks <Keybuk> the mirror of the startup tasks <Keybuk> the startup tasks are chained off "startup", and do things like mount the filesystems <Keybuk> I think likewise, the shutdown tasks are chained off "shutdown" and do things like unmount them <wasabi> Is shutdown in fact an event? <wasabi> I know it is now. <wasabi> Is that right, is that proper? <Keybuk> it is currently <Keybuk> I think it has to be, as you need to do something to start bringing things down <wasabi> That seems more like using shutdown as a method call. <Keybuk> I tend to think of events as method calls anyway :p <wasabi> Heh. <wasabi> If "shutdown" was a job/task, would that be any different/better/whatever? <wasabi> Other than looking stupid: <wasabi> initctl shutdown start <Keybuk> I think that having it as a job is a little less flexible <Keybuk> you could only do one thing with it, by modifying that task <Keybuk> by having it as an event, you can write any number of tasks to happen simultaneously <wasabi> Well, depends how you want to take it. What happens, in what order, on shutdown? <Keybuk> e.g. bring the filesystem and network down at once <Keybuk> shutdown is tiny <wasabi> You can do that too. The task can emit furthur signals. <Keybuk> kill all processes <Keybuk> unmount filesystems <wasabi> With more specific meanings. <Keybuk> reboot() <wasabi> Are we commiting to reversing the killall processes with unmounting file systems? <Keybuk> right, but I think that it's better that if a distro wants to do that, they write a task that emits those signals "on shutdown" <Keybuk> more flexible <Keybuk> reversing? <wasabi> hmm. <wasabi> well, we are no longer going to kill anything in direct response to shutdown. <wasabi> Them stoppnig will be a byproduct of their dependencies becoming unavailable: <wasabi> networking, file systems. <wasabi> That's what makes me think about the shutdown task. <Keybuk> you'd still need an equivalent to "killall -TERM" <Keybuk> otherwise you can't unmount the filesystems <wasabi> It can do the work of unmounting the file systems, which indirectly emit filesystem-unmounting, and bring down services. <_ion> Can't you do a lazy unmount? <wasabi> And then it can do the work of killall -TERM. <wasabi> Where is that work going? <Keybuk> _ion: shutdown ... kinda critical it happens before we power off :p <wasabi> Hmm... interesting thing, we aren't actually unmounting file systems on shutdown, either... <wasabi> We are just making them RO, aren't we? <Keybuk> wasabi: I figured there'd be a shutdown task started by the shutdown event :) <Keybuk> wasabi: currently we unmount them <Keybuk> we make the root ro <wasabi> even /? <_ion> kebyuk: Ah. :-) <wasabi> And there is some sort of guarentee that /bin is on the same fs as / <wasabi> heh <wasabi> guess there'd have to be he <wasabi> and /usr shouldn' tmatter. <Keybuk> yeah, you can't have /bin and /sbin different to / :) <Keybuk> otherwise you don't have /sbin/init and /bin/sh <g> <wasabi> So, the shutdown task loops file systems, determines which it should unmount, does so, resulting in services stopping. <wasabi> I'm thinkiing this <Keybuk> windows services knowing stop was caused by poweroff ... <Keybuk> we have that now in two ways <Keybuk> 1) UPSTART_EVENT = "shutdown" <wasabi> for fs in / /usr /usr/local /var /whatever_some_user_has; do ( initctl emit fs-bye-bye $fs *BLOCKING*; umount $fs; initctl emit fs-gone ) *; done <wasabi> Err, that last * should be a & <Keybuk> 2) any event after shutdown (or not) can be matched using complex-event-config <wasabi> UPSTART_EVENT won't == shutdown. <wasabi> It will equal something sill like network-going-away <Keybuk> right <wasabi> s/sill/silly/ <wasabi> Which is what makes me wonder. Should UPSTART_EVENT be the stack? <Keybuk> it could be <wasabi> That wa you could go if [ $UPSTART_EVENT starts with "shutdown" ] <Keybuk> start state defined on graph => it's defined as the name of the "exec process" node in the text below the graph <wasabi> Another interesting thing... from the "shutdown" task. <wasabi> If it sees that an event it emits breaks, such as fs-umounting, it can revert. <wasabi> If /usr can't be umounted, it can log, then remount everything. <wasabi> or just issue "startup" again. <Keybuk> right <wasabi> That can go all the way down to being unable to remount / ro <Keybuk> started/stopped being blocking events => while it would be "consistent", they wouldn't actually block anything <wasabi> quite interesting. ;) <Keybuk> the interesting thing about the starting/stopping events is that they can actually block the job from starting or stopping <Keybuk> started/stopped are emitted at the end of a state transition -- so if they block, it has absolutely no effect <wasabi> That's true. <wasabi> You are right. ;) <Keybuk> so it'd be an extra code headache to produce no discernable effect :p <wasabi> I guess, what I'd be afraid of, is by making shutdown an event, is that other software will in fact attempt to shut itself down on shutdown. <Keybuk> no worry about that <Keybuk> e.g. getty :p <wasabi> When it should really not do so, it should wait for it's required resources to go away <wasabi> And I think there needs to be one entry task for the procedure of shutting down... so it can do network/filesystem/whatever and detect failures to revert both. <wasabi> network for instance doesn't go down in response to an event, it goes down because something tells it to. <Keybuk> (back in 15-30 min) <Keybuk> ok <Keybuk> yeah for the most part I agree <Keybuk> I think the reason I dislike having a forced shutdown task is that it's ... icky <Keybuk> of course, I guess we could define neither in upstart, and just let distros decide whether they do "initctl start shutdown" or "initctl emit shutdown" <Keybuk> but again, that's kinda icky, because it removes some consistency <Keybuk> they'd all have a different /sbin/shutdown <theCore> how often the bzr branch (http://bazaar.launchpad.net/~keybuk/upstart/main/) is sync'd? <Keybuk> te <Keybuk> theCore: dunno, hourly or so I guess <theCore> rev 23? <Keybuk> 297 <Keybuk> syndicate scott% bzr revno http://bazaar.launchpad.net/~keybuk/upstart/main/ <Keybuk> 297 <theCore> oh.... <theCore> nevermind <Keybuk> did you bzr pull? <theCore> yes <theCore> the tree is sync'd <Keybuk> ...but...? <theCore> bzr's wasn't clear <theCore> bzr's output <theCore> Using saved location: http://bazaar.launchpad.net/~keybuk/upstart/main/ <theCore> All changes applied successfully. <theCore> 23 revision(s) pulled. <theCore> I thought it was rev23 <Keybuk> ah, heh <Keybuk> nah, it means you got 23 new revisions <Keybuk> top one should be NEWS: Updated <theCore> yeah, I figured it out <theCore> bzr log -r 10..23 <theCore> was kinda weird <Keybuk> bzr log -r $(($(bzr revno) - 23).. <Keybuk> err <Keybuk> bzr log -r $(($(bzr revno) - 23)).. <Keybuk> :p <theCore> ah, I just found better way <theCore> bzr log -r -10... <theCore> er, bzr log -r -10.. <Keybuk> ooh <Keybuk> that's shiny <Keybuk> I didn't know about that <g> <theCore> me, either <Keybuk> theCore: pushed the "Bump version to 0.3.2" revision <Keybuk> see how long that takes to show up <theCore> ah, I know what I am going to do <theCore> I will translate upstart in French :) <Keybuk> sweet <Keybuk> I haven't yet worked Rosetta out <Keybuk> I'm vaguely nagging for it to just have a bzr branch with the translated po files on it :) <Keybuk> so I can just bzr merge http://rosetta.launchpad.net/products/upstart <Keybuk> :p <theCore> oh <Keybuk> I click a button, it sends me a tarball <Keybuk> all seems a bit ... primitive <theCore> Writing in French with a English keyboard is painful <theCore> I almost never write in French <theCore> I only speak it #upstart 2006-12-14 <Keybuk> interesting <Keybuk> upstart's tests consistently fail on the buildds <Keybuk> (null):alloc.c:416: Assertion failed in nih_alloc_size: ptr != NULL <Keybuk> FAIL: test_file <Keybuk> passed on powerpc and sparc <Keybuk> failed on both real architectures, and itanium <drakeoutlaw> hi all, can we boot to a non gui console with the single command? <drakeoutlaw> !single <Keybuk> drakeoutlaw: depends on the distribution; which are you using? <drakeoutlaw> edgy, but there is no /etc/inittab <Keybuk> yes, you can still use "single" to get to single-user mode <drakeoutlaw> ok, but how to change the default run level? <Keybuk> see /usr/share/doc/upstart/README.Debian.gz <drakeoutlaw> ok willdo <Keybuk> hmm <Keybuk> again I can't help but think that "failed" shouldn't be a separate event, but should be an argument to the "stopped" event <Keybuk> (or stopping) <wasabi> Keybuk: I agree with that. It makes the job easier for other people who want to know when the job is "no longer running" <wasabi> Without having to explicitly say stopped or failed <wasabi> And most dependencies care about the fact that the server is gone, less about the particulars about why it is gone. <Amaranth> so can we actually start writing useful jobs or whatever with 0.3? :) <Keybuk> well, failed was always going to be followed by stopped <Keybuk> the reason I was thinking of merging them is that there's no way right now to say "until this job succeeds" <Keybuk> e.g. ntpdate, you only want to run once <Keybuk> on network-interface-up and from startup until $NTPDATE_DIDNT_FAIL <Keybuk> Amaranth: that's the intent <Keybuk> 0.2 was "let's see if the daemon code works, and is sound in principal" <Amaranth> heh <Amaranth> i'll have to look into converting willowng to use it <Amaranth> although it's not particularly complex, just starting and stopping, no fancy stuff <Keybuk> that's a dbus service? <AlexExtreme> hmm, Keybuk: when you do that rodriguezcrystal@example.org, will there be any way of seeing a video/audio of the talk? i'd quite like to see it but I can't easily get to Australia for it ;) <Keybuk> I've no idea <Keybuk> I suspect, given jdub, that they'll all be live streamed or something <Keybuk> I'm in the big hall, so it's possible <AlexExtreme> great <Keybuk> Amaranth: looking at the willowng package in edgy; it'd be something like <Keybuk> start on started dbus <Keybuk> stop on stopping dbus <Keybuk> exec /usr/sbin/willowng <Amaranth> yeah, real simple :) <Keybuk> I'd probably write it as <Keybuk> from started dbus until stopping dbus <Keybuk> respawn /usr/sbin/willowng <Keybuk> so it gets respawned as well; and acts statefully <Amaranth> wow, i love upstart <Amaranth> the init script is like 20 lines of garbage <Amaranth> that's 2 lines that tell you exactly what's going on <AlexExtreme> yeah <AlexExtreme> it's the simplest i've ever seen <AlexExtreme> none of the other "next-gen" init systems do that as simply as that <Amaranth> There is a lot of magic behind the scenes to make things that simple, I'm sure. <AlexExtreme> see the specifications for upstart on launchpad ;) <Keybuk> I like reading the really old specs, and being amused by how much has changed in a year <AlexExtreme> yeah <Keybuk> the PDF on the upstart website is particularly good <g> <Keybuk> "The basic design of upstart is that tasks exist in one of three states:" <Keybuk> we have something like 8 now <AlexExtreme> :P <_ion> :-) <Keybuk> and that goes on about "edge events" and "level events" <Keybuk> we do still need to rename /etc/event.d <AlexExtreme> why's that? <Keybuk> it's not very descriptive of its content <Keybuk> it contains definitions of services, tasks and states <Keybuk> not events :) <AlexExtreme> so, servicetaskstate.d? :) <AlexExtreme> gotta go <Keybuk> http://opensolaris.org/os/project/smf-profiles/;jsessionid=A8CF91BE41ED07443BFA5A4F686515D0 <Keybuk> interesting #upstart 2006-12-15 * ..[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 <Keybuk> phew <Keybuk> it looks like the upstart test failures on the buildds is caused by EELMO <Keybuk> I suspect their kernels have inotify disabled <maro> EELMO? <Keybuk> elmo likes to build custom, module-less kernels <maro> oh, heh :) <_ion> Why not just run stock kernels on buildds? <Keybuk> because they scare him <wasabi> fear is a mind killer, or something <Keybuk> heh <wasabi> nice. on site interview next week. * wasabi cheer. <Keybuk> wasabi: sweet <steev64> the Getting Started page link to example jobs is 404 <Keybuk> fixed <steev64> thanks :) <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 <Keybuk> seems to be quite popular :) * Keybuk peers at libdbus * AlexExtreme prods at libdbus <AlexExtreme> not one of my favourite libs... <AlexExtreme> ;) <Keybuk> I like it about as much as implementing my own IPC <Keybuk> not very much <AlexExtreme> heh <Keybuk> trying to decide whether the init/initctl communication should be done with a peer-to-peer libdbus connection <Keybuk> and whether that'll make it easier on the code at each end <AlexExtreme> but still, upstart already has it's own IPC which works for the purpose intended, why change it? <Keybuk> because it's a pain in the arse <Keybuk> in fact, upstart has two different IPCs <AlexExtreme> oh? <Keybuk> the one it uses between init and initctl <Keybuk> and the one it uses when it re-execs itself after an upgrade to transfer job/event state <Keybuk> I'd rather there was just one <AlexExtreme> ah <Keybuk> and I'd rather that one was actually easy to deal with <Keybuk> e.g. right now, to send job information from one process to the oehter <Keybuk> upstart packs that into an UpstartMsg struct <Keybuk> which has a UpstartJobStatusMsg struct inside it <Keybuk> message->job-status.name = ... <Keybuk> and tags the UpstartMsg struct with the type <Keybuk> message->type = UPSTART_JOB_STATUS; <Keybuk> then has to arrange for that to be sent asynchronously to the requesting/subscribed process <Keybuk> so it has to _COPY_ that structure into a ControlMsg struct for each process that could receive it, a field at a time <Keybuk> when the socket is writable, it then grabs the info, and packs it into an iovec buffer <Keybuk> and writes it to the receiving process <Keybuk> which has to unpack the iovec buffer into an UpstartMsg struct <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) ? <Keybuk> examine the type to determine what message type it is <Keybuk> unpack the info from the message->job_status struct back into a Job <Keybuk> and only then decide whether *it* needs to send a reply <Keybuk> etc. <Keybuk> yeah <Keybuk> it's a pain in the arse :p <AlexExtreme> sounds like it :) <Keybuk> I'm not sure that something like libdbus is any better though <AlexExtreme> hmm <Keybuk> I suspect the problem is the method of IPC <Keybuk> e.g. "send me the status of job FOO" => "bulk reply of job foo" <AlexExtreme> bbl <eMish> I have several questions about updtart <eMish> upstart <eMish> (1) Does it come without automatic convertor of inittab to it's /etc/event.d ? <eMish> (2) DO I need to convert all of /etc/init.d, /etc.rcN.d to /etc/event.d ? <eMish> (3) can upstart run alonside with old init ? <Keybuk> 1 - the ubuntu package has one that handles getty and control-alt-delete changes <eMish> not kuubuntu, the upstart itself <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 <Keybuk> 3 - what do you mean by "old init" ? <eMish> ok, actually I'd prefer (3), running it alongside existing init then. Can I ? <Keybuk> eMish: the tarball itself doesn't contain the perl script, mostly by omission at the moment <Keybuk> eMish: the existing /sbin/init -- or the existing /etc/init.d stuff? <eMish> yes <eMish> doesn't upstart want to overwrite it ? <Keybuk> yes to which? <eMish> i compiled upstart and saw that upstart contains init <eMish> is it supposed to be a replcement for /sbin/init and the inittab ? <eMish> can I run upstart alongside with existing /sbin/init ? <Keybuk> it's a replacement for /sbin/init <eMish> can I run upstart alongside with existing /sbin/init ? <Keybuk> so no, you cannot run it alongside the existing one <eMish> fuck <eMish> anyway <Keybuk> you can install it to a different location, and alternate between them at boot time <eMish> heh <eMish> it's OS <eMish> anyway <Keybuk> ie. --prefix=/opt/upstart then boot with init=/opt/upstart/sbin/init <eMish> no, that's irrelevant <eMish> i want old init and upstart together <Keybuk> what's the context for wanting to run it "along side" ? <eMish> heh <eMish> wait <eMish> does upstart has ability to specify, per job, a "health-checking script" that tells if process is ok or needs to be restarted ? <eMish> and that needs to be run periodically ? <Keybuk> it's a planned feature, yes <eMish> good <Keybuk> (upstart's still in
{'channel': 'upstart', 'month': 12}