[02:36] <rich3krow> hi, upstartians.  Has the subject of addressing the rpm package "initscripts" cropped up somewhere?  I'd be happy to have a pointer to it.
[02:36] <rich3krow> or the subject of upstart on say fedora core 5?
[02:47] <Md> I do not remember reading anything about upstart and RPM-based distributions
[02:47] <Md> except that so far the red hat people are still looking at upstart and waiting to see if it will be adopted by others or crash and burn
[02:48] <rich3krow> I expect a lot of people are doing that.
[02:50] <rich3krow> What would be great is to have a parallel implementation so one could choose to do either.  Say, "init 7" or "init 8" or "init 9" would be the upstart equivalent of inits 1, 3, and 5
[02:50] <rich3krow> i believe [789]  are unused
[02:51] <rich3krow> much like if your kernel crashes, grub will let you use a former kernel, replete with its modules
[02:52] <rich3krow> well, i really need to read an in-depth doc and/or implementation, guess I should (1) d/l 6.10 of Ubuntu (I saw my first Ubuntu billboard Sunday!  Going north on 101 toward SF) and (2) inspect if
[02:52] <rich3krow> it
[06:09] <Luna-Tick> Hello all. I'm looking at my bootchart and seem to have 2 x 5secs where the processor and disk do absolutely nothing. It seems that this could be to do with fsck. A copy of my bootchart can be found here https://wiki.ubuntu.com/LaptopTestingTeam/DellInspiron510m?action=AttachFile&do=get&target=bootchart-edgy-20060920-7.png
[06:10] <Luna-Tick> I'm running Edgy Beta
[09:56] <Keybuk> good morning
[11:02] <uhmmm> so.. is this upstart likely to change our linux lives?
[11:04] <Keybuk> upstart is like a change of toothpaste
[11:04] <Keybuk> the benefit is feeling fresher throughout the day
[11:04] <uhmmm> great answer
[11:05] <uhmmm> now I know what to expect from it
[11:05] <Keybuk> heh, could you be more specific with your question?
[11:06] <Keybuk> it's sufficiently broad that it's difficult to answer
[11:07] <Keybuk> the change for users are that their system is a little more flexible to their needs
[11:07] <Keybuk> the change for developers is that it's much easier to make the system more flexible
[02:14] <gebi> hi all :)
[02:37] <gebi> i've a question regarding upstart, whats the intended mechanism in upstart to preserve starting services
[02:37] <_ion> Preserve?
[02:37] <gebi> e.g just because a server has a graka i don't won't the x server to be started
[02:37] <gebi> haven't read about that in the upstart doku
[02:38] <gebi> _ion: on preserve is wrong, 'keep from starting' would be better, sorry
[02:40] <_ion> 1) Don't install X to a server, 2) i proposed a "disabled" stanza to the job description syntax, but i think Keybuk has something better in mind.
[02:41] <gebi> hmm...
[02:43] <gebi> disable in the job description would really be suboptimal, just look at the (imho) mess with /etc/defaults/<service> (disable=yes) and such things
[02:45] <gebi> _ion: would upstart support different "profiles"? (where profiles mean something like a runleve)
[02:46] <gebi> suppose a user only want consolen login, or console + network access, but no daemons started (or only gpm and things needed to work with console) and ssh
[03:13] <Keybuk> these are all things we're still designing
[03:13] <Keybuk> what do you think would work best?
[03:22] <gebi> thats a bit complicated in a event based system imho, because what if a user is in "consolen mode" but now want to start into "graphic mode" (without reloading the graphic card modules)
[03:26] <gebi> idea: every so called profile consists of a file with event filters, if an event gets filtered by the rules of the profile it is saved by upstart und replayed if the user decided to switch to another profile (same for the new profile, if the event is also filtered in the new profile it is saved again)
[03:29] <gebi> but this aproach needs strict definitions which events are supposed do what, and imho also something like virtual events
[03:29] <_ion> What is a virtual event?'
[03:31] <gebi> e.g network daemons, pretty any network daemon has the same requirements (the network should be present and useable + maybe a loaded firewall), so to repetly define all such things is waste of time and divert the system because a few scripts won't get it right
[03:32] <gebi> a virtual event would something like: daemons-up which depends on a network card beeing useable + firewall loaded, this is the main event every daemon should depend on
[03:34] <gebi> the main point, for event filters to be usefull in this case you need one event every daemon depends on
[03:42] <gebi> another "problem" where the event based system simply doesn't work (imho) is if the user want's to start a specific daemon, upstart needs to figure out the right dependencies and if they are not satisfied needs to print why exactly the daemon can't be started
[03:45] <Keybuk> job "dependencies" are an interesting exercise
[03:45] <Keybuk> do you just depend on another job
[03:45] <Keybuk> or should you be able to say "apache can't start until a network card is up"
[03:47] <gebi> the second one, solaris is the best example in this respect (imho)
[03:51] <gebi> it might be possibel to use events as dependencies but this needs a more formal description on what type of events and what arguments a service depends (and no coding of this dependencies into a code section)
[09:07] <rich3krow> "Apache can't start until a network card is up"  but but but
[09:07] <rich3krow> what if I only want to use apache for local web development and I only want to use 127.0.0.1?
[09:08] <rich3krow> Oh, Keybuk has gone to bed
[09:10] <_ion> That's just a matter of configuration.
[09:11] <_ion> In that case the network interface you want apache to wait for would be 'lo'. :-)
[09:12] <rich3krow> hm, I don't even know how lo is brought up, I should dig a little.
[11:59] <rich3krow> Well, ok, lo comes up in the same way any interface comes up.  In the redhat scheme /etc/initd/network looks through files /etc/sysconfig/network-scripts, and ifcfg-lo is one of them, and it has ONBOOT=yes