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:
1
~#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
1
~#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
1
update-rc.dTest.appdefaults
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!
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
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!
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
>> 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 :-)
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!
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.
[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ß
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
...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?!
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
> 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
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
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:
> 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):
1
$ find /etc/rc* -type l -name '*gdm'
2
/etc/rc0.d/K01gdm
3
/etc/rc1.d/K01gdm
4
/etc/rc2.d/S21gdm
5
/etc/rc3.d/S21gdm
6
/etc/rc4.d/S21gdm
7
/etc/rc5.d/S21gdm
8
/etc/rc6.d/K01gdm
Der ist hierzuworkstation also in den Runleveln 2 bis 5 aktiv (das sind
die üblichen Muliuser-Runlevel in Debian).
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?!
> 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? :
1
/etc/rc0.d/K01gdm
2
^ ^
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
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.
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
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:
..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
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
"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 ;)
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.
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...
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 ;)
>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.....)
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.
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
>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!
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.
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".)
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) :)
>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.
Thread beobachten
Seitenaufteilung abschalten