vmware-serverd über init ein-/ausschalten

[surfmode]

Howdy Com,

OpenSuse10.2 x86_64 Einsatz.

Habe mir gerade "runlevel 4" als Standardrunlevel eingerichtet.
In runlevel 5 startet eigentlich nur zusätzlich noch der vmware-server. Sinn und Zweck
dieses Prozedere ist, dass ich Ressourcen sparen möchte, da ich vmware ja nicht
immer benutze.

Nach dem Booten ist im Runlevel 4 natürlich auch keine Spur von vmware in den Prozessen:



bluepoint: # ps aux | grep *vmware*
root 13483 0.0 0.0 7072 840 pts/2 S+ 00:15 0:00 grep *vmware*


Wenn ich nun per init 5 von runlevel 4 nach 5 wechsele, startet also vmware und dessen
kompletter netzwerk-rümpel (nat, dhcp und co). Alles perfekt soweit.



Aug 23 23:31:58 bluepoint init: Switching to runlevel: 5
Aug 23 23:31:58 bluepoint kernel: /dev/vmmon[10351]: Module vmmon: registered with major=10 minor=165
Aug 23 23:31:58 bluepoint kernel: /dev/vmmon[10351]: Module vmmon: initialized
Aug 23 23:31:58 bluepoint kernel: /dev/vmnet: open called by PID 10378 (vmnet-bridge)
Aug 23 23:31:58 bluepoint kernel: /dev/vmnet: hub 0 does not exist, allocating memory.
Aug 23 23:31:58 bluepoint kernel: /dev/vmnet: port on hub 0 successfully opened
Aug 23 23:31:58 bluepoint kernel: bridge-eth0: enabling the bridge
Aug 23 23:31:58 bluepoint kernel: bridge-eth0: up
Aug 23 23:31:58 bluepoint kernel: bridge-eth0: already up
Aug 23 23:31:58 bluepoint kernel: bridge-eth0: attached
Aug 23 23:31:58 bluepoint kernel: /dev/vmnet: open called by PID 10386 (vmnet-natd)
Aug 23 23:31:58 bluepoint kernel: /dev/vmnet: hub 8 does not exist, allocating memory.
Aug 23 23:31:58 bluepoint kernel: /dev/vmnet: port on hub 8 successfully opened
Aug 23 23:32:08 bluepoint kernel: /dev/vmnet: open called by PID 10417 (vmnet-netifup)
Aug 23 23:32:08 bluepoint kernel: /dev/vmnet: port on hub 8 successfully opened
Aug 23 23:32:08 bluepoint vmnet-dhcpd: Configured subnet: 172.16.241.0
Aug 23 23:32:08 bluepoint vmnet-dhcpd: Setting vmnet-dhcp IP address: 172.16.241.254
Aug 23 23:32:08 bluepoint kernel: /dev/vmnet: open called by PID 10430 (vmnet-dhcpd)
Aug 23 23:32:08 bluepoint kernel: /dev/vmnet: port on hub 8 successfully opened
Aug 23 23:32:08 bluepoint vmnet-dhcpd: Recving on VNet/vmnet8/172.16.241.0
Aug 23 23:32:08 bluepoint vmnet-dhcpd: Sending on VNet/vmnet8/172.16.241.0
Aug 23 23:32:08 bluepoint ifup: vmnet8
Aug 23 23:32:08 bluepoint ifup: No configuration found for vmnet8


Wenn ich dann aber von runlevel 5 zurück nach 4 switche, dann werden nur die vmware-
netzwerkgeschichten gestoppt.



Aug 23 23:32:46 bluepoint init: Switching to runlevel: 4
Aug 23 23:32:46 bluepoint kernel: /dev/vmmon[10523]: Module vmmon: unloaded
Aug 23 23:32:46 bluepoint kernel: bridge-eth0: down
Aug 23 23:32:46 bluepoint kernel: bridge-eth0: detached
Aug 23 23:32:47 bluepoint ifdown: vmnet8
Aug 23 23:32:48 bluepoint ifdown: Interface not available and no configuration found.


vmware-serverd läuft noch immer, obwohl mir der runlevel-editor von YASt
sagt, dass der Dienst vmware z Zt (zurück im runlevel 4 also) nicht mehr aktiv ist.



bluepoint: # pidof vmware-serverd
10393
bluepoint # ps aux | grep *vmware*
root 10393 0.0 1.3 16784 13500 ? Ss Aug23 0:00 /usr/sbin/vmware-serverd -s -d


Ich vermute ja jetzt mal stark, dass es mit dem Schalter /usr/sbin/vmware-serverd -s -d zu tun hat....
-d steht ja im Allgemeinen für Daemon und den krieg ich ja wohl über init 4 nicht gestoppt.

Im script /etc/init.d/vmware habe ich auch schon die entsprechende Stelle gefunden:



bluepoint # cat /etc/init.d/vmware | grep serverd
serverd=vmware-serverd
serverd=vmware-ccagent
"$vmdb_answer_SBINDIR"/"$serverd" -s -d


Denkt ihr es genügt, wenn ich in dem Script mal den -d Schalter rausnehme?
Oder wäre das nicht so gut?

Greetz
surfmode

[Olleg]

Du musst in /etc/init.d/rc5.d (oder ist es bei SuSE /etc/rc5.d ?) einen "K"-Link auf die vmware-serverd erstellen.
Ungefähr so:
ln -s /usr/sbin/vmware-serverd /etc/init.d/rc5.d/K99vmware

[b3ll3roph0n]

Du musst in /etc/init.d/rc5.d (oder ist es bei SuSE /etc/rc5.d ?) einen "K"-Link auf die vmware-serverd erstellen.
Ungefähr so:Nein, bitte nicht!

1. Die Symlinks werde auf die Init-Scripte gesetzt, und nicht auf das jeweilige Binary.
2. Unter SUSE werden die Symlinks überhaupt nicht manuell angelegt.

Siehe: http://linuxforen.de/forums/showpost.php?p=1501695&postcount=21

@TE
Was gibt denn
chkconfig -l vmware xinetd aus?

[surfmode]

bluepoint # chkconfig -l vmware xinetd
vmware 0:off 1:off 2:on 3:on 4:off 5:on 6:off
xinetd 0:off 1:off 2:off 3:off 4:off 5:off 6:off


So wie es aussieht hat xinetd also wohl nix damit zu tun ;)

Greetz
x-mode

[b3ll3roph0n]

So wie es aussieht, werden weder vmware noch xinetd im Runlevel 4 gestartet.

Wenn du dir schon "Runlevel 4 als Standardrunlevel" eingerichtet hast, solltest du auch alle notwendigen Dienste im RL 4 aktivieren.
Für vmware z.B.:
chkconfig vmware 2345

Btw:
So wie es aussieht hat xinetd also wohl nix damit zu tun ;)Den xinetd brauchst du für den vmware-authd (VMware remote access authentification daemon) - für den Fall, dass du dich von einem Client mit der VMWare-Console zum Server verbinden willst.

[surfmode]

Hmmm, Sinn und Zweck der Aktion ist ja schließlich eben dass vmware in Runlevel 4
nicht läuft (d.h. auch vmware-serverd nicht) um so Resourcen freizumachen.

Im Prinzip will ich ja vom Standardrunlevel 4 nach 5 switchen, wenn ich vmware
benötige und wenn ich es nicht mehr benötige einfach wieder nach 4 switche wobei alle
Dienste die vmware gehören, abgeschaltet werden.

Hab dieses Prozedere jetzt übrigens auch mal mit "service" durchgespielt:



bluepoint # runlevel
N 4

bluepoint # service vmware start
Starting VMware services:
Virtual machine monitor done
Virtual ethernet done
Bridged networking on /dev/vmnet0 done
Host-only networking on /dev/vmnet8 (background) done
NAT service on /dev/vmnet8 done
Starting VMware virtual machines... done

bluepoint # service vmware stop
Stopping VMware services:
Virtual machine monitor done
Bridged networking on /dev/vmnet0 done
DHCP server on /dev/vmnet8 done
NAT service on /dev/vmnet8 done
Host-only networking on /dev/vmnet8 done
Virtual ethernet done

bluepoint # pidof vmware-serverd
5301


Also selbst wenn ich den Dienst direkt mit aufrufe, wird der vmware-serverd nicht
mit "stop" beendet.

Bug?

[temir]

Bevor man was falsches macht, könnte ein Blick in den init-Script Abhilfe schaffen (hier am Beispiel lm-sensors):


### BEGIN INIT INFO
# Provides: sensors
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
# Default-Start: 2 3 5
# Default-Stop:
# Description: sensors is used for monitoring motherboard sensor values.
# Config file is /etc/sysconfig/lm_sensors

Die Zeile "# Default-Stop:" ist die benötigte...Im Fall mit vmserver sollte hier mind. "4" stehen, dann wird der Dienst (sollte o_O) im init 4 gestoppt werden.

Zu empfehlen wäre noch, vor der Script-Änderung mit `insserv -r vmserver` die Links zu entfernen, und nach der Änderung mit `insserv vmserver` wieder anlegen zu lassen.

[surfmode]

Kleine Verständnisfrage hierzu:
Offensichtlich sind die Zeilen in deinem Beispiel und auch in meinem /etc/int.d/vmware-Script
auskommentiert? Muss das so sein oder muss ich die Kommentare der entsprechenden
Zeile oder gar alle Zeilen entfernen?

Greetz
surfmode

[b3ll3roph0n]

Hmmm, Sinn und Zweck der Aktion ist ja schließlich eben dass vmware in Runlevel 4
nicht läuft (d.h. auch vmware-serverd nicht) um so Resourcen freizumachen.Sry, hatte ich irgendwie missverstanden ...

Wie hast du den Standardrunlevel denn gesetzt?
Per default ist (unter openSUSE) der RL 4 in /etc/inittab auskommentiert.
$ grep "rc 4" /etc/inittab
#l4:4:wait:/etc/init.d/rc 4
Also:
Die Raute (#) entfernen und anschließend alle Dienste, die im RL 5 aktiv sind (außer vmware) auch im RL 4 aktivieren (am einfachsten im YaST Runlevel-Editor).


@temir
Die Default-Werte im Header des Init-Scriptes werden ausgelesen, wenn das Script z.B. mit
chkconfig <script> [on|off] aktiviert bzw. deaktiviert wird anstatt die Runlevel in denen das Script gestartet wird explizit zu setzen.
Um Dienste beim RL-Wechsel zu Starten/Stoppen sollte eine Änderung im Init-Script nicht notwendig sein.

[surfmode]

Sry, hatte ich irgendwie missverstanden ...

Wie hast du den Standardrunlevel denn gesetzt?
Per default ist (unter openSUSE) der RL 4 in /etc/inittab auskommentiert.

$ grep "rc 4" /etc/inittab
#l4:4:wait:/etc/init.d/rc 4

Also:
Die Raute (#) entfernen und anschließend alle Dienste, die im RL 5 aktiv sind (außer vmware) auch im RL 4 aktivieren (am einfachsten im YaST Runlevel-Editor).

Genauso hab ich es getan, erst /etc/inittab, dann per YaST Runlevel-Editor editiert und
Runlevel 4 als Standardrunlevel konfiguriert:D
Und für Runlevel 5 dann nur noch zusätzlich im Runlevel-Editor "vmware" aktiviert...

Klappt ja swoeit auch alles, bis auf das "vmware-serverd" beim Switchen nach 4
nicht beendet wird, vermutlich weil er beim Switchen nach RL 5 vom vmware-initscript mit -d als Daemon aufgerufen wird.

Hab mir jetzt mal die Stopsequenz von /etc/init.d/vmware angeschaut:



stop)
# need to do VM auto stop before unmounting vmfs disks, in case
# we are suspending to VMFS files
if [ "`vmware_product`" = "wgs" -o "`vmware_product`" = "vserver" ]; then
if [ "`vmmonUseCount`" -gt 0 ]; then
echo "Stopping VMware virtual machines..."
serverd_pid=`pidof $serverd`
if [ -n "$serverd_pid" ]; then
# This whole code is hella racy
vmware_synchrone_kill "$serverd_pid" "USR1"
# Wait for serverd to stop;
# XXX: Add a finite timeout to give up at (maybe use serverd to g
uess the value)
while [ -d /proc/"$serverd_pid" ]; do
sleep 1
done
else
vmware_exec '' "$vmdb_answer_SBINDIR"/"$serverd" -k
fi
fi
fi


Der Author kommentiert ja selber schon: "# This whole code is hella racy" :(

Ideen dazu?

Greetz
surfmode

[temir]

@temir
Die Default-Werte im Header des Init-Scriptes werden ausgelesen, wenn das Script z.B. mit
chkconfig <script> [on|off] aktiviert bzw. deaktiviert wird anstatt die Runlevel in denen das Script gestartet wird explizit zu setzen.
Um Dienste beim RL-Wechsel zu Starten/Stoppen sollte eine Änderung im Init-Script nicht notwendig sein.
Es gab mal Zeiten, in denen SuSE's /sbin/chkconfig aus ein paar Zeilen bestand, like:


#!/bin/sh
# do nothing
exit 0

heute ist es ein umfangreiches Perl-Script, das auf /sbin/insserv zurückgreift.

Gerade mal in der manpage zu insserv nachgeschaut:


and calculating the dependencies between all scripts. Please note, that the Required-Stop, Should-Stop, and
Default-Stop are ignored in SuSE Linux, because the SuSE boot script concept uses a differential link scheme
(see init.d(7)). With known dependencies and runlevel(s) insserv sets and reorders the corresponding sym-
bolic links of the concerned runlevels directories (see init.d(7)).


chkconfig hin oder her... es stellt sich die Frage, ob man überhaupt so umständlich agieren sollte, sprich:
Runlevel 4 in der /etc/inittab aktivieren, dann noch mit den Services hantieren...

@surfmode : Wäre es nicht einfacher (wenn du `init ...` eingeben musst, bist eh schon eingeloggt), den default Runlevel auf 3 zu stellen und (man könnte mehrere/alle VM-Dienste in einem Script zusammengefasst) bei Bedarf die VM-Services zu starten?

EDIT:
Zur Frage über Kommentar-Zeilen: der Block mit
## BEGIN INIT INFO
.....
## END INIT INFO
wird von insserv ausgewertet.