2010-06-10 5 views
7

Ich habe ein Skript, das Killproc und Procopdid Befehle verwendet und auf einer 64bit-suse fein ausführt. Aber als ich das Skript auf 32bit redhat ausführte, fand ich, dass die obigen Befehle nicht existieren.killproc und pidofproc auf linux

Ich habe keine 32bit Suse und 64bit redhat Maschinen, um mein Skript zu testen.

Ist meine Vermutung richtig, dass auf 64bit redhat die oben genannten Befehle verfügbar sein sollten? Oder sind die obigen Befehle spezifisch für Suse und redhat?

Dank

+1

Nein, aber 'kill' und' pidof' ist, die auch tragbar. –

Antwort

4

Die Befehle sind wahrscheinlich nicht tragbar. Das ist das erste Mal, dass ich von ihnen höre - aber ich denke, dein Problem ist es, mit dem Prozess mit dem Namen zu arbeiten, nicht mit pid.

Überprüfen Sie die man pgrep oder man pkill - sie sind ein bisschen mehr tragbar. Sie sind Teil von procps Paket (wobei ps und 10 kommen) und sollte auf allen Linux-Varianten verfügbar sein. Sie sind auch unter Solaris verfügbar.

0

Ich denke, diese Befehle sind distrib Besonderheiten: Ich habe sie noch nie gesehen. Killproc sollte eine Art von töten sein, aber was soll Procopwid tun?

In dem Titel sprechen Sie über pidofproc, Sie können diesen Befehl unter dem Pidof auf den meisten Linux-Boxen finden.

-1

hatte ich das gleiche Problem wie du, es die Warnung gab:

pidof: ungültige Optionen auf der Kommandozeile!

Ich änderte die

"killproc -d 10 $cmd" 

zu

"kill -9 \`pidof $cmd\`" 
8

killproc in RedHat Enterprise Linux ist 5.4 als Teil /etc/init.d/functions

wenn Sie es brauchen tun Sie einfach

. /etc/init.d/functions

in Ihrem Skript, um die Shell-Funktionen zu laden, ist es wahrscheinlich in anderen Versionen von Red Hat, aber das ist die einzige, die ich im Moment

6

Diese Befehle sind defined als Teil der Linux Standards Base (LSB), wie von @AndreKR angegeben.

Bei einigen Systemen wie Redhat (und wahrscheinlich SUSE) sind diese Funktionen jedoch abhängig von den installierten Paketen möglicherweise nicht an der vom LSB angegebenen Stelle definiert, also /lib/lsb/init-functions. Vielmehr sind sie innerhalb /etc/init.d/functions definiert. Außerdem fehlt in einigen Versionen der Redhat-Variante /etc/init.d/functions die LSB-definierte Funktion start_daemon.Wenn Sie das folgende Snippet zum Anfang des Skripts hinzufügen, sollte es in den meisten Distributionen tragbar sein/installiert:

if [[ -f /lib/lsb/init-functions ]]; then 
    . /lib/lsb/init-functions 
elif [[ -f /etc/init.d/functions ]]; then 
    . /etc/init.d/functions 
    # Pretend to be LSB-compliant 
    function start_daemon() { 
    daemon $* 
    } 
else 
    echo "Linux LSB init function script or Redhat /etc/init.d/functions is required for this script." 
    echo "See http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html" 
    exit 1 
fi 
+0

Ihre Aussage 'Redhat (und wahrscheinlich SUSE) definiert sie nicht an dem durch das LSB spezifizierten Ort' ist falsch. Das Meta-Paket 'lsb-core-noarch' stellt die Datei'/lib/lsb/init-functions' in LSB-konformen Distributionen zur Verfügung. Verwenden Sie einfach den Distribution Package Manager zur Installation. – Samveen

+0

@Samveen Vielen Dank für die Klarstellung und Informationen zum 'lsb-core-noarch' Paket. FWIW, auf Fedora 24 ist es "redhat-lsb-core". Das Skript-Snippet ist immer noch nützlich, wenn Sie nicht sicher sind, ob in Laufzeitumgebungen das Paket installiert ist oder nicht, und Sie keine Möglichkeit haben, die Installation zu erzwingen. – Raman

+0

Bitte überprüfen Sie das 'provides' für das' redhat-lsb-core' Paket: Sie werden feststellen, dass es 'lsb-core-noarch' liefert, was ein' meta-Paket' ist, wie ich in meinem Kommentar erwähnt habe ([rpmfind info] (https://www.rpmfind.net/linux/RPM/fedora/updates/24/x86_64/r/redhat-lsb-core-4.1-33.fc24.x86_64.html)). – Samveen