Init : someone could comment this ?

Rudolf Kastl che666 at gmail.com
Fri Jan 11 12:55:50 UTC 2008


On Jan 11, 2008 7:36 AM, Andrew Farris <lordmorgul at gmail.com> 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 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
> ----                                                                       ----
>
> --
>
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>




More information about the fedora-devel-list mailing list