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