# Bootzeit optimieren - runlevel ausmisten

## Schinkencroissant

Hallo alle zusammen,

mittlerweile läuft mein System ja ganz ordentlich, danke dafür.

Jetzt kann ich aber sicher noch ein wenig optimieren und damit ich nicht jetzt das laufende System zerschieße, frage ich besser erst mal nach.

Meine runlevels sehen zur Zeit so aus (nach dem ich hier im Forum ja vor kurzem gelernt habe, dass es runlevel heißt, was ich mit Autostart gemeint habe, ist das Leben ohnehin viel einfacher geworden ;-) ):

```
sudo rc-update -v show

               acpid | boot                          

           alsasound | boot                          

          atieventsd |                               

            bootmisc | boot                          

             checkfs | boot                          

           checkroot | boot                          

               clock | boot                          

         consolefont | boot                          

          consolekit |      default                  

         crypto-loop |                               

               cupsd |      default                  

                dbus |      default                  

       device-mapper |                               

             dmcrypt |                               

            dmeventd |                               

             dnsextd |                               

          git-daemon |                               

                 gpm |                               

                hald |      default                  

            hostname | boot                          

             keymaps | boot

               local |      default nonetwork

          localmount | boot

               mdnsd |

  mDNSResponderPosix |

             modules | boot

               mysql |

        mysqlmanager |

            net.eth0 |      default

              net.lo | boot

            netmount |      default

      NetworkManager |      default

                nscd |

             numlock |

             pciparm |

             pwcheck |

           pydoc-2.6 |

           rmnologin | boot

              rsyncd |

           saslauthd |

                slpd |

                sshd |

            svnserve |

           syslog-ng |      default

                udev |

    udev-dev-tarball |

          udev-mount |

      udev-postmount |

             urandom | boot

          vixie-cron |      default

                 xdm |      default

           xdm-setup |
```

Mir fällt beim Booten immer wieder auf, dass er versucht auf eth0 über dhcpd sich zu verbinden, was relativ witzlos ist, da ich in den seltensten Fällen mit Netzwerkkabel verbunden bin. Kann ich die entsprechenden Punkte mit eth0 einfach rausnehmen zum Beispiel?

Vielleicht fallen Euch ja noch mehr Sachen ein, sollte mir noch etwas entscheidend wichtiges fehlen, lasse ich mich auch gerne belehren.

Einiges habe ich während der Installation einfach blindlings reingehauen, ich wusste nicht immer, was es bedeutet, oder ob es Sinn macht. Vielleicht ist auch die Reihenfolge nicht die beste.

Ich freue mich jetzt schon auf Eure Tipps und möchte an dieser Stelle noch darum bitten, dass Ihr mir dann auch sagt, warum das Sinn machen könnte, was Ihr sagt, damit ich auch was dazulerne und dann auch mal anderen helfen kann.

Vielen Dank im Voraus,

schönes Wochenende,

Schinkencroissant

----------

## Josef.95

 *Quote:*   

> Mir fällt beim Booten immer wieder auf, dass er versucht auf eth0 über dhcpd sich zu verbinden, was relativ witzlos ist, da ich in den seltensten Fällen mit Netzwerkkabel verbunden bin. Kann ich die entsprechenden Punkte mit eth0 einfach rausnehmen zum Beispiel?

 Soweit ich mitbekommen nutzt du den Networkmanager? , wenn das noch so ist, ja dann solltest du "net.eth0" aus dem default runlevel rausnehmen, also zb 

```
# rc-update del net.eth0 default
```

Doch das wird noch nicht den gewünschten Erfolg bringen, da zb "net.eth0" auch ohne es einem runlevel hinzugefügt zu haben automatisch geladen wird. (hotplug udev)

Ich würde da in der

/etc/conf.d/rc 

```
rc_plug_services="!net.*"
```

setzen, damit wird jegliches automatisches laden von "net.*" verhindert, denn das sollte ja nun bei dir der Networkmanager mit übernehmen...

MfG

----------

## Necoro

Ich würde vielleicht noch den syslog-ng vom default in den boot runlevel schieben. Denn ich denke, bei einem logger kann es nicht schaden, so früh wie möglich zu laufen.

Consolekit kann man sicherlich rausschmeißen. Hab irgendwie noch nicht gefunden wozu das überhaupt gut sein soll...

Wenn dir langweilig ist, kannst du ja von baselayout-1 auf baselayout-2 und openRC wechseln. Da kann man denn auch gut PARALLEL_STARTUP setzen  :Smile: . (Warnung: Der Übergang zu OpenRC kann ein wenig holprig werden...)

Und denn gibt es noch den Trick, /bin/sh auf dash anstatt bash zu setzen  :Smile: . (Hinweis: Kann hier und dort was kaputt machen, wenn in nem skript /bin/sh drin steht, aber eigentlich /bin/bash gemeint ist ... ist bei mir aber in systemskripten nur einmal und ab und zu in selber geschriebenen passiert)

----------

## Josef.95

 *Quote:*   

> Consolekit kann man sicherlich rausschmeißen.

 Oh, Vorsicht!

AFAIK ist USE="consolekit" seit ein paar Wochen default im Desktop Profil, wenn zb Loginmanager wie kdm oder gdm mit dieser Flag gebaut wurden, dann muss auch der "Consolekit Daemon" gestartet sein!

AFAIK benötigt er dies auch für den Networkmanager.

Doch was dies "Consolekit" genau macht kann ich leider auch nicht aufklären.., ich vermute des es für Authentifikation und/oder zum setzen bestimmter rechte zuständig ist..?

----------

## Necoro

Also consolekit wird bei mir sowieso gestartet ... selbst wenn ich USE=-consolekit gesetzt hab und consolekit nicht im runlevel habe ... ich suche immer noch den Schuldigen.

Im Moment scheint nur "emerge -C consolekit" zu helfen.

----------

## zyko

 *Quote:*   

> Mir fällt beim Booten immer wieder auf, dass er versucht auf eth0 über dhcpd sich zu verbinden, was relativ witzlos ist, da ich in den seltensten Fällen mit Netzwerkkabel verbunden bin.

 

Dafür gibt es sys-apps/ifplugd. Ifplugd prüft, ob das Netzwerkkabel drin ist und schickt den Start von net.eth0 in den Background, so dass keine Zeit damit verschwendet wird. Einfach emergen, keine config nötig.

----------

## Klaus Meier

 *Necoro wrote:*   

> Also consolekit wird bei mir sowieso gestartet ... selbst wenn ich USE=-consolekit gesetzt hab und consolekit nicht im runlevel habe ... ich suche immer noch den Schuldigen.
> 
> Im Moment scheint nur "emerge -C consolekit" zu helfen.

 Was hast du denn gegen consolekit? Soll mal hal ablösen habe ich gehört.

----------

## Necoro

 *Klaus Meier wrote:*   

>  *Necoro wrote:*   Also consolekit wird bei mir sowieso gestartet ... selbst wenn ich USE=-consolekit gesetzt hab und consolekit nicht im runlevel habe ... ich suche immer noch den Schuldigen.
> 
> Im Moment scheint nur "emerge -C consolekit" zu helfen. Was hast du denn gegen consolekit? Soll mal hal ablösen habe ich gehört.

 

Nein ... das war DeviceKit  :Smile: 

Und gegen consolekit hab ich, dass es ein Daemon ist, von dem ich nicht weiß was er genau macht und auch die Beschreibung "ConsoleKit is a framework for defining and tracking users, login sessions, and seats. " mir nicht einleuchtet, was ich auf einem Single-User-System damit soll.

Und ferner startet das Teil geschätzte 100 Threads und müllt mir meine htop Ausgabe zu.

----------

## firefly

 *Necoro wrote:*   

> Und gegen consolekit hab ich, dass es ein Daemon ist, von dem ich nicht weiß was er genau macht und auch die Beschreibung "ConsoleKit is a framework for defining and tracking users, login sessions, and seats. " mir nicht einleuchtet, was ich auf einem Single-User-System damit soll.

 

dann setz doch global -consolekit als useflag dann sollte es nicht mehr benötigt werden, oder?

----------

## Necoro

 *firefly wrote:*   

>  *Necoro wrote:*   Und gegen consolekit hab ich, dass es ein Daemon ist, von dem ich nicht weiß was er genau macht und auch die Beschreibung "ConsoleKit is a framework for defining and tracking users, login sessions, and seats. " mir nicht einleuchtet, was ich auf einem Single-User-System damit soll. 
> 
> dann setz doch global -consolekit als useflag dann sollte es nicht mehr benötigt werden, oder?

 

Japp ... aber wenn man es net wieder runterschmeißt wird es eben weiterhin gestartet ...  :Smile:  ...

egal ... btt

----------

## Klaus Meier

 *Necoro wrote:*   

> Nein ... das war DeviceKit 

 

Danke, guten Morgen, noch zu früh am Tag um zu Denken....

----------

## Schinkencroissant

Hallo,

das sind ja jetzt schon haufenweise Tipps auf einmal, ich versuche mal, von oben nach unten durchzugehen:

Zur Antwort von Josef.95:

net.eth0 habe ich jetzt mal aus dem default runlevel herausgenommen, aber zu dem Eintrag in /etc/conf.d/rc habe ich noch eine Frage in Verbindung mit einer weiteren Antwort, also kommt die erst gleich.

Zur Antwort von Necoro:

Das mit dem syslog-ng klingt sinnvoll, das habe ich jetzt auch gerade eben verschoben.

ConsoleKit brauche ich für den Networkmanager, wobei ich jetzt nicht weiß, ob ich es dann in einem runlevel brauche, oder ob sich der Networkmanager nicht selbst schon darum kümmern würde, wenn ich es rausnähme, falls dazu jemand mehr weiß, wäre das sicher hilfreich.

Was bringt mir ein Wechsel von baselayout 1 auf 2? Ich habe mir kurz etwas dazu durchgelesen, aber bin mir noch nicht ganz sicher, ist das performanter? Und was bedeutet PARALLEL_STARTUP, handelt es sich dabei wirklich um das, wonach es klingt, sprich, einem nebenläufigen Bootvorgang, der dann wohl sicher performanter sein kann, als ein "normaler" oder ist das etwas anderes?

Was ist der Unterschied, wenn ich /bin/sh auf dash statt auf bash setze?

Zur Antwort von zyko:

Jetzt noch einmal die Frage im Bezug auf die Antwort von Josef.95. Wenn ich dieses ifplugd benutze, erübrigt sich damit der !net.* Eintrag, den Josef.95 vorgeschlagen hat. Welche Lösung ist die sinnvollere/performantere/sicherere?

Dann noch eine weitere Frage:

alsa wird bei mir im boot bereits gestartet, aber sonlange mein System noch nicht ganz hochgefahren und ich eingeloggt bin, brauche ich eigentlich doch noch keinen Soundserver, wäre es sinnvoll, alsa zu verschieben oder ist das so schon die sinvollere Variante?

Fragen über Fragen, aber ich glaube, dass scheint ein ganz interessantes Thema zu sein, so viele Antworten, wie ich jetzt schon in kürzester Zeit bekommen habe.

Vielen Dank schonmal bis hierhin,

viele Grüße,

Schinkencroissant

----------

## zyko

 *Quote:*   

> Jetzt noch einmal die Frage im Bezug auf die Antwort von Josef.95. Wenn ich dieses ifplugd benutze, erübrigt sich damit der !net.* Eintrag, den Josef.95 vorgeschlagen hat. Welche Lösung ist die sinnvollere/performantere/sicherere?

 

Wenn du ifplugd installiert hast, sollte net.eth0 im default runlevel sein und du solltest das hot/coldplugging nicht verhindern -- also alles ganz normal lassen. Der Vorteil von ifplugd ist, dass du automatisch ein funktionierendes eth0 bekommst, falls das Kabel steckt und anderenfalls keine Zeit beim booten verlierst. Falls du hingegen net.eth0 aus dem runlevel rausschmeißt, musst du es bei Bedarf manuell starten.

 *Quote:*   

> aber bin mir noch nicht ganz sicher, ist das performanter? Und was bedeutet PARALLEL_STARTUP, handelt es sich dabei wirklich um das, wonach es klingt, sprich, einem nebenläufigen Bootvorgang, der dann wohl sicher performanter sein kann, als ein "normaler" oder ist das etwas anderes? 

 

Beim PARALLEL_STARTUP werden die einzelnen runscripts nicht strikt nacheinander abgearbeitet, sondern sie werden alle gleichzeitig gestartet (sofern die dependencies das erlauben, manche runscripts können ja nur starten, wenn ein anderes bereits gestartet ist). Insgesamt sollte das absolut Null Gewinn bringen, da die Bootgeschwindigkeit von der i/o-Performance deiner Festplatte limitiert wird, nicht von irgendwelchen softwareseitigen Unzulänglichkeiten. Aber teste es einfach mal, kostet ja nix  :Wink: 

----------

## Necoro

 *zyko wrote:*   

> Beim PARALLEL_STARTUP werden die einzelnen runscripts nicht strikt nacheinander abgearbeitet, sondern sie werden alle gleichzeitig gestartet (sofern die dependencies das erlauben, manche runscripts können ja nur starten, wenn ein anderes bereits gestartet ist). Insgesamt sollte das absolut Null Gewinn bringen, da die Bootgeschwindigkeit von der i/o-Performance deiner Festplatte limitiert wird, nicht von irgendwelchen softwareseitigen Unzulänglichkeiten. Aber teste es einfach mal, kostet ja nix 

 

Also ich sehe nicht, warum Platten-I/O die Begrenzung darstellen soll. Spätestens bei irgendwelchen größeren Daemons (inkl. X) geht es schon in die CPU-Auslastung. Und es ist schon vorteilhaft, wenn andere Services gestartet werden während dein X hochfährt. Oder während deine Netzwerk auf ne IP wartet.

Bei mir war der speedup schon erstaunlich... (natürlich gemessen am rein subjektiven Empfinden)

 *Quote:*   

> Was ist der Unterschied, wenn ich /bin/sh auf dash statt auf bash setze?

 

```
necoro@Zakarumiy / % time bash -c exit

bash -c exit  0,00s user 0,00s system 71% cpu 0,003 total

necoro@Zakarumiy / % time dash -c exit

dash -c exit  0,00s user 0,00s system 77% cpu 0,001 total
```

die Dash kann kaum was. Das macht sie viel leichter und schneller als die Bash. Sicher ist der obige Unterschied von 0.002s nicht wirklich ausschlaggebend -- wenn man ihn einzeln betrachtet. Aber beim Hochfahren werden zig Skripte gestartet, die jeweils immer ne neue Sh-Instanz starten... und die Masse machts  :Smile: 

----------

## Schinkencroissant

Hallo,

das mit dem nebenläufigen Booten klingt echt interessant, da kümmere ich mich mal drum. Außerdem würde ich mich auch gerne mal um die dash kümmern, aber dazu wüsste ich gerne mal ob mir auch so im Voraus und ohne Fehlermeldung jemand sagen kann, ob er irgendwelche gentoo-eigenen Skripte kennt, bei denen ich die /bin/sh-Zeile besser ersetzen sollte durch eine /bin/bash-Zeile.

Ansonsten bleiben ja noch genügend Fragen aus dem, was ich vorhin geschrieben habe ;-)

Viele Grüße und schonmal ein großes Danke bis hierher,

Schinkencroissant

----------

## Klaus Meier

 *firefly wrote:*   

>  *Necoro wrote:*   Und gegen consolekit hab ich, dass es ein Daemon ist, von dem ich nicht weiß was er genau macht und auch die Beschreibung "ConsoleKit is a framework for defining and tracking users, login sessions, and seats. " mir nicht einleuchtet, was ich auf einem Single-User-System damit soll. 
> 
> dann setz doch global -consolekit als useflag dann sollte es nicht mehr benötigt werden, oder?

 Habs mal probiert. Auch wenn du es als Flag deaktivierst, wird es von genutzt. Habe nicht getestet von welchen, ist ja auch egal, also ob willst oder nicht, bei Gnome hast du es mit dabei.Und wenn es Pakete gibt, die es brauchen, dann sollte man es auch starten.

----------

## sprittwicht

Hab's bei mir jetzt auch runtergeschmissen. Alles mit USE="-consolekit" neu kompiliert, aus dem Runlevel raus und neu gestartet. Trotzdem lief der Prozess nachher. emerge --depclean war der Meinung "weg damit", und dem hab ich mich dann dankend angeschlossen. Wer auch immer das startet tut das unbewusst oder hat seine Abhängigkeiten nicht sauber definiert.

Nach dem was ich so aus Conselekit-Ankündigungen und Doku rauslesen konnte ist der Dienst an einem Single-User-Desktop absolut überflüssig, also nein danke und weg damit...

----------

## Klaus Meier

 *sprittwicht wrote:*   

> Hab's bei mir jetzt auch runtergeschmissen. Alles mit USE="-consolekit" neu kompiliert, aus dem Runlevel raus und neu gestartet. Trotzdem lief der Prozess nachher. emerge --depclean war der Meinung "weg damit", und dem hab ich mich dann dankend angeschlossen. Wer auch immer das startet tut das unbewusst oder hat seine Abhängigkeiten nicht sauber definiert.
> 
> Nach dem was ich so aus Conselekit-Ankündigungen und Doku rauslesen konnte ist der Dienst an einem Single-User-Desktop absolut überflüssig, also nein danke und weg damit...

 Du hast stable? Bei testing ist das nicht mehr der Fall. emerge--depclean wollte nichts entsorgen. Zumindestens unter Gnome.

----------

## Necoro

 *sprittwicht wrote:*   

> Wer auch immer das startet tut das unbewusst oder hat seine Abhängigkeiten nicht sauber definiert.

 

/etc/init.d/hald ist der Schuldige... da steht "use consolekit" drin. Ergo: Starte, wenn du's findest...

----------

## musv

 *Necoro wrote:*   

> Und denn gibt es noch den Trick, /bin/sh auf dash anstatt bash zu setzen . (Hinweis: Kann hier und dort was kaputt machen, wenn in nem skript /bin/sh drin steht, aber eigentlich /bin/bash gemeint ist 

 

Hab's getestet. Und auf einmal war mein Portage weg. Das Ersetzen von sh -> bash der 1. Zeile der Scripte in /etc/init.d/ ist irgendwie ein sinnloser Tipp, denn die beginnen mit:

```

#!/sbin/runscript

```

Oder ich hab das was falsch verstanden?

 *Necoro wrote:*   

> /etc/init.d/hald ist der Schuldige... da steht "use consolekit" drin. Ergo: Starte, wenn du's findest...

 

```

# Start before X

use acpid consolekit hald xfs

```

Hal ist bei mir gar nicht installiert. Aber bevor ich nicht weiß, was consolekit macht, lösch ich das Teil lieber nicht runter.

----------

## SinoTech

 *musv wrote:*   

>  *Necoro wrote:*   Und denn gibt es noch den Trick, /bin/sh auf dash anstatt bash zu setzen . (Hinweis: Kann hier und dort was kaputt machen, wenn in nem skript /bin/sh drin steht, aber eigentlich /bin/bash gemeint ist  
> 
> Hab's getestet. Und auf einmal war mein Portage weg. Das Ersetzen von sh -> bash der 1. Zeile der Scripte in /etc/init.d/ ist irgendwie ein sinnloser Tipp, denn die beginnen mit:
> 
> ```
> ...

 

Du sollst nichts an den Scripten ändern, sondern lediglich in deinem System den Link "/bin/sh" auf "/bin/dash" zeigen lassen (der zeigt normalerweise nämlich auf "/bin/bash"). Und schon benutzen alle Scripte die "/bin/sh" in ihrer ersten zeile haben die "dash" anstatt der "bash".

Cheers,

Sino

----------

## musv

 *SinoTech wrote:*   

> Du sollst nichts an den Scripten ändern, sondern lediglich in deinem System den Link "/bin/sh" auf "/bin/dash" zeigen lassen (der zeigt normalerweise nämlich auf "/bin/bash"). Und schon benutzen alle Scripte die "/bin/sh" in ihrer ersten zeile haben die "dash" anstatt der "bash".

 

Genau das hab ich gemacht. Und genau deswegen funktioniertierte das Squash-Portage-Script nicht mehr.

----------

## Necoro

Du könntest versuchen die 'source DATEI' durch '. DATEI' zu ersetzen  :Smile: . Denn sollte es, soweit ich es sehe, sh-konform sein (vergesse auch die source-Statements in /etc/make.conf nicht)

----------

## Klaus Meier

Hm, also mal etwas Kritik an dem ganzen hier. Ich finde diese ganzen Bootzeitdiskussionen sowieso etwas überflüssig. Was hast du denn für einen Bootzeit? Wenn die bei 5 Minutenliegt sollte man überlegen, wo es ist, aber ansonsten? Also bei deinen Startscripten kannst du wohl netmount rauswerfen, den Rest brauchst du. dash statt bash bringt bei 500x starten genau eine Sekunde. Paralleles startender Scripte hat bei mir Probleme gemacht. Kanns aber noch mal testen.

Wie oft startet mandenn den Rechner? Denke mal, die Zeit, die hier mit diesem Thema verbracht wurde kann man nicht durch das Starten in den nächsten Jahren wieder reinbekommen.

Also ob das jetzt 30, 60 oder 90 Sekunden ist mir absolut egal. Ich starte das Teil einmal am Tag.

----------

## Schinkencroissant

Hallo,

entschuldigt bitte, dass ich so lange mit einer Antwort habe auf mich warten lassen. Also zum Sinn dieses Themas:

Für mich war es bisher sehr interessant, ich konnte schon einiges über das System im Allgemeinen dazulernen. Die Bootzeit ist für mich schon relativ wichtig, da mein ThinkPad schon öfters aus und wieder an mache, gerade, wenn ich unterwegs bin. Da hat es mich schon sehr weiter gebracht, dass ich hier mal ein paar wertvolle Tipps bekommen konnte.

Außerdem hat sich das Ausmisten bisher auch schon positiv auf meinen Stromverbrauch ausgewirkt.

Zwei Dinge wollte ich noch probieren, dann wäre ich auch vorerst fertig mit diesem Thema, aber bis jetzt kann ich schon sagen, dass ich es sehr informativ fand und ich glaube, ich habe auch schon viel gerade bei diesem Thema lernen können.

Zum einen hatte ich mal das mit dem Link auf die Dash ausprobiert, das gab Fehler bei mir einen eher unerwarteten Fehler, um den genauer schildernzukönnen muss ich es erst wieder ausprobieren, also frage ich die Tage noch einmal.

Außerdem werde ich das mit dem parallelen Booten mal ausprobieren, weniger wegen Geschwindigkeit, als mehr, einfach weil mich Nebenläufigkeit schon sehr interessiert und ich gerne mal das nebenläufige Booten erleben will ;-)

Viele Grüße,

Schinkencroissant

P.S.: Klar, dass man für diese Zeit, die wir hier "verplempern", Jahre lang den Rechner booten kann, aber selbst, wenn Dir technisch nichts daran wichtig erscheint, kannst Du Dich immer noch darüber freuen, dass viele wartend vor ihrem Rechner sitzen, bis er hochgefahren ist und dabei an guter Laune verlieren, sprich, viele von den - eventuell nach der Lektüre dieses Themas - Schnellbootern sind besser gelaunt und schreiben netter hier im Forum. Davon haben alle was, egal ob für sie die Bootzeit eine Rolle spielt oder nicht :-)

----------

## Klaus Meier

Nix für ungut, ich fand diesen Threas ja auch nicht daneben, sonst hätte ich da ja icht gelesen, ist auch für mich brauchbares bei rausgekommen.

----------

## Necoro

 *Schinkencroissant wrote:*   

> Die Bootzeit ist für mich schon relativ wichtig, da mein ThinkPad schon öfters aus und wieder an mache, gerade, wenn ich unterwegs bin.

 

Warum nicht suspend2disk/suspend2ram einrichten? Das ist bei Laptops doch schon ein netter Vorteil  :Smile: 

----------

## mv

 *musv wrote:*   

> Genau das hab ich gemacht. Und genau deswegen funktioniertierte das Squash-Portage-Script nicht mehr.

 

Ich habe jetzt nicht nachgeschaut, welches Skript dort empfohlen wird, aber das initscript von dieser Seite ist POSIX und läuft daher mit dash.

----------

## mv

 *Necoro wrote:*   

> Warum nicht suspend2disk/suspend2ram einrichten?

 

Viele können kein suspend2ram, und suspend2disk braucht je nach Laptop sogar noch länger (abgesehen davon, dass es auch Probleme bringen kann, auf die man sich nicht ohne guten Grund einlassen will).

----------

## mv

 *Schinkencroissant wrote:*   

> Also zum Sinn dieses Themas:

 

Für Leute, die mit dem Laptop Vorträge halten, ist die Bootzeit immer ein Thema.

 *Quote:*   

> Zum einen hatte ich mal das mit dem Link auf die Dash ausprobiert, das gab Fehler bei mir

 

Ich habe den Thread jetzt nicht genau verfolgt: Hoffentlich wurde erwähnt, dass das nur bei baselayout-2 möglich ist, da baselayout-1 nicht in POSIX ist. Ein paar Init-scripte spezieller Pakete sind immer noch nicht POSIX, für viele gibt es aber bereits Patches in bugzilla.

 *Quote:*   

> Außerdem werde ich das mit dem parallelen Booten mal ausprobieren, weniger wegen Geschwindigkeit, als mehr, einfach weil mich Nebenläufigkeit schon sehr interessiert.

 

Im Gegensatz zu der Umstellung auf dash hatte die Parallelisierung bei mir kaum Vorteile gebracht; es kommt aber sicherlich sehr auf das System an. Auf jeden Fall funktioniert paralleles Booten ab und zu nicht. Zum Spielen kann man es mal probieren, aber zum zuverlässigen Hochfahren ist es ungeeignet.

----------

## zyko

Man kann nochmal gehörig Zeit sparen, wenn man konsequent passwortloses Login einrichtet und auf xdm/kdm/gdm verzichtet um X zu starten. Selbstverständlich spielen hier Securityerwägungen eine Rolle.

Ich persönlich starte via inittab nicht 7 ttys mit agetty sondern 4 terminals mit mingetty (muss erst emerg't werden). Mingetty ist minimal kleiner und schneller als agetty und ermöglicht ein passwordless login (--autologin):

```
# /etc/inittab

# ... diverse Einträge ...

# TERMINALS

c1:12345:respawn:/sbin/mingetty --noclear --nonewline --nohostname --autologin <USERNAME> tty1

c2:2345:respawn:/sbin/mingetty --noclear --nonewline --nohostname --autologin <USERNAME> tty2

c3:2345:respawn:/sbin/mingetty --noclear --nonewline --nohostname --autologin <USERNAME> tty3

c4:2345:respawn:/sbin/mingetty --noclear --nonewline --nohostname --autologin <USERNAME> tty4

```

Der vierte Terminal startet automatisch X via ~/.bash_profile:

```
# ~/.bash_profile

# ... diverse Einträge ...

tty | grep tty4 && startx
```

X startet somit in tty5. Via ~/.xinitrc startet dann mein Window Manager (awesome) und einige nützliche Programme, die ich von anfang an haben will:

```
# ~/.xinitrc

unclutter -root -noevents -idle 2 &

numlockx &

urxvtd -q -o -f && urxvtc -e htop && urxvtc &

firefox &

pcmanfm &

nvidia-settings --load-config-only &

awesome
```

Selbstverständlich muss hierfür das runscript /etc/init.d/xdm aus dem Bootprozess entfernt werden.

Ich glaube, so ein Setup funktioniert nicht nur mit einfachen WMs, sondern auch mit KDE und dem ganzen Bloat da (=Gnome)  :Wink: 

Ein Display Manager mit Login ist riesige Zeitverschwendung, speziell wenn man sich eh nicht einloggen will. Aber wie gesagt, gewisse Sicherheitserwägungen sollte hier bedacht werden.

----------

## Klaus Meier

Ok, dann mal eine Frage an die Bootzeitoptimierer hier: Um wievei Prozent hat ihr geschafft, die Startzeit zu bexchleunigen?

----------

## ChrisJumper

@Klaus Meier

Ich beschleunige eigentlich nicht mehr, bin aber mit meinen 27 Sekunden (+ Kernel/Grub Zeit) zum GDM durchaus zufrieden. Ca. 30 Sekunden nach dem Einschalten vom PC kann ich mich schon einloggen und damit bin ich zufrieden. Dieser Rechner verwendet aber auch einen Bootsplash für die TTY's, denke das frisst bestimmt 2-3 Sekunden.

Mein zweites Gentoo (Server,TV, Gelegenheitsrechner) braucht sogar nur 24 Sekunden.

Der Schritt zu OpenRC/Baselayout2 war ein gefühlter Sprung von 50%.

----------

## Klaus Meier

 *ChrisJumper wrote:*   

> @Klaus Meier
> 
> Ich beschleunige eigentlich nicht mehr, bin aber mit meinen 27 Sekunden (+ Kernel/Grub Zeit) zum GDM durchaus zufrieden. Ca. 30 Sekunden nach dem Einschalten vom PC kann ich mich schon einloggen und damit bin ich zufrieden. Dieser Rechner verwendet aber auch einen Bootsplash für die TTY's, denke das frisst bestimmt 2-3 Sekunden.
> 
> Mein zweites Gentoo (Server,TV, Gelegenheitsrechner) braucht sogar nur 24 Sekunden.
> ...

 

Ja, ok, sehe ich genauso, aber es gibt hier doch welche, die schreiben, wie Scheiße die Startscripte sind und was für nen Mist sie da alles rausgeschmissen haben usw. Von denen möchte ich wissen, was sie damit erreicht haben. Naja, OpenRC/Baselayout2 habe ich auch. Deshalb will ich ja wissen, was kann man da noch erreichen? Alles unter 20% Steigerung ist irrelevant.

----------

## Necoro

@Klaus Meier:

es geht beim entfernen von unnötigen Startskripten nicht unbedingt um die Bootzeit. Sondern einfach um den Gedanken, dass man nicht will, dass Services auf dem Rechner laufen von denen man keine Ahnung hat was sie tun. Bzw. man weiß was sie tun und man sie definitiv nicht da haben möchte.

Einfach ein: Ich möchte, dass ich im Bilde bin, was wie und wo auf meinem Rechner läuft.

----------

## Klaus Meier

 *Necoro wrote:*   

> @Klaus Meier:
> 
> es geht beim entfernen von unnötigen Startskripten nicht unbedingt um die Bootzeit. Sondern einfach um den Gedanken, dass man nicht will, dass Services auf dem Rechner laufen von denen man keine Ahnung hat was sie tun. Bzw. man weiß was sie tun und man sie definitiv nicht da haben möchte.
> 
> Einfach ein: Ich möchte, dass ich im Bilde bin, was wie und wo auf meinem Rechner läuft.

 Ok, bei dir verstehe ich das ja und ich fand das sehr nützlich, was du geschrieben hast. Aber der Titel von diesem Thread ist Bootzeit. Einige tun aber so, als ob sie da richtig was bewirkt hätten. Deshalb würden mich die Zahlen interessieren.

----------

## ChrisJumper

Oh ich hab nicht den Kompletten thrad gelesen.

Klaus, ich denke es ist einfach ein bisschen der Sportliche/Technische Ehrgeiz. Einfache 5 Sekunden Bootzeit wären schon cool. Und wenn das einmal Standard wird will das jeder haben, ganz bestimmt. Diese kleinen Optimieren mögen vielleicht "überflüssig" sein, sind aber nicht hinderlich. Daher rege ich mich nicht mehr drüber auf. Wenn du mal an einem seeeeehr langsamen System gearbeiteter hast. Wirst du jede dieser kleinen Unterschiede lieben. Überzogen dargestellt wenn aus jeder gesparten Sekunde Minuten werden! Dann sind auch Verbesserungen unter 20% durchaus toll.

----------

## Klaus Meier

 *ChrisJumper wrote:*   

> Oh ich hab nicht den Kompletten thrad gelesen.
> 
> Klaus, ich denke es ist einfach ein bisschen der Sportliche/Technische Ehrgeiz. Einfache 5 Sekunden Bootzeit wären schon cool. Und wenn das einmal Standard wird will das jeder haben, ganz bestimmt. Diese kleinen Optimieren mögen vielleicht "überflüssig" sein, sind aber nicht hinderlich. Daher rege ich mich nicht mehr drüber auf. Wenn du mal an einem seeeeehr langsamen System gearbeiteter hast. Wirst du jede dieser kleinen Unterschiede lieben. Überzogen dargestellt wenn aus jeder gesparten Sekunde Minuten werden! Dann sind auch Verbesserungen unter 20% durchaus toll.

 Meine Güte, rede ich chinesich oder was tue ich, damit mich keiner versteht? Ich habe nichts geben Verbesserungen der Startzeit. Die nicht darauf beruhen, dass ich cups rausnehme.

Ich will eins wissen: Da ja hier einige so groß rumtönen, wie beschissen die Startscripte sind und was sie da alles optimiert haben usw. Wie war die Startzeit vorher und wie hinterher? Also Angabe in Sekunden vorher/nachher. Ist das so schwer zu verstehen?

Natürlich finde ich jede Verbesserung toll und bin auch dafür aufgeschlossen, aber bislang ist mir nur folgendes untergekommen:

Dash statt Bash? Eventuell eine Sekunde.

```
Hallo

Ich will den Bootprozess beschleunigen. Ich bin wie folgt vorgegangen.

aus rc default entfernt:

acpid

cpufrequtils

cupsd

lircd

vixie-cron 
```

Äh, nichts davon wird bei Gentoo automatisch installiert. Entweder ich brauche einen Drucker oder ich brauche keinen.

Was soll eine Aussage, dass auch Verbesserungen unter 20% toll sind, aber mir noch keiner sagen konnte, ob und wie er sie errieicht hat.

Ich bin für jede 5 Sekunden dankbar, aber. es muss doch mal einer sagen, wie er es erreicht hat. ich bin ja auch ein Bastler und Pfriemler... Also nichts gegen dich, aber ich habe in den ganzen Beiträgen noch nichts gelesen, was mir helfen würde.

----------

## Necoro

Ich hab diesen For-Schleifen "Test" auch mal mit der zsh gemacht. Und erstaunlicherweise ist die um einiges flotter als die bash... Hätte eigentlich das Gegenteil erwartet

/edit: Eh ... der Post auf den ich mich bezog, ist obskurer Weise verschwunden   :Shocked: 

----------

## mv

 *Klaus Meier wrote:*   

> Dash statt Bash? Eventuell eine Sekunde.

 

Dann hast Du einen extrem schnellen Prozessor. Bei meinem Laptop (Pentium3) macht der Unterschied locker 20-30 Prozent der Bootzeit aus, und selbst bei einem 64-Bit Athlon waren es mehrere Sekunden; bei einem nagelneuen Dual/Quad-Core dürfte der Unterschied nicht so sehr ins Gewicht fallen. Neben dem Prozessor wird vielleicht auch die Speichergröße eine Rolle spielen (ab 512MB dürfte das egal sein, aber darunter fehlt ev. dann Platz für Cache). Hier übrigens mal ein einfacher Versuch, der den Unterschied deutlich macht: 

```
time bash -c 'i=0; while [ $i -lt 1000 ]; do i=$((i+1)); (:); done'
```

 vs. 

```
time dash -c 'i=0; while [ $i -lt 1000 ]; do i=$((i+1)); (:); done'
```

 gibt als Unterschied ca. den Faktor 3 (jeweils nach mehrmaligem Starten, damit Interpreter und Libraries im Cache sind, wobei das natürlich erst recht zu Ungunsten der Bash ausgehen würde).Last edited by mv on Sun Nov 08, 2009 11:23 pm; edited 1 time in total

----------

## mv

 *Necoro wrote:*   

> Ich hab diesen For-Schleifen "Test" auch mal mit der zsh gemacht.

 

Sorry, den alten Artikel hatte ich gleich wieder gelöscht, da mir ein böser Lapsus unterlaufen war ({1..1000} ist nicht POSIX, und daher der Vergleich falcsh).

Ja, die bash ist so ziemlich die schlechteste Shell, die derzeit auf dem Markt ist - sowohl von der Geschwindigkeit als auch erst recht von den Features. Umso erstaunlicher ist ihre Popularität.

----------

## Klaus Meier

[quote="mv"] *Necoro wrote:*   

> Ja, die bash ist so ziemlich die schlechteste Shell, die derzeit auf dem Markt ist - sowohl von der Geschwindigkeit als auch erst recht von den Features. Umso erstaunlicher ist ihre Popularität.

 

Wie beim IE6. Sie ist standardmäßig voreingestellt. Was würdest du empfehlen? War ganz früher auch bei der tcsh, aber die Kraft des normativen...

----------

## franzf

Ich bin hier schon seit einiger Zeit recht zufrieden mit der zsh.

Wg. Bootzeit:

AMD64 3700+, 1GB RAM.

* parallel=no, bash -> 47 sec.

* parallel=yes, bash -> 34 sec.

* parallel=yes, dash -> 30 sec.

* parallel=yes, zsh -> 34 sec.

Allerdings macht mysql und der remount vor dem poweroff ohne bash Probleme...

Das parallele Starten bringt also am meisten, und macht hier keine Probleme.

Ist es ohne weiteres möglich, in den Startscripts das "/sbin/runscript" (-> /sbin/rc) in ein "/bin/bash" zu ändern? Ich denke nicht...

Ansonsten braucht bei mir das Scannen des Bios nach SATA-Devices so lange, dass 10 Sekunden mehr beim booten gar nicht auffallen.

----------

## mv

 *Klaus Meier wrote:*   

> Was würdest du empfehlen?

 

Für einfache Skripte POSIX (also dash) wegen Geschwindigkeit und Kompatibilität. Für komplexe Skripte zsh (obwohl ich dann meist gleich perl nehme). Als Login-Shell definitiv zsh, denn was interaktive Features anbelangt (Shell-Prompt, Kommandozeilen-Kompletion, Kommandozeileneditor, Inline-Aliase, Mehrfachumleitungen, Abkürzungen für gängige Dinge [wie rekursives Globbing, einfache Schleifen [for i in bla; commando] usw.) ist die zsh unschlagbar (zumindest nach geeigneter Konfiguration, für die man zugegebenermaßen zunächst mal Zeit investieren muss, weil per Default der ganze Luxus abgeschaltet ist, und man erst nachlesen muss, was man alles machen kann).

----------

## mv

 *franzf wrote:*   

> * parallel=yes, zsh -> 34 sec.

 

Wie bitte!? Soll das heißen, Du hast einen Link von /bin/sh auf /bin/zsh gelegt? Das halte ich für gefährlich, so POSIX-Kompatibel ist die zsh nun auch wieder nicht: Es passiert zu leicht, dass da eine Variable oder Feature benutzt wird, das bei der zsh eine spezielle Bedeutung hat.

 *Quote:*   

> Ist es ohne weiteres möglich, in den Startscripts das "/sbin/runscript" (-> /sbin/rc) in ein "/bin/bash" zu ändern?

 

Nein, das darfst Du keinesfalls: In den Scripten werden ja nur Funktionen definiert, nichts ausgeführt. Der ganze Kontext (Funktionen wie depend, Aufrufen der richtigen Funktion beim Starten/Stoppen/Restart, Sourcen des zugehörigen /etc/conf.d-Skripts, Verwaltung was bereits gestarted wurde, usw. usf.) wird von /sbin/runscript erledigt. Dieses benutzt zur Erledigung seiner Aufgabe lediglich /bin/sh. Möglicherweise (aber das habe ich nicht überprüft), kannst Du durch Setzen von SHELL in /etc/rc.conf (oder ev. Erlauben von SHELL in /etc/rc.conf und Aufrufen aus einer Environment, in der SHELL gesetzt wurde), das /sbin/runscript überreden, $SHELL statt /bin/sh zu benutzen.

----------

## franzf

 *mv wrote:*   

>  *franzf wrote:*   * parallel=yes, zsh -> 34 sec. 
> 
> Wie bitte!? Soll das heißen, Du hast einen Link von /bin/sh auf /bin/zsh gelegt?

 

Für einen Boot. Ich wollte nur sehen, ob das Ding evtl. schneller ist als bash, war es nicht. Und mysql wollte auch nicht starten, drum wieder: /bin/sh -> /bin/bash

 *Quote:*   

>  *Quote:*   Ist es ohne weiteres möglich, in den Startscripts das "/sbin/runscript" (-> /sbin/rc) in ein "/bin/bash" zu ändern? 
> 
> Nein, das darfst Du keinesfalls: In den Scripten werden ja nur Funktionen definiert, nichts ausgeführt.

 

Gut, so hab ich mir das auch gedacht. Es wäre halt interessant gewesen, nur im mysql-Script die Bash das Ausführen übernehmen zu lassen, und ansonsten die dash zum Booten nehmen.

----------

## mv

 *franzf wrote:*   

> Es wäre halt interessant gewesen, nur im mysql-Script die Bash das Ausführen übernehmen zu lassen

 

Die richtige Lösung dafür wäre ein Bugreport für das Paket: Startup-Scripte sollen in POSIX geschrieben sein. Vielleicht existiert sogar schon ein solcher Bug mit einem Patch...

----------

## firefly

 *mv wrote:*   

>  *franzf wrote:*   Es wäre halt interessant gewesen, nur im mysql-Script die Bash das Ausführen übernehmen zu lassen 
> 
> Die richtige Lösung dafür wäre ein Bugreport für das Paket: Startup-Scripte sollen in POSIX geschrieben sein. Vielleicht existiert sogar schon ein solcher Bug mit einem Patch...

 

bug ja aber noch kein patch: https://bugs.gentoo.org/show_bug.cgi?id=289970

----------

## Schinkencroissant

Hallo,

hier hat sich ja mittlerweile einiges getan, hätte nicht damit gerechnet, dass dieses Thema solche Kontroversen auslöst. Mir ging es zum einen darum, dass ich mein System genauer kennenlernen wollte, mein Rechner sollte nach Möglichkeit auch schneller starten und am Besten gleich auch noch weniger Strom verbrauchen.

Bis jetzt habe ich auch einiges gelernt, mein Rechner startet mittlerweile in knapp über 20 Sekunden von GRUB zu grafischem Login. Vorher war es fast eine Minute und was mich auch freut, mittlerweile schwankt der Stromverbrauch bei hellem Display zwischen 9 und 14 Watt, sprich, selbst wenn ich daran arbeite, kann ich durchaus mal eine Akkulaufzeit von über 10 Stunden erreichen.

Dass mit dem baselayout-2 als Voraussetzung für den Link von sh auf die dash habe ich bei meinem ersten Versuch noch nicht gewusst, vielleicht probiere ich es im Laufe der nächsten Woche mal so.

Suspend2ram/disk wäre prinzipiell auch interessant, 2ram funktioniert auch anstandslos, 2disk nicht so wirklich. Dennoch kommt es öfters vor, dass ich nicht weiß, wenn ich unterwegs bin, ob ich den Rechner gleich schon wieder oder erst in einigen Stunden brauche und dann ist mir eine kurze Bootzeit doch lieber als ein suspend2ram.

Natürlich spielt auch der Wettbewerb eine kleine Rolle, es ist schließlich ganz interessant, so zu hören, was andere so erreicht haben und was noch möglich ist.

Viele Grüße,

Schinkencroissant

P.S.: Es gibt zwar eine Anleitung http://www.gentoo.de/doc/de/openrc-migration.xml zum Wechsel auf baselayout2 und openrc, aber da steht nur drin:  *Quote:*   

> Die Migration zu OpenRC ist ziemlich geradlinig; es wird als Teil Ihres regulären Upgrade-Prozesses durch Ihren Paket-Manager einbezogen. Der wichtigste Schritt kommt eigentlich erst nachdem Sie die neuen Pakete >=sys-apps/baselayout-2 und sys-apps/openrc installieren.

  Mir erschließt sich dabei nicht so ganz, ob vor der Installation der beiden erwähnten Pakete auch schon etwas kommt, oder ob ich mit der Installation anfange.

Noch mal vielen Dank.

----------

## Puschi

Hallo an alle,

booten in 5 sec. habe ich noch nicht geschafft , aber 14 sec von grub bis zum funktionsfähigen X-Oberfläche hab ich nun erreicht.

Wie habe ich das erreicht?

1: 

openrc und baselaout 2, paraleles starten

2: 

Grub - Kerneloption -quiet für Unterdrückung Kernelnachrichten

3:

Kernekonfiguration alles fest einkompiliert

4:

Netzwerk mit fester IP-Adresse

5:

Installation auf 2 schnellen Sata-Platten mit Raid0 für / und /var und /home mit reiserfs in separaten   Partitionen. (mit mdadm, kein Hardwareraid)

-------------

meiner ich # hdparm -tT /dev/md1

/dev/md1:

 Timing cached reads:   3444 MB in  2.00 seconds = 1722.54 MB/sec

 Timing buffered disk reads:  814 MB in  3.00 seconds = 270.98 MB/sec

---------------

/boot mit ext2 auf Bootpartition damit das Raid booten kann

6: 

Einsatz von mingetty und autologin wie oben beschrieben, kein slim, kdm, gdm oder xdm

/etc/inittab mit Eintragung

"# TERMINALS

c1:12345:respawn:/sbin/mingetty --noclear --nonewline --nohostname --autologin ich tty1 

c2:2345:respawn:/sbin/mingetty --noclear --nonewline --nohostname --autologin ich tty2 

c3:2345:respawn:/sbin/mingetty --noclear --nonewline --nohostname --autologin ich tty3 

c4:2345:respawn:/sbin/mingetty --noclear --nonewline --nohostname --autologin ich tty4"

~/.bash_profile mit Eintragung "tty | grep tty4 && startx"

~/.xinitrc mit Eintragung     "exec ck-launch-session startxfce4" 

7:

Benutzung Xfce4 4.8

Ich sitze hier zuhause alleine am Rechner und habe deshalb keine übertriebenen Sicherheitsanforderungen.

Nachtrag:

Ich habe auch mal mit systemd experimentiert. Aus dem Overlay systemd kann man es installieren.

Funktioniert soweit schon ganz gut. 

Die Bootzeit entspricht etwa meiner jetzigen mit openrc, bringt also keinen Mehrwert. Auch ist der Aufwand und die Pflege des Systems dann abseits von portage und dem initsystem und somit aufwändiger und fehlerträchtiger.

Puschi

----------

