Fileserver startet nach Runlevel 6 nicht neu

L

-loop-

Installer
Hallo,

ich habe ein Problem mit meinen Debian-Fileserver.

Hatte mir ein wenig die Runlevels zerschossen mit dem Tool "rcconf".

Der Server lässt sich nur noch erfolgreich neustarten mit dem Befehl:

Code:
reboot -d -f -i

Also wenn ich eingebe
Code:
shutdown -r now
,
friert die Konsole ein und der Server schaltet sich ab.

Laut Syslog schaltet der Server erfolgreich in Runlevel 6.

Hier einmal ein
Code:
ls -l /etc/rc6.d
:

Code:
lrwxrwxrwx 1 root root  17 19. Feb 2007  K09apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root  14 18. Feb 2007  K11cron -> ../init.d/cron
lrwxrwxrwx 1 root root  20 27. Jan 2008  K20apache-ssl -> ../init.d/apache-ssl
lrwxrwxrwx 1 root root  13 23. Mai 16:16 K20atd -> ../init.d/atd
lrwxrwxrwx 1 root root  18  9. Jul 20:02 K20bootlogd -> ../init.d/bootlogd
lrwxrwxrwx 1 root root  14  9. Jul 21:45 K20capa -> ../init.d/capa
lrwxrwxrwx 1 root root  18  9. Jul 20:02 K20discover -> ../init.d/discover
lrwxrwxrwx 1 root root  19  9. Jul 20:02 K20dns-clean -> ../init.d/dns-clean
lrwxrwxrwx 1 root root  15  9. Jul 18:05 K20exim4 -> ../init.d/exim4
lrwxrwxrwx 1 root root  20 17. Mai 16:52 K20fancontrol -> ../init.d/fancontrol
lrwxrwxrwx 1 root root  14  9. Jul 19:52 K20halt -> ../init.d/halt
lrwxrwxrwx 1 root root  17  9. Jul 20:02 K20hotplug -> ../init.d/hotplug
lrwxrwxrwx 1 root root  18 27. Jan 2008  K20icecast2 -> ../init.d/icecast2
lrwxrwxrwx 1 root root  15 18. Feb 2007  K20inetd -> ../init.d/inetd
lrwxrwxrwx 1 root root  20  5. Aug 2007  K20irqbalance -> ../init.d/irqbalance
lrwxrwxrwx 1 root root  19  9. Jul 20:02 K20killprocs -> ../init.d/killprocs
lrwxrwxrwx 1 root root  26  9. Jul 20:02 K20libdevmapper1.02 -> ../init.d/libdevmapper1.02
lrwxrwxrwx 1 root root  20  9. Jul 20:02 K20lm-sensors -> ../init.d/lm-sensors
lrwxrwxrwx 1 root root  13  9. Jul 18:05 K20lpd -> ../init.d/lpd
lrwxrwxrwx 1 root root  27  9. Jul 20:02 K20module-init-tools -> ../init.d/module-init-tools
lrwxrwxrwx 1 root root  18  9. Jul 20:02 K20modutils -> ../init.d/modutils
lrwxrwxrwx 1 root root  13 17. Mai 16:52 K20mpd -> ../init.d/mpd
lrwxrwxrwx 1 root root  15 20. Feb 2007  K20mysql -> ../init.d/mysql
lrwxrwxrwx 1 root root  13  9. Jul 20:02 K20nas -> ../init.d/nas
lrwxrwxrwx 1 root root  20 23. Mai 16:16 K20nfs-common -> ../init.d/nfs-common
lrwxrwxrwx 1 root root  17  9. Jul 20:02 K20nviboot -> ../init.d/nviboot
lrwxrwxrwx 1 root root  23  8. Mai 2007  K20openbsd-inetd -> ../init.d/openbsd-inetd
lrwxrwxrwx 1 root root  18  9. Jul 20:02 K20pppd-dns -> ../init.d/pppd-dns
lrwxrwxrwx 1 root root  16  9. Jul 20:02 K20procps -> ../init.d/procps
lrwxrwxrwx 1 root root  18  9. Jul 20:02 K20rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root  19  9. Jul 20:02 K20rmnologin -> ../init.d/rmnologin
lrwxrwxrwx 1 root root  15 28. Apr 23:01 K20samba -> ../init.d/samba
lrwxrwxrwx 1 root root  22  9. Jul 21:52 K20serverconfig -> ../init.d/serverconfig
lrwxrwxrwx 1 root root  16  9. Jul 20:02 K20single -> ../init.d/single
lrwxrwxrwx 1 root root  23  9. Jul 20:02 K20stop-bootlogd -> ../init.d/stop-bootlogd
lrwxrwxrwx 1 root root  30  9. Jul 20:02 K20stop-bootlogd-single -> ../init.d/stop-bootlogd-single
lrwxrwxrwx 1 root root  14  9. Jul 20:02 K20udev -> ../init.d/udev
lrwxrwxrwx 1 root root  19  9. Jul 20:02 K20udev-mtab -> ../init.d/udev-mtab
lrwxrwxrwx 1 root root  16 18. Feb 2007  K20vsftpd -> ../init.d/vsftpd
lrwxrwxrwx 1 root root  20  9. Jul 20:02 K20x11-common -> ../init.d/x11-common
lrwxrwxrwx 1 root root  24  9. Jul 20:02 K20xfree86-common -> ../init.d/xfree86-common
lrwxrwxrwx 1 root root  16 28. Jan 2008  K20xinetd -> ../init.d/xinetd
lrwxrwxrwx 1 root root  19 22. Jan 2008  K22mysql-ndb -> ../init.d/mysql-ndb
lrwxrwxrwx 1 root root  23 22. Jan 2008  K23mysql-ndb-mgm -> ../init.d/mysql-ndb-mgm
lrwxrwxrwx 1 root root  20  9. Jul 18:05 K25hwclock.sh -> ../init.d/hwclock.sh
lrwxrwxrwx 1 root root  26  9. Jul 18:05 K63mountoverflowtmp -> ../init.d/mountoverflowtmp
lrwxrwxrwx 1 root root  16  9. Jul 18:05 K75hdparm -> ../init.d/hdparm
lrwxrwxrwx 1 root root  17  9. Jul 18:05 K81portmap -> ../init.d/portmap
lrwxrwxrwx 1 root root  14  9. Jul 18:05 K88dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root  21  9. Jul 18:05 K89hotplug-net -> ../init.d/hotplug-netlrwxrwxrwx 1 root root  15 18. Feb 2007  K89klogd -> ../init.d/klogd
lrwxrwxrwx 1 root root  18 18. Feb 2007  K90sysklogd -> ../init.d/sysklogd
-rw-r--r-- 1 root root 351 23. Dez 2007  README
lrwxrwxrwx 1 root root  18  9. Jul 20:02 S20sendsigs -> ../init.d/sendsigs
lrwxrwxrwx 1 root root  17 18. Feb 2007  S30urandom -> ../init.d/urandom
lrwxrwxrwx 1 root root  22 19. Jul 12:01 S31umountnfs.sh -> ../init.d/umountnfs.sh
lrwxrwxrwx 1 root root  20 18. Feb 2007  S35networking -> ../init.d/networking
lrwxrwxrwx 1 root root  18 18. Feb 2007  S36ifupdown -> ../init.d/ifupdown
lrwxrwxrwx 1 root root  18  9. Jul 20:02 S40umountfs -> ../init.d/umountfs
lrwxrwxrwx 1 root root  20  9. Jul 20:02 S60umountroot -> ../init.d/umountroot
lrwxrwxrwx 1 root root  16  9. Jul 20:02 S90reboot -> ../init.d/reboot


Auf Anfrage stell ich gern weitere Informationen zur Verfügung.

Ich komm einfach nicht darauf warum die Scripte in Runlevel 6 nicht greifen.

Gruß

-loop-
 
Ich wäre mir da nicht so sicher.
Was soll das da?
Ich kenne es von HPUX, dass außer den scripten nichts in den init.d-verzeichnissen stehen darf (soll).

Aber gut, du wirst schon wissen, was du da tust und ich habe kein problem damit, wenn dein server nicht rebootet.
 
Hi,

wieso hast du rc6 überhaupt verändert? Von 2 - 5 kannste ruhig rum spielen, 1 und 6 sind was schon was ganz Eigenes.

1 - Systemhalt
2-5 - Multiuser-Betrieb mit Netzwerk und GUI
6 - Systemreboot

Warum nimmste für den normalen Betrieb nich n "normales" Runlevel?

Edit://
@NoXqs
-loop- hat schon Recht, alles was nicht mit 'S' oder 'K' beginnt wird ignoriert. Die README Datei gibt Informationen zu den Verzeichnissen und gibts nur unter Debian Etch. - Sie existiert standardmäßig.
 
Zuletzt bearbeitet:
Hi,

wieso hast du rc6 überhaupt verändert? Von 2 - 5 kannste ruhig rum spielen, 1 und 6 sind was schon was ganz Eigenes.

1 - Systemhalt
2-5 - Multiuser-Betrieb mit Netzwerk und GUI
6 - Systemreboot

Was die Runlevels bedeuten ist mir schon plausibel.

Es gab da nur dieses spezielle tool was einen die Arbeit bei der Runlevelverwaltung unter Debian erleichten soll --> "rcconf"

Dieses tool ist dann ein wenig "aus dem Ruder" geraten, und hat mir manche Einträge in den Runlevels verborgen, manche wiederum gelöscht
und hat die Startreihenfolgen nahezu alle auf den default-Wert
von K20 / S20 gesetzt.

Um präziser zu arbeiten sollte man daher besser
Code:
update-rc.d
unter Debian verwenden ;-)

Also wenn einem noch etwas einfällt ... dem wäre ich sehr dankbar!

Gruß

-loop-

Edit://
Um noch anzumerken: rcconf hat mir meine Runlevels so derbe zerschossen,
das der Server sich einfach nicht mehr booten lies.

Ich habe dann mittels einer Knoppix-LiveCD alles in einer chroot-Umgebung eingebunden
und mittels update-rc.d die nötigsten Runlevel um mit den Betrieb
wieder fortzufahren wiederhergestellt.

So weit läuft alles .. bis auf Runlevel 6
Da werde ich wohl noch ein paar Anpassungen vornehmen müssen.

Ich hab hier nur einen Thread erstellt, falls jemand ähnl. schon mal gemacht hat,
mir auf der Schnelle helfen könnte.

Für andere User könnte eine Lösung ebenfalls interessant sein.

Wenn ich zwischenzeitlich eine Lösung gefunden habe, werde ich Sie hier natürlich posten.

Gruß

-loop-
 
Zuletzt bearbeitet:
Ich kenne Debian nicht, aber ich glaube, das gehört da nicht hin.

root:~# ls /etc/rc*.d/README
/etc/rc0.d/README /etc/rc2.d/README /etc/rc4.d/README /etc/rc6.d/README
/etc/rc1.d/README /etc/rc3.d/README /etc/rc5.d/README /etc/rcS.d/README

Ich kenne Debian und benutze es sogar und bin mir ziemlich sicher das das da hin gehört. Wenn man Tipps gibt ohne die Distri zu kennen ists ja ok, aber es ist kein Grund dann rumzupflaumen wenn der Vorschlag nicht angenommen wird.. tststs

Hier meine rc?.d Verzeichnisse:
 

Anhänge

  • runlevel.tar.bz2
    2,6 KB · Aufrufe: 1
root:~# ls /etc/rc*.d/README
/etc/rc0.d/README /etc/rc2.d/README /etc/rc4.d/README /etc/rc6.d/README
/etc/rc1.d/README /etc/rc3.d/README /etc/rc5.d/README /etc/rcS.d/README

Ich kenne Debian und benutze es sogar und bin mir ziemlich sicher das das da hin gehört. Wenn man Tipps gibt ohne die Distri zu kennen ists ja ok, aber es ist kein Grund dann rumzupflaumen wenn der Vorschlag nicht angenommen wird.. tststs

Hier meine rc?.d Verzeichnisse:

Danke für die Mühe! Werd es mir anschauen!
 
Ich weiß nicht was für ein Debian du fährst, meins ist das aktuelle stable. Du kannst da mal dein rc6.d sichern und es mit meinem probieren.. Wieder heilmachen kannst du dann ja später. Alternativ könntest du vielleicht mal schauen in welchem Paket die Systemrunlevels drin sind, bin leider gerade zu faul dazu :-) Unter Gentoo ist das alles viel besser, das ist eine der Sachen die ich so vermisse. (Bin aufm Server auf Debian umgestiegen)
 
Alternativ könntest Du (nach Sicherung des aktuellen Standes) alle Links in /etc/rcX.d/ löschen und dann per
Code:
update-rc.d <script> defaults
vom System wieder mit den default Werten anlegen lassen ...
 
Alternativ könntest du vielleicht mal schauen in welchem Paket die Systemrunlevels drin sind, bin leider gerade zu faul dazu :-)

Nein. Ich denke nicht das es dafür ein spezielles Paket unter Debian gibt. Die Runlevels werden doch individuell erstellt.
Das heisst im Grunde, wenn ich ein Paket wie "openssh" installiere, werden bei der Einrichtung des Paketes automatisch auch die Runlevel erzeugt.

Also gehe ich davon aus das die Scripte für die Runlevelerzeugung den jeweiligen Paketen beiligen.

Besser ich erzeuge sämtliche Runlevels neu auf Basis deiner angehangen gepackten Datei.
update-rc.d erzeugt auf allen Runlevelebenen Symlinks.
Also etwas "einzeln anfassen" in einen bestimmten Runlevel ist nicht der richtige Weg denke ich.

Wenn alles wieder seine Ordnung hat, dann wird es sicher auch mit den reboot klappen!


Gruß

-loop-
 
Wenn Du ein Paket wie samba installierst, wird nix anderes gemacht als das Init-Script nach /etc/init.d/ zu kopieren und hierfür update-rc.d <script> defaults aufzurufen ... also quasi das, was ich Dir oben empfohlen hab ....
 
Alternativ könntest Du (nach Sicherung des aktuellen Standes) alle Links in /etc/rcX.d/ löschen und dann per
Code:
update-rc.d <script> defaults
vom System wieder mit den default Werten anlegen lassen ...

Probier das mal, wenn das geht wärs wohl die ideale Lösung. Godspeeds Hinweis in den Wind zu schlagen ist meistens nicht das beste ;-)
 
Probier das mal, wenn das geht wärs wohl die ideale Lösung. Godspeeds Hinweis in den Wind zu schlagen ist meistens nicht das beste ;-)

Ich hab hier keine Hinweise in den Wind geschlagen ;-)
Goodspeeds Vorschlag kenne ich bereits,
genau so habe ich auch eine Teilrekonstruktion,
wie oben beschrieben mit Knoppix vorgenommen.
Steht alles in der manpage von update-rc.d!

Genau so werde ich vorgehen und alle Symlinks in den Runlevels wiederherstellen.

Gruß

-loop-
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

Wenn Du ein Paket wie samba installierst, wird nix anderes gemacht als das Init-Script nach /etc/init.d/ zu kopieren und hierfür update-rc.d <script> defaults aufzurufen ... also quasi das, was ich Dir oben empfohlen hab ....

Ja. Hat geklappt :-) .. Hab alle Runlevels nochmal neu angelegt und nach den Vorgaben die Startreihenfolgen bestimmt:

Code:
* After the S40 scripts have executed, all local file systems are mounted
  and networking is available. All device drivers have been initialized.

* After the S60 scripts have executed, the system clock has been set, NFS
  filesystems have been mounted (unless the system depends on the automounter,
  which is started later) and the filesystems have been cleaned.


Muss wohl etwas nicht vernünftig verlinkt gewesen sein.

Jedenfalls jetzt rebootet der Server wieder ordnungsgemäß =)

Danke an all die jenigen die mir Hilfestellungen angeboten haben!



Gruß

-loop-
 
Zuletzt bearbeitet:
Freut mich dass es wieder läuft, was genau war jetzt die Lösung?
 
Freut mich dass es wieder läuft, was genau war jetzt die Lösung?

Lösung war das ich die Runlevels mittels update-rc.d
neu erstellt habe.

Code:
 update-rc.d [-n] [-f] name remove

       update-rc.d [-n] name defaults [NN | SS KK]

       update-rc.d   [-n]   name   start|stop  NN  runlevel  [runlevel]...   .
              start|stop NN runlevel [runlevel]...  . ...

Vorher hatte ich lediglich nur Symlinks von Hand einen bestimmten Runlevel zugeordnet.

Da aber ein Daemon beispielsweise auch ordnungsgemäß "gestoppt" werden will, kam es bei mir zu Problemen.

update-rc.d fügt synchron in allen Runlevels die jeweiligen Symlinks hinzu, so das alles wie ein Uhrwerk läuft ;-)

Ein einfacher Symlink von Hand angelegt ist daher alles andere als sinnvoll.

Wenn ich ein Script in Runlevel 2 habe,
ist es praktisch, wenn es dann auch bei einen Reboot / Shutdown wieder gestoppt wird.

Das alles erledigt update-rc.d automatisch,
so das man keine wichtigen Symlinks vergisst.

Also wer Dienste beim Start laden will, besser nicht von Hand in den Runlevels rumpfuschen,
da gibt es doch so ein tooles tool : update-rc.d =)

Gruß

-loop-

BTW. Und wenn man ein Symlink nicht mehr benötigt :
Code:
update-rc.d <Symlink> remove
Wird dann somit aus allen Runlevels sauber entfernt.
 
Zuletzt bearbeitet:

Ähnliche Themen

Problem mit SATA

Mit AWK verschiedene Felder verschiedener Zeilen vergleichen

Creative Labs SoundBlaster Audigy 2 ZS unter Debian / Kernel 3.16

X startet nichtmehr

XEN 4.3 GMP Problem

Zurück
Oben