On Jan 11, 2008 2:43 PM, Casey Dahlin <cjdahlin@xxxxxxxx> wrote: > > Rudolf Kastl wrote: > > On Jan 11, 2008 7:36 AM, Andrew Farris <lordmorgul@xxxxxxxxx> wrote: > > > >> Les Mikesell wrote: > >> > >>> Lennart Poettering wrote: > >>> > >>> > >>>> Then, the reason I hacked this up was mostly to fix stuff like sudo > >>>> and apache, which do a lookup+reverse lookup on initialization, which > >>>> fails completely if DNS doesn't work (as in "*immediately* fail") and > >>>> the entry is not available in /etc/hosts. DNS lookups that time out > >>>> are a different problem. > >>>> > >>>> > >>>>> And it still fails in the same way, when there is no network (Ie. > >>>>> daemon can bind to a specific IP that is the "wrong" one). > >>>>> > >>>> Hmm? > >>>> > >>>> Are you suggesting that there are daemons that bind on addresses by > >>>> resolving host names? Who's doing something like that? Either daemons > >>>> should bind on 0.0.0.0 or bind to manually configured IP > >>>> adresses. Everything else is broken anyway. > >>>> > >>> There are a lot of things that can't work and will do horribly wrong > >>> things if started without a working DNS - and for reasons not related to > >>> your own hostname. Such daemons would be better off if they could defer > >>> startup until after DNS works. > >>> > >> But shouldn't these things be fixed directly by identifying what goes wrong and > >> when, and filing bugs against them upstream so that when DNS misbehaves the > >> daemons handle it appropriately. It should never be a 'working as intended' > >> behavior for a daemon to do things wrong just because DNS was unavailable... the > >> daemon should postpone its operation until it can try to resolve the hostname > >> again later, and keep doing exactly that until it works. > >> > >> In my view the init scripts should not have to handle that situation, but rather > >> the daemon itself should. Defering the startup is a hack. Maybe its necessary > >> and maybe its not, but it seems like a poor design either way. > >> > > > > > > I am just generally curious... is anyone actively working on a new > > solution? there has been talks about init system replacements now for > > years and well actually lots of discussions and ideas were expressed. > > now i am curious about if anyone is already working on atleast a full > > design document how it should work and look like (besides the old one > > page on the wiki). there are a lot of argument why not to use the > > existing solutions. some are valid some arent (as it is always). but > > what tires me personally a bit is the fact that there is no effort > > beeing done besides making the existing old sysV scripts atleast > > behave a bit according to existing standards (they were largely > > unusable e.g. for clustering before and some still are e.g. due to > > incorrect exit codes). > > If something manifested yet id be happy to take a look at it... just > > direct me to the checkout url please. > > > > > > one of the things that are often managed is upstart. yet no one even > > found it useful enough to package it for fedora at all. sure in compat > > mode it is just another useless sleeping process hanging around with > > no real benefits to it... but still, it doesent seem to be worth the > > effort to roll and maintain an rpm with it for most people. > > > > there is always lots of criticism about initng. while some of the > > things beeing said are true... some are just myths. ... personally i > > can say ... it just wfm and i also wrote lots of patches for the new > > scripts recently... booting a system in below 15 seconds with NM and > > other fancy stuff enabled is quite appealing to me (especially since > > suspend was broken alot in the last years and at some points still > > is). > > > > there are various other systems aswell. most of them are directed at > > embedded devices.... for that sysV is just pure bloat and overhead > > and usually they are missing the required scripts to be properly used. > > but ok... not really in the scope of fedora anways (looking at the > > minimal install requirements). > > > > the prcsys solution to parallelize the current sys bootup does improve > > boot performance for me while maintaining backwards compatibility to > > the existing system (with the same crappy scripts that partially > > contain undocumented workarounds) seems to be one of the rather > > unintrusive ways that dont require major changes in any ways. > > > > kind regards, > > Rudolf Kastl > > > > > > > I'm off to the FUDCon hackfest now. I'm thinking about getting some > people together to try to package Upstart. > > The prcsys solution seems to have benefits now, but in the long run it > isn't going to give us things like service management, which we should > be interested in, and it may not give us much of a speedup (theres been > some suggestion that parallelizing scripts ends up not being much of a > bonus). I fully agree with you. I just tried to point out a small overview of what is already available and what is going on actually. of course with obviously my personal opinion attached to it. If you want help packaging upstart... i can definitely help there. just talking without doing anything about the issues or atleast offering help or atleast valuable input would be somewhat cheap ;). kind regards, Rudolf Kastl > >> -- > >> Andrew Farris <lordmorgul@xxxxxxxxx> <ajfarris@xxxxxxxxx> > >> gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 > >> No one now has, and no one will ever again get, the big picture. - Daniel Geer > >> ---- ---- > >> > >> -- > >> > >> fedora-devel-list mailing list > >> fedora-devel-list@xxxxxxxxxx > >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > >> > >> > > > > > > -- > > fedora-devel-list mailing list > fedora-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
