runlevel von rc1 -> rc2 portmap startet nicht

[domix]

Hallo zusammen,

ich habe ein Problem beim switchen der runlevels. Wenn ich von runlevel 2 auf 1 wechsle und dann wieder zurück zu runlevel 2 kann der nfs-kernel-server nicht richtig starten, da der portmap daemon nicht mehr läuft.

In rc1.d befindet sich K81portmap. Damit wird der portmap daemon abgeschalten. In rc2.d befindet sich S18portmap und sollte damit eigentlich neu gestartet werden. Das Startskript wird allerdings nicht aufgerufen.

Was mir aufgefallen ist, wenn ich zu runlevel 1 wechsle befinde ich mich im Anschluss in runlevel S, jedoch werden nicht die Startskrpts aus rcS.d aufgerufen. Darin wird wahrscheinlich das Problem liegen.
Hat jemand ein ähnliches verhalten bei sich beobachtet und es vielleicht sogar gelöst?

Grüße und vielen Dank,
domix

[cosmac]

hi,

das einfachste dürfte sein, den portmap von Hand zu starten. Das Problem ist jedenfalls als Bug #438529 bekannt und anscheinend nicht trivial.

Yes, it behaves as documented and it is seriously messed up.

was will man da noch sagen
Ich dachte, ich hätte mal eine Erklärung gelesen, aber ich finde sie natürlich nicht wieder. Danach war es nicht vorgesehen, vom Runlevel 1 auf einen normalen zu wechseln. Man sollte stattdessen neu booten.

[rendegast]

Danach war es nicht vorgesehen, vom Runlevel 1 auf einen normalen zu wechseln. Man sollte stattdessen neu booten.

Wäre eine total beknackte Entschuldigung für unsaubere Startskripte.

[domix]

Hallo,
das sehe ich ähnlich wie rendegast!
Für mich wäre es eigentlich schon sehr wichtig bei einem Wechsel der runlevel in einen klar definierten Zustand zu wechseln. Im Zweifel einen Dienst von Hand zu starten oder den Rechner neu zu starten kenne ich von Windows. Das war jetzt böse ich weiß!!! Das sollte aber nicht das Ziel von einer Linux Distribution sein oder liege ich da falsch?
Ich würde gerne in den Ablauf der runlevel manuell eingreifen. Das wird sehr schwierig, wenn der Grundzustand schon zu einem fehlerhaften verhalten führt. Bisher habe ich NICHT in die init Skripts eingegriffen.

Deshalb nochmal meine Nachfrage an Euch! Könnt Ihr dieses Verhalten ebenfalls reproduzieren?

Der oben genannte Bug #438529 wurde im August 2007 gemeldet. Diesen hatte ich ebenfalls gefunden war jedoch der Meinung, das dieser eineinhalb Jahre später behoben sein sollte.

Grüße,
domix

[rendegast]

Der oben genannte Bug #438529 wurde im August 2007 gemeldet. Diesen hatte ich ebenfalls gefunden war jedoch der Meinung, das dieser eineinhalb Jahre später behoben sein sollte.

Nein, lenny portmap_6.0-9, postinst :

Code: Alles auswählen

# Automatically added by dh_installinit
if [ -x "/etc/init.d/portmap" ]; then
	update-rc.d portmap start 43 S . start 32 0 6 . stop 81 1 . >/dev/null

Ein Walkaround:
wegen /etc/init.d/portmap :

Code: Alles auswählen

case "$1" in
    start)
	log_begin_msg "Starting portmap daemon..."
	pid=$( pidofproc -p /var/run/portmap.pid /sbin/portmap )
	if [ -n "$pid" ] ; then
	      log_begin_msg "Already running."
	      log_end_msg 0
	      exit 0

ist es kein Problem, den portmap in den benötigten Runleveln mit update-rc.d als S01portmap einzubinden.



-----------
suse hat hier kein Problem, da 'yast runlevel' die Startlinks unter Berücksichtigung der LSB-Header zusammenwürfelt.
Und die unterschiedliche Technik, daß bei suse Eintritts- und Austrittsskripte in den Runleveln existieren,
in debian aber nur Eintrittsskripte.
(In debian laufen Dienste also über Runlevelwechsel hinweg weiter, während sie bei suse neu gestartet werden)

---- EDIT 20090605 - testing/squeeze -----------------
'insserv' beachtet die LSB-Header, portmap-Header:

Code: Alles auswählen

# Default-Start:     S 2 3 4 5
# Default-Stop:      0 1 6

viewtopic.php?f=15&t=66551&hilit=yast&start=15#p703980
yast_runlevel_debian.sh :

Code: Alles auswählen

#!/bin/sh
sysv-rc-conf  -s S1234560  --Purge  [-p]
insserv  [-v]

'sysv-rc-conf ... -p' läßt einen explizit die STOP-Skripte angeben