2010-06-10 21 views
7

Tengo un script que usa los comandos killproc y procofpid y se ejecuta correctamente en un suse de 64 bits. Pero cuando ejecuté el script en 32bit redhat, encontré que los comandos anteriores no existen.killproc y pidofproc en Linux

No tengo máquinas de 32 bits Suse y 64bit redhat para probar mi script.

¿Tengo razón en que en 64bit redhat los comandos anteriores deberían estar disponibles? ¿O son los comandos anteriores específicos de Suse y redhat?

Gracias

+1

No, pero '' kill' y pidof' son, que también son portátiles. –

Respuesta

4

Es poco probable que los comandos sean portátiles. En realidad, esta es la primera vez que escucho sobre ellos, pero supongo que su problema es trabajar con el proceso por el nombre, no pid.

Compruebe man pgrep o man pkill - son un poco más portátiles. Son parte del paquete procps (de donde provienen ps y top) y deberían estar disponibles en todas las variantes de Linux. También están disponibles en Solaris.

0

creo que esos comandos son específicos distrib: nunca los he visto antes. killproc debería ser una especie de asesinato, pero ¿qué se supone que procofpid debe hacer?

En el título usted habla sobre pidofproc, puede encontrar este comando debajo del pidof en la mayoría de los cuadros de linux.

-1

que tenían el mismo problema que tú, le dio la advertencia:

pidof: opciones no válidas en la línea de comandos!

he cambiado el

"killproc -d 10 $cmd" 

a

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

killproc está en RedHat Linux Enterprise 5.4 como parte de /etc/init.d/functions

si lo necesita solo haga

. /etc/init.d/functions

en la secuencia de comandos para cargar las funciones de shell, su probablemente en otras versiones de RedHat, pero esa es la única que tengo a mano en el momento

6

Estos comandos son defined como parte del Linux Standards Base (LSB), según lo observado por @AndreKR.

Sin embargo, en algunos sistemas como Redhat (y probablemente SUSE), dependiendo de los paquetes instalados, estas funciones no se pueden definir en la ubicación especificada por el LSB, que es /lib/lsb/init-functions. Más bien están definidos dentro de /etc/init.d/functions. Además, en algunas versiones, la variante Redhat de /etc/init.d/functions falta la función definida por LSB start_daemon.Si se agrega el siguiente fragmento de la parte superior de la secuencia de comandos, debe ser portable a través de la mayoría de las distribuciones/instala:

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

Su afirmación 'Redhat (y probablemente SUSE) no los define en la ubicación especificada por el LSB' es falsa. El meta paquete 'lsb-core-noarch' proporciona el archivo'/lib/lsb/init-functions' a través de distribuciones compatibles con LSB. Simplemente use el administrador del paquete de distribución para instalarlo. – Samveen

+0

@Samveen Gracias por la aclaración y la información sobre el paquete 'lsb-core-noarch'. FWIW, en Fedora 24, es 'redhat-lsb-core'. El fragmento de script sigue siendo útil si no está seguro de si los entornos de tiempo de ejecución tienen el paquete instalado o no, y no tiene la capacidad o el deseo de forzar su instalación. – Raman

+0

Por favor, compruebe el 'proporciona' para el paquete' redhat-lsb-core': notará que 'proporciona' una capacidad' lsb-core-noarch' que es un 'meta package', como mencioné en mi comentario ([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