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 > > -- > 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
