mikrocontroller.net

Forum: PC Hard- und Software Debian: Programm ausführen nach Systemstart


Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!


Ich habe folgendes vor:

Ich habe ein C-Programm geschrieben und möchte dieses unter Debian Linux 
(ohne graphische Oberfläche) während des Bootens meines Systems 
ausführen.

Zunächst lege ich mein kompiliertes Programm in den Ordner "etc/init.d". 
Von dort aus verknüpfe ich nun mittels "ln -s QUELLE ZIEL" die 
auszuführende Datei auf den jeweiligen Runlevel-Ordner.

Das Ganze sieht dann so aus:
~#  ln -s /etc/init.d/Test.app /etc/rcS.d

Die Skripte, die im Ordner "rcS.d" enthalten sind, sollen laut 
ubuntu-Wiki "während des Bootens" ausgeführt werden. -Also genau da wo 
ich es möchte.

Leider funktioniert es aber nicht!

Nach längerem Recherchieren im Netz habe ich eine "Erweiterung" des 
händischen Verknüpfens in die einzelnen Ordner gefunden.
Die Lösung dazu ist der Befehl "update-rc.d".

Hiermit habe ich dann die Test.app, die unter init.d liegt automatisch 
mit allen Ordnern (rcX.d) verknüpfen lassen.

Mit diesem Befehl klappt es.

Das Problem ist aber, dass er mir nun beim herunterfahren, beim ersten 
Bootlevel, beim zweiten Bootlevel usw. das Programm ausführt.

Durch händisches Verknüpfen mittels
~#  ln -s /etc/init.d/Test.app /etc/rcS.d
funktioniert es leider nicht.

Wo liegt hier mein Fehler?

Ich habe mir extra die Mühe gemacht, in alle rcX.d-Ordner händisch zu 
verknüpfen. Habe anschließend immer neugestartet, leider wurde mein 
Programm aber kein einziges Mal ausgeführt.

Wiegesagt, mit dem Befehl
update-rc.d Test.app defaults
klappts.

Woran kann das liegen?

Ich möchte einfach mein Programm so schnell wie möglich (ohne Userlogin) 
vom System ausführen lassen.


Vielen Dank!

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich spekuliere einfach mal drauf los:

1. Welches init-System? Alt oder neu? Das neue funktioniert anders.

> ~#  ln -s /etc/init.d/Test.app /etc/rcS.d
2.                                         ^
                                            '/' vergessen
3.                                            ^
                                               Präfix vergessen

4. Was ist so schlimm daran, es den update-rc.d automatisch (und 
funktionsfähig..) erledigen zu lassen? Man muss es ja nicht in alle 
Runlevel eintragen lassen..

HTH

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es in alle Runlevel einzutragen heißt, dass er es in jedem Runlevel 
einmal ausführt.
Ich möchte es aber nur in einem bestimmten Runlevel, und zwar in dem, 
der am ehesten das Ausführen des Skripts ermöglicht.

Was meinst du mit Präfix "vergessen"?
Den Link hat er immer richtig erzeugt. Habe es im jeweiligen Ordner mit 
"ls" geprüft, ob der Link tatsächlich existiert.


Wie lautet dann der Befehl für update-rc.d um das Skript nicht in alle 
Runlevel einzutragen?

Danke!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Runlevel 3:
update-rc.d Test.app start 99 3 .

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ad Präfix: 'Sxx' gehört(tm) da vorne mit dran.

> Wie lautet dann der Befehl für update-rc.d um das Skript nicht in alle
> Runlevel einzutragen?

Die man-Page [1], behelfsweise [2], dokumentiert das ausführlich.

HTH und HF

[1] man update-rc.d
[2] https://encrypted.google.com/search?q=man+update-rc.d

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> update-rc.d Test.app start 99 3

funktioniert leider nicht.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> update-rc.d Test.app start 99 3
>
> funktioniert leider nicht.

Das ist sehr schwammig. Falls eine Fehlermeldung kommt wegen Parameter: 
Da gehört (wie prx korrekt angegeben) noch ein '.' hinten dran. (Das 
steht übrigens auch in der man-Page :-)

Falls es eingetragen wird aber 'nur' nicht startet: Debian bootet per 
Default in den Runlevel 2 (das steht in der inittab :-)

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok habe es geschafft.

Ich habe nun händisch folgenden Befehl eingegeben:

ln -s /etc/init.d/Test.app /etc/rc2.d/S20DerTest.sh


Die Bezeichnung  "S20DerTest.sh" hat mir das update-rc.d vorher immer 
ausgegeben. Kann mir einer verraten, wofür dieses "S20" steht? Ist das 
diese Priorität?

Jedenfalls führt er mir nun das Programm aus, während des Bootens, bevor 
ich mich als Benutzer anmelden muss, sowie ich es wollte. -Allerdings 
führt er es 2x aus.


Was ist bei Runlevel 2 schon alles geladen? Kann man da schon auf die 
Peripherie zugreifen?


Danke!

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Idee, und vielleicht reicht das ja schon aus: gewünschtes Programm in 
/etc/rc.local aufrufen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LeanUX schrieb:

> ausgegeben. Kann mir einer verraten, wofür dieses "S20" steht? Ist das
> diese Priorität?

S = Start
20 = Sortierreihenfolge - vorne kommt zuerst dran.

Früher gab es auch K für Stop/Kill. Aus der Mode gekommen, weil 
redundant.
S rückwärts tut es auch.

> Was ist bei Runlevel 2 schon alles geladen? Kann man da schon auf die
> Peripherie zugreifen?

Schau nach /etc/rc2.d, da steht drin was alles gestartet wird. Wenn du 
von was abhängig bist, dann starte danach. Daher auch meine 99.

Überdies empfiehlt sich die Auswertung des Parameters 
(start/stop/restart/...). Drum stehen in /etc/init.d auch nicht die 
Exes, sondern Shell-Scripts.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[Präfix bei init-Skript-Links]
> Kann mir einer verraten, wofür dieses "S20" steht?

..das steht in der schon mehrfach angeführten man-Page, weiterführend in 
der von init(8). Schau halt einfach mal rein, tut auch gar nicht weh..

> Was ist bei Runlevel 2 schon alles geladen? Kann man da schon auf die
> Peripherie zugreifen?

Runlevel 2 ist Muliuser. Was man da schon alles kann hängt von dieser 
ominösen zweistelligen Nummer ab.. ich sag jetzt nicht nochmals 
'man-Page'.. uups, zu spät..

rc.local wäre auch eine Alternative wie Sebastian schrub..

Viel Spaß

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wunderbar, Danke Sebastian!

Hat super geklappt. Ist wohl die einfachste Lösung.

Komischerweise führt er mit dieser Variante (rc.local) das Programm wie 
gewünscht nur einmal aus.



Kann mir jetzt noch einer erklären, was es denn mit diesen Runlevels 
aufsich hat?


Danke

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...Dann lag wohl mein Problem anfangs darin, dass ich dieses "S20" 
weggelassen habe und das System wohl nicht wusste, wann es meinen 
Dienst/Skript ausführen musste?!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LeanUX schrieb:

> Komischerweise führt er mit dieser Variante (rc.local) das Programm wie
> gewünscht nur einmal aus.

Vorher hatte er es beim Start mit "start" und beim Shutdown mit "stop" 
aufgerufen.

> Kann mir jetzt noch einer erklären, was es denn mit diesen Runlevels
> aufsich hat?

Ururalte Unix-Tradition. Siehe www.gidf.de

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Kann mir jetzt noch einer erklären, was es denn mit diesen Runlevels
> aufsich hat?

maaaaan-Page ∗hust∗. Oder [1]

HF

[1] http://en.wikipedia.org/wiki/Runlevel

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine bescheuerte Frage:

Dann müsste doch auch der X-Server (die graphische Oberfläche), sofern 
man sie mit installiert hat, im Ordner "etc/init.d" bzw. in einem der 
rsX.d-Ordner stehen, damit dieser automatisch beim Systemstart 
ausgeführt wird, richtig?

Danke

Autor: Tom M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LeanUX schrieb:
> Ich habe ein C-Programm geschrieben und möchte dieses unter Debian Linux
> (ohne graphische Oberfläche) während des Bootens meines Systems
> ausführen.
>
> Zunächst lege ich mein kompiliertes Programm in den Ordner "etc/init.d".
> Von dort aus verknüpfe ich nun mittels "ln -s QUELLE ZIEL" die
> auszuführende Datei auf den jeweiligen Runlevel-Ordner.

Soll das Proggie immer/einfach laufen, oder abhängig von Runlevel das 
oder jenes tun?

Gängige debian Systeme haben den Vixie-cron mit an Bord. Um einen 
Prozess automagisch zu starten, verwende ich sowas:
@reboot ( tail -F /var/log/auth.log | /usr/local/sbin/sshguard ) &

Alles weitere steht in der manpage (man 5 crontab).

HTH! :)

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dann müsste doch auch der X-Server (die graphische Oberfläche), sofern
> man sie mit installiert hat, im Ordner "etc/init.d" bzw. in einem der
> rsX.d-Ordner stehen, damit dieser automatisch beim Systemstart
> ausgeführt wird, richtig?

Ja. Beispielhaft für den Gnom (Gnome Display Manager):
$ find /etc/rc* -type l -name '*gdm'
/etc/rc0.d/K01gdm
/etc/rc1.d/K01gdm
/etc/rc2.d/S21gdm
/etc/rc3.d/S21gdm
/etc/rc4.d/S21gdm
/etc/rc5.d/S21gdm
/etc/rc6.d/K01gdm

Der ist hierzuworkstation also in den Runleveln 2 bis 5 aktiv (das sind 
die üblichen Muliuser-Runlevel in Debian).

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum aber steht das dann in jedem der Runlevel-Verzeichnisse? Würde es 
nicht auch reichen, es in einem bestimmten (Graphische Oberfläche dann 
so ziemlich im Letzten) reinzuschreiben?

Das versteh ich noch nicht ganz. Das System startet ja von Level 0 bis 
Level 5. Was hat dann schon im Level 0 die Graphische Oberfläche 
verloren?!

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Warum aber steht das dann in jedem der Runlevel-Verzeichnisse?
[..]
> Das versteh ich noch nicht ganz. Das System startet ja von Level 0 bis
> Level 5.

Bitte tu Dir einen Gefallen uns lies endlich die Doku. Hier nochmals 
zwei schöne Links dazu [1, 2]. Das System startet eben ∗nicht∗ durch die 
Runlevel 'durch'. Einzig 'S' wird anfangs betreten, danach wird in den 
Zielrunlevel geschaltet (bei Debian per default '2'). Erst beim 
Runterfahren (oder wenn es explizit angefordert wurde) wird der Runlevel 
wieder geändert.

> Was hat dann schon im Level 0 die Graphische Oberfläche verloren?!

Runlevel 0? Du meinst deswegen? :
/etc/rc0.d/K01gdm
       ^   ^

Da steht ein 'K' vorne dran (als Teil jenen ominösen Präfixes, das Du 
anfangs unterschlagen hattest). Warum das Skript mit 'K' vorne dran beim 
Systemstart ∗nicht∗ gestartet wird steht - ich sags ja nur ungern - in 
der Doku, im speziellen in den man-Pages zu update-rc.d [3] und init 
[2]. Da steht auch sehr ausführlich was wann warum und wie gemacht wird 
und was es für Auswirkungen hat.

[1] http://en.wikipedia.org/wiki/Runlevel
[2] man 8 init
[3] man 8 update-rc.d

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das heißt, ich kann auch direkt in einen Runlevel booten, der kaum 
Treiber enthält, damit mein System noch schneller startet?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LeanUX schrieb:
> der kaum
> Treiber enthält, damit mein System noch schneller startet?

nein, weil ein runlevel keine Treiber enthält sonder Dienste/Dämonen 
aber bestimmt keine Treiber.

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Habe mir nun die Manuals durchgelesen. Es sind aber weiterhin Fragen 
offen:

 - in welchem Runlevel startet denn mein Linux? Oben wurde geschrieben 
im Runlevel 3?

So kann ich also hergehen und die "nicht benötigten" Skripte aus dem 
Ordner /etc/rc3.d (sofern es Runlevel 3 ist) rauswerfen, um das Ganze 
auf Zeit zu optimieren?!

Ansonsten müsste ich wohl den Kernel mit dmeentsprechend eingeschränkten 
Treibern neukompilieren, um das Ganze etwas flotter zu machen?!


Vielen Dank

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LeanUX schrieb:
> - in welchem Runlevel startet denn mein Linux? Oben wurde geschrieben
> im Runlevel 3?

Das steht in der Datei /etc/inittab

Beispiel für Default-level 2:
...
id:2:initdefault:
...

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..kommt drauf an was letztenendes alles laufen soll. Wenn Du das 
Programm möglichst früh gestartet haben möchtest und das restliche 
System soll dann auch 'normal' hochkommen: Packs ans Ende(!) von rc.S. 
In einem adäquaten Start-Skript versteht sich. Ist zwar leicht 
missbräuchlich aber was solls.

Wenn das auch noch zu spät ist und Du ∗nur∗ Dein Programm laufen lassen 
wisst, dann hau init (und das restliche System :-) komplett weg und 
starte stattdessen selbiges Programm. Dies erreichst du per 
'init='-Kernel-Boot-Parameter. Aber Achtung: Da läuft sonst ∗nix∗, es 
werden dann auch keine weiteren Dateisysteme oder so eingehängt. Einfach 
nur ein nackter Kernel. Ggf. musst du das Programm statisch linken und 
in die initrd mit einpacken.

Ich würds mir allerdings schwer überlegen ob das alles wirklich nötig 
ist, obs die paar Sekunden beim Start wirklich Wert sind.

So oder so viel Spaß beim basteln und mach nix kaputt

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann den rc-Mechanismus auch ignorieren, indem man
das eigene Programm direkt in die /etc/inittab einträgt.
Das ist nicht besser, aber leichter zu verstehen :-)

siehe:
man 5 inittab

Autor: faustian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Man kann den rc-Mechanismus auch ignorieren, indem man
das eigene Programm direkt in die /etc/inittab einträgt.
Das ist nicht besser, aber leichter zu verstehen :-)"

Nicht fuer den Systembetreuer der das findet und sich fragt wo es das 
gibt was Du geraucht hast beim Installieren ;)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
faustian schrieb:

> Nicht fuer den Systembetreuer der das findet und sich fragt wo es das
> gibt was Du geraucht hast beim Installieren ;)

Kommt drauf an wie alt er ist und was für Systeme er sonst noch betreut.

Man kann sich so nämlich als alter Unix-Hase tarnen ;-). Immerhin ist 
diese Methode weit älter als der ganze /etc/rc*.d Mechanismus. Unter den 
Unixen gibt es noch heute welche, bei denen man nur die Wahl zwischen 
inittab und ein paar rc-Files hat, aber kein /etc/rc*d.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke mal, daß der Frager hier auch gleich sein eigener Admin
ist, sonst würde er sich das nicht fragen.
Warum soll er also nicht eben schnell sein Programm da eintragen?

Das ist sicher nicht der eleganteste Weg für einen Rechner, auf
mal der eine und der andere etwas administrieren soll.
Aber hier wäre es der gerade und direkte Weg.

Und immerhin wird der rc-Kram ja auch genau dort gestartet...

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, danke erstmal für die zahlreichen Antworten :)

Ich werde es wohl weiterhin in der rc.local stehen lassen. Ich (als mein 
Admin ;-) ) werde dann die paar Sekunden beim Starten verschmerzen, 
zumal das System dann "voll" da ist.
Das System startet bei mir nun in etwa 15 sec, bis das von mir 
geschriebene Programm ausgeführt wird. Das ist optimal. Allerdings habe 
ich mir eben ein paar Gedanken darüber gemacht, wie man diese Bootzeit 
noch etwas kürzen könnte, durch Dienste, die nicht unbedingt benötigt 
werden.

Deshalb auch meine Frage.


Könnte mir trotzdem einer noch Step-by-Step erklären, wie ich die 
Dienste nun (die WIRKLICH nicht benötigt werden) löschen/deaktivieren 
kann?
Ich würde jetzt einfach in den einzelnen rcX.d-Verzeichnissen die 
jeweiligen Softlinks löschen. Unwissendlich, welcher Dienst dahinter 
steckt.

Bringt das dann überhaupt was bei der Bootzeit?


Vielen Dank!

...ich weiß, meine Fragen erzeugen bei Euch Linux-Freaks ein müdes 
Lächeln ;)

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Könnte mir trotzdem einer noch Step-by-Step erklären, wie ich die
>Dienste nun (die WIRKLICH nicht benötigt werden) löschen/deaktivieren
>kann?

Nun, erstmal must du wissen was du wirklich nicht brauchst.
Das must du selbst wissen (Poste mal ein ps ax).
Dann den kram deinstallieren. aptitude ist dein freund.

Wenn du den Packetnamen nicht kennst hilft dir dpkg -S /path/file

>Ich würde jetzt einfach in den einzelnen rcX.d-Verzeichnissen die
>jeweiligen Softlinks löschen. Unwissendlich, welcher Dienst dahinter
>steckt.

Schlechte Idee. Wie stellt du links wieder her wenn doch benötigt?

>Bringt das dann überhaupt was bei der Bootzeit?

Wie viele von den 15 Sek sollen es denn weniger sein?
Mein Squeeze hier brauch im Bootloader genau solange
wie für /etc/rc2.d/*. (so ca 3 Sekunden.....)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS:

1. die ganzen rc-Skripte werden beim Start in alphabetischer
   Reihenfolge abgearbeitet.
   Deshalb haben die Namen meist nach einem "S" (nötig, damit es
   beim Eintreten in den level gestartet wird) danach
   zweistellige Nummern und dann
   einen beschreibenden Teil im Namen; dadurch werden sie
   letztlich in Reihenfolge ihrer Nummern ausgeführt (was
   bei konsequenter Benamsung ja gleich der alphabetischen
   Reihenfolge ist).
   Wenn du dein Skript also möglichst früh laufen lassen
   willst, kannst du es über den rc-Mechanismus einfach in
   der Art "S00_irgendwas" nennen. Dann kommt es vor den
   anderen dran (in dem entsprechenden rc<Zahl>.d-Verzeichnis).

2. Daß diese Namen letztlich meist nur symbolische Links
   auf andere Skripte sind, wurde ja schon erwähnt.
   Das kann man nett nutzen, um versuchsweise Skripte
   stillzulegen:
   Einfach das Ziel des Links etwas umbenennen (z.B. einen
   Tiefstrich anhängen). Dann kann man sehen, ob der Rechner
   noch wie gewünscht läuft, ohne etwas gelöscht zu haben.
   Dadurch, daß der Link ins Nirwana verweist, passiert
   nichts weiter, außer daß das Skript natürlich nicht läuft.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PPS:
Es gibt keine Softlinks, nur Softdrinks.

Ein Link ist entweder ein "hard link" oder "symbolic link".

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Man kann den rc-Mechanismus auch ignorieren, indem man
> das eigene Programm direkt in die /etc/inittab einträgt.
> Das ist nicht besser, aber leichter zu verstehen :-)

In manchen Fällen ist das besser ;-)

Der Vorteil gegenüber Initscripten ist, dass damit das Programm auch 
überwacht werden kann, so dass es neugestartet wird, wenn es aus welchem 
Grund auch immer (also z.B. auch nach einem Segfault wegen eines 
Programmfehlers) beendet wird. Natürlich darf dazu das Programm sich 
nicht selbst als Daemon in den Hintergrund befördern.

Mit Initscripten ist das nur durch Zusatztools oder erhebliche 
Shellverrenkungen möglich, insbesondere wenn man den Prozess auch 
irgendwann mal beim Shutdown kontrolliert beenden möchte, ohne dass er 
gleich wieder neugestartet wird.

faustian schrieb:
> Nicht fuer den Systembetreuer der das findet und sich fragt wo es das
> gibt was Du geraucht hast beim Installieren ;)

Ein Unixadmin, der damit nicht klarkommt, hat den falschen Job ;-)

Andreas

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie viele von den 15 Sek sollen es denn weniger sein?
>Mein Squeeze hier brauch im Bootloader genau solange
>wie für /etc/rc2.d/*. (so ca 3 Sekunden.....)


Dein Linux bootet in 3 Sekunden?
Was mache ich nur falsch :-/

Habe auch schon den Grub (Timeout:1) gesetzt, damit er in einer Sekunde 
das gewählte System lädt.

Wenn ich die Pakete deinstalliere, was bringt mir das?! Die Pakete 
werden doch nur dann geladen, wenn sie auch ausgeführt werden oder? 
Sprich, das benötigte Paket wird erst beim Ausführen in den RAM geladen, 
sollte also somit beim Booten keine Zeit beanspruchen?

Ansonsten, wo stehen die Anweisungen, das Paket-X mit dem jeweiligen 
Bootlevel geladen werden soll???

Zu dem was ich für mein System brauche:

 - Zugriff auf die Serielle Schnittstelle
 - Gnu C Compiler (wird eigentlich garnicht zwingend benötigt, da das ja 
nur das fertig kompilierte Programm ausgeführt wird)
 - Treiber für Ein-/Ausgabe (Keyboard / Shellausgabe)
 - ggf. Zugriff auf eine mySQL-Datenbank und Webserver (XAMPP/ 
APache/mySQL)


Das heißt, das System startet mit dem gewünschten Bootlevel und führt 
dann die in dem jeweiligen Ordner (rc<ZAHL>.d) enthaltenen Skripte aus.
Ich schaue also erstmal nach, welcher Bootlevel bei mir gebootet wird, 
richtig?
Das müsste ja dann in /etc/inittab stehen.


Vielen Dank!

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LeanUX schrieb:
> Wenn ich die Pakete deinstalliere, was bringt mir das?! Die Pakete
> werden doch nur dann geladen, wenn sie auch ausgeführt werden oder?
> Sprich, das benötigte Paket wird erst beim Ausführen in den RAM geladen,
> sollte also somit beim Booten keine Zeit beanspruchen?

Das kommt drauf an, welche Pakete du hast.
Wenn ein Oaket einen gcc enthält, wird das beim Booten natürlich
nicht auffallen, sondern erst wenn jemand das Ding aufruft.

Ist in dem Paket dagegen ein ssh-Dämon, ein ftp-Server oder der
Apache wird es so installiert, daß es beim Hochfahren auch gestartet
wird.
Dafür gibt es dann in der Regel jeweils ein neues rc-Skript.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LeanUX schrieb:
> Ansonsten, wo stehen die Anweisungen, das Paket-X mit dem jeweiligen
> Bootlevel geladen werden soll???

Über den rc-Mechanismus werden je nach <runlevel> alle Skripte,
die in /etc/rc<runlevel>.d stehen und mit S beginnen, beim
Eintritt in den run level gestartet (mit dem Parameter "start").
(Entsprechend beim Verlassen alle, die mit K wie Kill beginnen,
mit dem Parameter "stop".)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wobei es bei manchen Distros keine K* mehr gibt.

Autor: LeanUX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Das heißt, ich habe durch Einblick in die rc<ZAHL>.d-Ordner Einblick, 
welche Dienste auch wirklich nur beim Starten gestartet werden.?!


Danke!

Bin jetzt 2 Wochen im Urlaub (linuxfrei) :)

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Dein Linux bootet in 3 Sekunden?

lesen. Da stand 3 sek für /etc/rc2.s/*.
Dazu kommt Bios, Grub, Kernel, initrd, rcS.d, ....
Deswegen die frage wie viele Sekunden du gerne hättest.
Der Aufwand steigt nämlich exponentiell.

> Wenn ich die Pakete deinstalliere, was bringt mir das?!

Bei einem update kann es dir passieren das die rc?.s links
wieder angelegt werden.
Ausserdem: Was nicht gestartet wird kann man nicht verwenden.
Und was man nicht braucht kann runter.

> Die Pakete
> werden doch nur dann geladen, wenn sie auch ausgeführt werden oder?

Es ging um die packete die dienste via rc?.d starten.
Nicht um den gcc oder sowas (es sei denn du brauchst Platz).

>Sprich, das benötigte Paket wird erst beim Ausführen in den RAM geladen,
>sollte also somit beim Booten keine Zeit beanspruchen?

jeep.

>Zu dem was ich für mein System brauche:
> - Zugriff auf die Serielle Schnittstelle

setserial installiert/notwendig?

> - Gnu C Compiler (wird eigentlich garnicht zwingend benötigt, da das ja
> nur das fertig kompilierte Programm ausgeführt wird)

Kostet dich ausser Platte nix.

> - Treiber für Ein-/Ausgabe (Keyboard / Shellausgabe)

-> macht die Kernel.

> - ggf. Zugriff auf eine mySQL-Datenbank und Webserver (XAMPP/
APache/mySQL)

hmmm... Beides Monster. Reicht nicht z.b. thttpd/boa/... und sqlite?

> Das heißt, das System startet mit dem gewünschten Bootlevel und führt
> dann die in dem jeweiligen Ordner (rc<ZAHL>.d) enthaltenen Skripte aus.

Das ist etwas komplexer:
(Ohne Anspruch auf Vollständigkeit!)
- Grub
- initrd laden
- kernel laden und starten, basis Hardware init
- kernel entpackt die initrd ins Ram und startet /init
- u.a werden Ide/Sata Treiber geladen, raids zusammengebaut, ....
- ggf wird der swapspace nach einem suspend to disk image durchsucht
- das Rootfilesystem wird ausfindig gemacht und nach / gemounted.
- kernel startet /sbin/init welches die /etc/inittab liest
- init startet /etc/init.d/rcS welches /etc/rcS.d/* abarbeitet
- init startet /etc/init.d/rc 2 welches /etc/rc2.d/* abarbeitet
- init startet die gettys
- eines davon zeigt dir dann den login: prompt

>Ich schaue also erstmal nach, welcher Bootlevel bei mir gebootet wird,
>richtig?

runlevel weiß das. Wird N 2 sein.
Boote zum test doch mal in den single user mode (recovery im grub).
Dann hast du einen vergleich wie viel zeit mit dem tunen von rc2.d
rauszuhohlen ist. Der rest wird dann aufwendig.
(Angepasste kernel, initrd weglassen, /etc/init.d/rc anpassen,...)

>Das müsste ja dann in /etc/inittab stehen.

Sieht so aus: id:2:initdefault:

>Das heißt, ich habe durch Einblick in die rc<ZAHL>.d-Ordner Einblick,
>welche Dienste auch wirklich nur beim Starten gestartet werden.?!

Nicht zwangsläufig.
Einige Dienste starten bei Debian nur wenn sie konfiguriert sind (inetd, 
isdnutils,...) und/oder in /etc/default/* eingeschaltet wurden....
Diese tests brauchen aber auch zeit. -> auch deswegen deinstallieren.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.