ZitatKonkret geht es dabei um CPU, RAM, Festplatte?
Jo, so in etwa...
Ich verweise an der Stelle gerne auf ein paar andere Threads der letzten Wochen...
ZitatKonkret geht es dabei um CPU, RAM, Festplatte?
Jo, so in etwa...
Ich verweise an der Stelle gerne auf ein paar andere Threads der letzten Wochen...
Nun, wenn du die PID nicht für zuverlässig hälst, wie gesagt:
Du kannst MAXIMAL 2 Server-Instanzen starten, ohne Ressourcen anderer mitzunutzen. Also lege zwei Benutzer an und starte jede Instanz unter einem eigenen Benutzer.
Und um das ganze zu beenden, machst du das erst sanft per killall, dann hart mit demselben. Was geht da drüber?
Ganz gewiss nicht, ein Terminal mit Screen zu emulieren und die Prozesse grundsätzlich zu killen...
Stimmt. Killall ist nicht wirklich der Bringer. Aber es mit Screen zu machen, ist m.M.n. der GAU.
Davon ab: Was ist an zwei Benutzern statt einem für den CS:S-Server unübersichtlich oder unschön?
Mehr Instanzen kannst du sowieso nicht auf einem vServer mit geteilten Ressourcen ausführen.
vmk: ich zitiere aus dem Code:
Warum nicht einfach die Quick&Dirty-Lösung:
/etc/init.d/srcds1
#!/bin/sh
if [ -z $1 ] ; then
echo "Usage: $0 [start|stop] "
exit 1
fi
case "$1" in
start)
echo "Starte srcds, Instanz 1"
su -c "/home/srcds1/startscript.sh --background" -l srcds1
;;
stop)
echo "Stoppe srcds, Instanz 1"
killall -q -u srcds1
sleep 3
killall -q -s 9 -u srcds1
;;
esac
Alles anzeigen
Dieses Script pro srcds-Instanz mit eigenem Benutzer anlegen und glücklich sein.
Da ein Init-Script normal nur "start" und "stop", eventuell auch "restart" für die Faulen, unterstützen soll und somit a priori nicht mehrere Instanzen unterstützt, würde ich für jeden CS:S-Server ein eigenes Init-Script anlegen. Das ist auch deutlich ressourcenschonender, da es keinen Sinn macht, alle Server gleichzeitig den Server lahmlegen zu lassen.
Was das killall angeht: Entweder, du nutzt pro CS:S-Instanz einen eigenen Benutzer oder läst es "vernünftig" über die PID. Die variable "$!" gibt die PID des letzten BG-Prozesses aus. Musst mal schauen, ob das klappt.
Hey, das war ein Scherzli
Frage doch einfach die Kernelschnittstellen ab und schreibe dies in ein Log (file, db) deiner Wahl.
Also, ich stelle dann immer im DVD-Menü um ;):D
Wenn du in der richtigen Kategorie gepostet hättest, wüssten ein paar mehr, dass du sysCP nutzt.
Das ändert nämlich am Sachverhalt einfach alles.
Ansonsten kann ich immer nur auf die Log-Files verweisen. Die sagen einem exakt, wo das Problem liegt. Um die richtige zu finden, bietet es sich an, einen Aufruf wie http://deine.domain.tld/puh-der-baer abzusetzen, damit man geziehlt nach dem String "puh-der-baer" greppen kann.
Mein v(olks)Server 1G wurde gestern wegen eines Defekts rebootet
Davon gabe es bereits mind. 3 Threads.
Die Forensuche gibt Aufschluss.
Ich habe dir mal in meine rekurive Zone a.1.d.1.8.f.6.0.1.0.0.2.ip6.arpa. folgendes Eingetragen:
a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.3.3.1 IN PTR täst.de.
b.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.3.3.1 IN PTR xn--tst-qla.de.
Probiers mal aus:
2001:6f8:1d1a:1337::a => täst.de.
2001:6f8:1d1a:1337::b => xn--tst-qla.de.
PS: In spätestens 5min kommt die Änderung an.
EDIT: Bind mault bei dem folgenden Eintrag und ignoriert dann scheinbar die nachfolgenden Zeilen:
Umlaute mag er scheinbar nicht. Ob nun die konvertierte Form "xn--tst-qla.de" funzt, müsstest du mal gucken. Die liegt weiterhin auf 2001:6f8:1d1a:1337::b
Richtig, /etc/phpmyadmin.
Die darin enthaltenen Dateien sind selbsterklärend.
Jo, berechtigt.
Es wäre schön, wenn Linux-Admins sich mit solchen elementaren Fragen schon vor Jahren beschäftigt hätten oder wenigstens jetzt ad hoc recherchieren würden...
Das Bild kommt erstaunlich gut hin.
[Ironie]
Aber Hand aufs Herz: Wenn ich durch grottige Software in ein System einbreche, werde ich garantiert an einem billigen .pl-Dateien-lösch-Script scheitern
[/Ironie]
Richtig, der reale PTR-Record hat nichts mit den vHosts zu tun.
Du kannst deinen PTR-Record setzen lassen und damit glücklich sein. Oder du kannst einen vHost beantragen. Diese beiden Dinge haben herzlich wenig miteinander zu tun.
Korrekt. Ein Bouncer besteht aus 2 Teilen:
Dem Client, der sich mit dem IRC-Netz verbindet.
Und dem Server, mit dem sich der Benutzer verbindet.
Ein IRC-Bot hingegen ist nur ein Client und ein alleinstehender IRC-Server hingegen nur ein Server.
Nö, warum.
Bitte halte folgende Begriffsfelder strikt auseinander:
Server - Client
lauschen, empfangen - senden
Sowohl Server als auch die allermeisten Clients öffnen einen Port.
Aber aus völlig unterschiedlichen Ambitionen: Der Server wartet, bis man ihn braucht, der Client wartet auf eine Antwort.
ZitatDas klingt schon fast wie eine Aussage von Microsoft
Für mich klingt es wie die Definition von grober Fahrlässigkeit und extremer Kurzsichtigkeit aus dem Duden.
Da bricht jemand in den Server ein und kann BELIEBIGE Scripts AUSFÜHREN und du möchtest nach Perl-Scripten scannen? Sorry, aber unfassbar.
Das ist ja, als ob man beim Leck in Boot immer fleißig das Wasser aus der Kajüte eimert (die anderen Räume interessieren nicht), statt das Loch zu flicken oder anzulegen (jaaa, ich immer mit meinen Analogien).
Kommt drauf an. In den Mail- und Weblogs wird gerne mal aufgelöst.
Aber stimmt schon: Nur, wenn man eine EINGEHENDE Verbindung von diesem Server bekommt, interessiert man sich in der Regel für den PTR-Record der Domain.
Also nur, wenn eine Anwendung auf dem vServer als Client fungiert.