Init : someone could comment this ?

Andrew Farris lordmorgul at gmail.com
Fri Jan 11 06:36:40 UTC 2008


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.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
  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
----                                                                       ----




More information about the fedora-devel-list mailing list