Init : someone could comment this ?

Rudolf Kastl che666 at gmail.com
Fri Jan 11 13:54:03 UTC 2008


On Jan 11, 2008 2:43 PM, Casey Dahlin <cjdahlin at ncsu.edu> wrote:
>
> Rudolf Kastl wrote:
> > 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
> >
> >
> >
> 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 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
> >>
> >>
> >
> >
>
> --
>
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>




More information about the devel mailing list