Raskere oppstart av GNU/Linux

[Manuel]

Det er på tide å gjøre noe med den lange oppstartstiden. Unødvendige servere er fjernet, men jeg lurer på hvordan man kan gjøre oppstarten enda kortere. Det første jeg tenker på er rett og slett å starte prosessene i bakgrunnen, slik at man kjører prosessene parallellt fremfor seriellt. Sistnevnte burde være meningsløst på et multitasking-OS. Spørsmålet er da hvor jeg skal begynne; Det er klart at enkelte prosesser er avhengige av andre, f.eks må man være sikker på at nettverket er oppe før skriptene for cups og nfs kjøres. men hvordan kan nfs-skriptet vite at nettverket er oppe? Hva hvis det tar særskilt lang tid å få en ip-addresse?

[pgdx]

Hvilke distro har du? Du kan jo se om det finnes et script til din distro, jeg vet det eksisterer til Arch og til Debian-lignende distroer.

[Manuel]

Jeg bruker Debian unstable (som er oppgradert fra stable).

[Mr-CEO]

Er det ikke like greit å bare la boksen stå på da? slipper lange oppstarttider slik

[zyp]

Det finnes et prosjekt, kalt init-ng, som søker å erstatte vanlig init. Det satser på å optimere oppstartstiden.

 

Gentoo har allerede parallell oppstart i init-scriptene.

Tjenester som f.eks nfs er avhengig av at nettverket kommer opp. Scriptet for å sette opp nettverk (via dhcp) spør etter en ip. Når den får svar er nettverket oppe, og da kan tjenestene som er avhengig av det starte. Om man ikke får tildelt ip innen en viss tid så feiler oppstarten av nettverksscriptet, og da startes heller ikke nettverkstjenester opp.

 

Men som sagt, ta en titt på init-ng. Det bruker også parallell oppstart.

[olear]

Det er på tide å gjøre noe med den lange oppstartstiden. Unødvendige servere er fjernet, men jeg lurer på hvordan man kan gjøre oppstarten enda kortere. Det første jeg tenker på er rett og slett å starte prosessene i bakgrunnen, slik at man kjører prosessene parallellt fremfor seriellt. Sistnevnte burde være meningsløst på et multitasking-OS. Spørsmålet er da hvor jeg skal begynne; Det er klart at enkelte prosesser er avhengige av andre, f.eks må man være sikker på at nettverket er oppe før skriptene for cups og nfs kjøres. men hvordan kan nfs-skriptet vite at nettverket er oppe? Hva hvis det tar særskilt lang tid å få en ip-addresse?

Enkle steg for å få en rask oppstart:

 

- Fjern alt unødvendig i oppstarten (init scripts)

- Fjern hotplug og ldconfig

- Kompiler om kernelen til å inkludere bare det du trenger

- Bruk statisk IP

[Terrasque]

http://www-106.ibm.com/developerworks/linu...nxw04BootFaster

[objorkum]

Hm, står den å venter på å få IP då, om du har dynamisk? Skulle no tru DHCP-klienten vert køyrd som ein bakgrunnsprosess.

Endret 15. juni 2005 av objorkum

[Hell Toupée]

Fedora venter som bare det. Har en Windows 2000-server på jobben som er IP-servitør og det går treigt for å si det pent. Dette slår kraftig ut på antall sekunder maskina mi bruker på å støvle.

 

Edit --> leif

Endret 15. juni 2005 av Svendheim

[ways]

http://www-106.ibm.com/developerworks/linu...nxw04BootFaster

har du testet denne? står lite om det er trygt å bruke teknikken på andre system enn fedora, men jeg må vel prøve likevel (ubuntu). må bare ta tiden på nåværende oppstart først (og kanskje bli ferdig med eksamen).

[zyp]

Hm, står den å venter på å få IP då, om du har dynamisk? Skulle no tru DHCP-klienten vert køyrd som ein bakgrunnsprosess.

Varierer fra distribusjon til distribusjon. Uansett bør den vente, om du er avhengig av den f.eks for å montere nfs-volumer.

Med parallell oppstart kan den uansett vente mens andre tjenester som ikke er avhengig av nettverk starter.

I Gentoo (ikke distro-spesifikt, men jeg snakker av erfaring) kan man bytte ut nettverksscriptet med ifplugd, som vil ta seg av forespørsel av ip i bakgrunnen, også om du plugger ut kabelen og setter inn igjen. Det er ikke noe problem, så fremst man ikke bruker tjenester som trenger en tilkobling (f.eks nfs-volumer).

[kyrsjo]

En god forklaring på hvorfor initng etc. ikke er gode nok:

http://fedoraproject.org/wiki/FCNewInit

 

RH jobber i alle fall med et nytt init-system fram mot fc5. Dependencyes, parallell oppstart og DBUS er nøkkelord.

[Tafsen]

RH jobber i alle fall med et nytt init-system fram mot fc5. Dependencyes, parallell oppstart og DBUS er nøkkelord.

OT: Er ikkje FC frigjort frå RH?

[Gronz]

RH jobber i alle fall med et nytt init-system fram mot fc5. Dependencyes, parallell oppstart og DBUS er nøkkelord.

OT: Er ikkje FC frigjort frå RH?

Frigjort på den måten at RH ikke lenger eier prosjektet, men så vidt jeg vet bidrar de like mye til Fedora som før

[kyrsjo]

RH jobber i alle fall med et nytt init-system fram mot fc5. Dependencyes, parallell oppstart og DBUS er nøkkelord.

OT: Er ikkje FC frigjort frå RH?

Frigjort på den måten at RH ikke lenger eier prosjektet, men så vidt jeg vet bidrar de like mye til Fedora som før

Og godt er det. Mange flinke/engasjerte utviklere på RH!

[kyrsjo]

Fra:  Harald Hoyer <harald redhat com>

Svar-til:  Development discussions related to Fedora Core <fedora-devel-list redhat com>

Til:  fedora-devel-list redhat com

Emne:  Fedora Goals -- LSB-compliant/ideal init for FC5+ - Python test scripts for Proof of Concept

Dato:  Thu, 16 Jun 2005 13:16:15 +0200

For testing purposes and proof of concept, I have written some python

scripts as an "rc" replacement. I've done this, because I haven't seen

any code from others (where is the code of SystemServices??) and because

I want to experiment with some concepts, before something is set to stone.

 

See:

http://people.redhat.com/harald/ServiceManager/

 

The python script ServiceManager.py reads all /etc/init.d/* scripts and

creates DBUS "Service" objects. These parse the chkconfig and LSB-style

comments of their script and provide a DBUS interface to retrieve

information and control them. Note: I am new to DBUS, so forgive me, if

I haven't understood the concept of objects, interfaces and busses

correctly, yet.

 

To use the glib main_loop from python without the need of gtk (import

gtk needs a working X11 DISPLAY), I patched the dbus python bindings to

provide dbus.main_loop():

dbus-0.33-glib-mainloop.patch

dbus-0.33-99.hh.1.src.rpm

 

etc_dbus-1_system.d_rc.conf has to be placed to /etc/dbus-1/system.d/rc.conf

 

ServiceTestClient.py is a small client test app, which queries all

available services.

 

As you can see, ServiceManager.py was just started and is not ready yet,

but release early, release often. Stay tuned. Maybe someone is

interested and wants to help, or it maybe inspires others to develop a

completly other implementation.

 

Next steps I want to do:

- replace rc functionality for complete backwards compatibility

- implement the depends/requires mechanism (also with dynamic

requirements and dependencies)

- patch all initscripts to conform to LSB

- convert prefdm to an initscript which requires $authentication and

$local_dir

- create an initscript, which provides $authentication and depends on

$network, if network auth is needed.

- convert /etc/init.d/functions and /sbin/service to use the DBUS interface

 

Have fun!

 

Harald

 

--

Code, code, give me some open source code!