Curso
Temario
Clasificación de los Procesos...3
Procesos Normales ...3 Procesos Daemon ...3 Procesos Zombies ...3 Comando “ps”...3 Comando “pstree ”...7 Comando “kill” ...8 Comando killall ...9 Manejo de daemons ...9 Comando top ...10 Comando “nice”...11 Comando renice ...12
Entradas y salidas. Redirecciones. ...12
Redirecciones usando tuberías...14
Procesos en primer y segundo plano...15
Comando “bg"...16
Comando “fg” ...16
Comando “nohup”...16
Clasificación de los Procesos
Podríamos definir a los procesos como programas que están corriendo en nuestro Sistema Operativo. Dependiendo de la forma en que corren a estos programas los podemos clasificar en tres grandes categorías:
• Procesos Normales • Procesos Daemon • Procesos Zombies
Procesos Normales
Los procesos de tipo normal generalmente son ejecutados en una terminal (tty) y corren en el sistema operativo a nombre de un usuario.
Procesos Daemon
Los procesos de tipo Daemon se ejecutan a nombre de un usuario y no tienen salida directa por una terminal. Corren en 2o plano. Generalmente los conocemos como servicios. La gran mayoría de ellos en vez de usar la terminal para escuchar un requerimiento lo hacen a través de un puerto.
Procesos Zombies
Todos los procesos que están en ejecución en nuestro Sistema Operativo dependen del primer proceso que se lanza después del arranque: el proceso init, el padre de todos los procesos.
Muchas veces los procesos no son únicos sino que dan lugar a muchos procesos secundarios. Teóricamente el padre de cada uno de ellos debería en todo momento vigilar que es lo que hacen estos hijos. Si por alguna razón este padre falla en el control se pueden llegar a producir procesos de tipo zombie que pueden llenar el árbol de procesos, ocasionando que tengamos que reiniciar el equipo.
¿Podemos ver el árbol de procesos?
En nuestro Sistema Operativo está representado en el directorio /proc, que es una estructura de árbol virtual que genera y monta nuestro kernel durante el arranque.
En virtud de esto, cada vez que queremos ver un proceso debemos mirar por esta ventana y nos muestra realmente qué es lo que está ocurriendo con nuestro kernel.
Para ver el estado de los procesos en el sistema operativo tenemos varios comandos que a continuación iremos explicando sus características.
Comando “ps”
momento. Es como una imagen que se congela y la vemos en la pantalla; pero un segundo después puede estar ocurriendo cualquier otro proceso.
Este comando presenta varias opciones:
equipo1:~# ps
PID TTY TIME CMD 5296 pts/1 00:00:00 bash 5315 pts/1 00:00:00 ps
Si no usamos ninguna opción, este comando nos muestra lo que está ocurriendo en una terminal determinada. Podemos ver que cada proceso tiene un número que lo identifica dentro del sistema, tiene una tty... pero no sabemos si es la única terminal activa o hay más, para eso usamos el parámetro a:
equipo1:~# ps a
PID TTY STAT TIME COMMAND
763 tty4 Ss+ 0:00 /sbin/getty -8 38400 tty4 768 tty5 Ss+ 0:00 /sbin/getty -8 38400 tty5 785 tty2 Ss+ 0:00 /sbin/getty -8 38400 tty2 790 tty3 Ss+ 0:00 /sbin/getty -8 38400 tty3 794 tty6 Ss+ 0:00 /sbin/getty -8 38400 tty6 1076 tty1 Ss+ 0:00 /sbin/getty -8 38400 tty1 3684 pts/0 Ss+ 0:00 bash
5296 pts/1 Ss 0:00 bash 5317 pts/1 R+ 0:00 ps a
Para saber si además de los que vemos correr hay otros procesos en segundo plano, podemos usar el parámetro u. Nos brinda un estado del proceso y qué cantidad de recursos de la CPU está requiriendo cada uno.
equipo1:~# ps u
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jomax 3684 0.0 0.3 8248 2856 pts/0 Ss+ 12:21 0:00 bash jomax 5296 0.4 0.4 8248 3624 pts/1 Ss 16:33 0:00 bash jomax 5319 0.0 0.1 5736 1060 pts/1 R+ 16:35 0:00 ps u
Ahora incluyamos la información de los demonios y procesos sin terminal. Lo hacemos con el parámetro x:
equipo1:~# ps x
PID TTY STAT TIME COMMAND
1071 ? Ssl 0:00 gnome-session
1125 ? Ss 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session gnome-session
1131 ? S 0:00 /usr/bin/dbus-launch --exit-with-session gnome-session
5321 pts/1 R+ 0:00 ps x
Ahora pongamos todos los parámetros juntos!
equipo1:~# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 2892 1312 ? Ss 11:03 0:00 /sbin/init root 2 0.0 0.0 0 0 ? S 11:03 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S 11:03 0:00 [ksoftirqd/0] root 4 0.0 0.0 0 0 ? S 11:03 0:00 [migration/0] root 5 0.0 0.0 0 0 ? S 11:03 0:00 [watchdog/0] root 6 0.0 0.0 0 0 ? S 11:03 0:02 [events/0] root 7 0.0 0.0 0 0 ? S 11:03 0:00 [cpuset] root 8 0.0 0.0 0 0 ? S 11:03 0:00 [khelper] root 9 0.0 0.0 0 0 ? S 11:03 0:00 [netns] root 10 0.0 0.0 0 0 ? S 11:03 0:00 [async/mgr] root 11 0.0 0.0 0 0 ? S 11:03 0:00 [pm] root 12 0.0 0.0 0 0 ? S 11:03 0:00 [sync_supers] root 13 0.0 0.0 0 0 ? S 11:03 0:00 [bdi-default] root 14 0.0 0.0 0 0 ? S 11:03 0:00 [kintegrityd/0] root 15 0.0 0.0 0 0 ? S 11:03 0:01 [kblockd/0] root 16 0.0 0.0 0 0 ? S 11:03 0:00 [kacpid] root 17 0.0 0.0 0 0 ? S 11:03 0:00 [kacpi_notify] root 18 0.0 0.0 0 0 ? S 11:03 0:00 [kacpi_hotplug] root 19 0.0 0.0 0 0 ? S 11:03 0:00 [ata_aux] root 20 0.0 0.0 0 0 ? S 11:03 0:01 [ata_sff/0] root 21 0.0 0.0 0 0 ? S 11:03 0:00 [khubd] root 22 0.0 0.0 0 0 ? S 11:03 0:00 [kseriod] root 23 0.0 0.0 0 0 ? S 11:03 0:00 [kmmcd] root 25 0.0 0.0 0 0 ? S 11:03 0:00 [khungtaskd] root 26 0.0 0.0 0 0 ? S 11:03 0:03 [kswapd0] root 27 0.0 0.0 0 0 ? SN 11:03 0:00 [ksmd] root 28 0.0 0.0 0 0 ? S 11:03 0:00 [aio/0] root 29 0.0 0.0 0 0 ? S 11:03 0:00 [ecryptfs-kthrea] root 30 0.0 0.0 0 0 ? S 11:03 0:00 [crypto/0]
Otro parámetro interesante es el f que nos permite ver los procesos en forma de árbol, determinando así procesos padre y todos los procesos hijos.
equipo1:~# ps fax
3 ? SN 0:00 [ksoftirqd/0] 4 ? S< 0:00 [watchdog/0] 5 ? S< 0:00 [events/0] 6 ? S< 0:00 [khelper] 7 ? S< 0:00 [kthread] 9 ? S< 0:00 \_ [xenwatch] 10 ? S< 0:00 \_ [xenbus] 15 ? S< 0:00 \_ [migration/1] 16 ? SN 0:00 \_ [ksoftirqd/1] 17 ? S< 0:00 \_ [watchdog/1] 18 ? S< 0:00 \_ [events/1] 19 ? S< 0:00 \_ [migration/2] 20 ? SN 0:00 \_ [ksoftirqd/2] 21 ? S< 0:00 \_ [watchdog/2] 22 ? S< 0:00 \_ [events/2] 26 ? S< 0:00 \_ [kblockd/0] 27 ? S< 0:00 \_ [kblockd/1] 28 ? S< 0:00 \_ [kblockd/2] 29 ? S< 0:00 \_ [cqueue/0] 30 ? S< 0:00 \_ [cqueue/1] 31 ? S< 0:00 \_ [cqueue/2] 35 ? S< 0:00 \_ [khubd] 37 ? S< 0:00 \_ [kseriod] 111 ? S 0:00 \_ [khungtaskd] 112 ? S 0:00 \_ [pdflush] 114 ? S< 0:48 \_ [kswapd0] 115 ? S< 0:00 \_ [aio/0] 116 ? S< 0:00 \_ [aio/1] 117 ? S< 0:00 \_ [aio/2] 247 ? S< 0:00 \_ [kpsmoused] 303 ? S< 0:00 \_ [kstriped] 324 ? S< 0:00 \_ [kjournald] 4329 ? S 0:00 \_ [pdflush] 399 ? S<s 0:00 /sbin/udevd --daemon 1171 tty4 Ss+ 0:00 /sbin/getty 38400 tty4 1172 tty5 Ss+ 0:00 /sbin/getty 38400 tty5 1175 tty2 Ss+ 0:00 /sbin/getty 38400 tty2 1176 tty3 Ss+ 0:00 /sbin/getty 38400 tty3 1178 tty6 Ss+ 0:00 /sbin/getty 38400 tty6 1222 ? Ss 0:00 /sbin/syslogd -u syslog
1240 ? S 0:00 /bin/dd bs 1 if /proc/kmsg of /var/run/klogd/kmsg
1242 ? Ss 0:00 /sbin/klogd -P /var/run/klogd/kmsg 1305 ? Ss 0:45 /usr/sbin/openvpn --writepid
/var/run/openvpn.openvpn.pid --daemon ovpn-openvpn --cd /etc/openvpn --config /etc/openvpn/openvpn.conf --scrip
1323 ? Ss 0:00 /usr/sbin/sshd 22808 ? Ss 0:00 \_ sshd: jomax [priv] 22810 ? S 0:00 \_ sshd: jomax@pts/1 22811 pts/1 Ss 0:00 \_ -bash 22834 pts/1 R+ 0:00 \_ ps fax 1371 ? S 0:00 /bin/sh /usr/bin/mysqld_safe 1413 ? Sl 0:00 \_ /usr/sbin/mysqld --basedir=/usr
--datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --po
1414 ? S 0:00 \_ logger -p daemon.err -t mysqld_safe -i -t mysqld
1490 ? S 0:00 /usr/bin/memcached -m 64 -p 11211 -u nobody -l 127.0.0.1
1572 ? S 0:00 \_ qmgr -l -t fifo -u 2225 ? S 0:00 \_ tlsmgr -l -t unix -u -c 22564 ? S 0:00 \_ pickup -l -t fifo -u -c 22822 ? S 0:00 \_ cleanup -z -t unix -u -c
22823 ? S 0:00 \_ trivial-rewrite -n rewrite -t unix -u -c 22826 ? S 0:00 \_ smtp -t unix -u -c
1622 ? Ss 0:00 /usr/sbin/cron
1667 ? Ss+ 0:00 /sbin/getty 38400 xvc0
3633 ? Sl 0:03 python /usr/share/ajaxterm/ajaxterm.py --daemon --port=8022 --serverport=9200 --uid=ajaxterm
11676 pts/0 Ss+ 0:00 \_ python /usr/share/ajaxterm/ajaxterm.py --daemon --port=8022 --serverport=9200 --uid=ajaxterm
4139 ? Ssl 0:00 /usr/sbin/named -u bind 8497 ? Ss 0:00 /usr/sbin/apache2 -k start 17256 ? S 0:20 \_ /usr/sbin/apache2 -k start 19489 ? S 0:11 \_ /usr/sbin/apache2 -k start 19491 ? S 0:14 \_ /usr/sbin/apache2 -k start 19493 ? S 0:14 \_ /usr/sbin/apache2 -k start 21340 ? S 0:06 \_ /usr/sbin/apache2 -k start 21403 ? S 0:05 \_ /usr/sbin/apache2 -k start 21548 ? S 0:05 \_ /usr/sbin/apache2 -k start 21549 ? S 0:05 \_ /usr/sbin/apache2 -k start 21550 ? S 0:06 \_ /usr/sbin/apache2 -k start 22018 ? S 0:02 \_ /usr/sbin/apache2 -k start 22020 ? S 0:04 \_ /usr/sbin/apache2 -k start
Comando “pstree ”
Este comando nos muestra el árbol de procesos y el número que el sistema le otorga a cada uno.
├─migration/0(2) ├─named(4139)─┬─{named}(4140) │ ├─{named}(4141) │ ├─{named}(4142) │ ├─{named}(4143) │ └─{named}(4144) ├─openvpn(1305) ├─python(3633)─┬─python(11676) │ └─{python}(3634) ├─syslogd(1222) ├─udevd(399) └─watchdog/0(4)
Aquí solo podemos ver de qué proceso depende el programa en el cual estamos trabajando.
Comando “kill”
Como administradores del sistema necesitamos saber en todo momento lo que ocurre y necesitamos poder comunicarnos de alguna manera con los procesos para controlarlos.
Cada uno de los procesos en curso, pueden recibir de nosotros una serie de señales representadas aquí por el comando kill o killall. Con ellas podemos decirle a un proceso que termine inmediatamente. Si es un servicio podemos pedirle que se reinicie.
Las señales son muchas y son usadas por los programadores para tener control total sobre sus programas. Las vamos a enumerar y probaremos las que más vamos a usar.
Las señales se pueden enumerar con el comando kill y el parámetro l:
Ejemplo:
equipo1:~# kill –l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX
Las de mayor uso para nosotros van a ser las número 1,9 y 15 que son las de: recargar la
configuración, matar y terminar respectivamente.
Imaginemos que tenemos corriendo en una terminal una aplicación o un comando, y esa aplicación o comando no responde a nada ( ̈se colgó ̈).
Lo primero que debemos hacer es preguntarle al sistema operativo cuál es el PID de ese proceso colgado y después pasarle la señal de terminación o de matar.
Ejercicio:
Nos logueamos en otra terminal y ejecutamos el Midnight Commander (mc), es una aplicación parecida al Norton Commander de DOS. Volvemos a la consola anterior y ejecutamos el comando ps -aux para ver cuál es el PID del mc. Luego, corremos el comando kill -15 <PID del mc>.
Donde antes estaba el cursor ahora dice Terminated.
Repitamos los pasos, pero ahora usen kill -9 <PID del MC>, observen los resultados.
Comando killall
Para enviar señales a los servicios podemos usar el comando killall. Este comando no nos pide el PID, nos basta con poner el nombre de la aplicación.
equipo1:~# killall apache2
Con esto nos ahorramos el paso de ejecutar el ps para saber cuál es el PID.
Manejo de daemons
Los demonios (Daemons) son programas que corren en segundo plano, no tienen salida directa por la terminal. Reaccionan frente a algo que ocurre.
Normalmente decimos que un demonio "escucha" en un determinado puerto.
Ejemplo:
el demonio de las páginas web se llama apache2 y "escucha" en el puerto 80.
Estos demonios tienen un archivo de configuración que les dice cómo tienen que escuchar para estar atentos y responder a las peticiones.
Para arrancar también tienen su forma particular, parámetros que ya están definidos. Los programadores dejan lo que conocemos como scripts de arranque de servicio.
Repasando:
En las clases de arranque vimos que se guardan todos en un mismo directorio que es /etc/init.d/, y que todos aceptan el parámetro start, stop, restart (levantar, parar, reiniciar).
Cada servicio que queremos levantar tiene su propia forma de hacerlo. Para poder levantar o terminar un servicio, tenemos varias opciones:
Si queremos detener el servicio usamos stop en vez de start, y si queremos pararlo y después levantarlo usamos restart.
Si queremos saber si está corriendo podemos usar el parámetro stat (éste último nos devolverá el PID).
En realidad estos scripts están usando el sistema de señales que vimos arriba, pero predefinidas por los programadores de los servicios.
Comando top
Otra forma de ver los procesos que corren en el sistema operativo la encontramos en el comando top.
Este comando a diferencia del ps nos permite ver los procesos de manera dinámica, es decir en el mismo momento en que se lanzan.
Este comando en realidad tiene un tiempo de actualización de lectura de procesos.
Veamos un ejemplo:
equipo1:~# top
top - 16:55:21 up 3 days, 19:45, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 74 total, 2 running, 72 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
El comando top además de ser dinámico es interactivo. Esto significa que podemos ejecutar comandos dentro del top.
Si queremos cambiar el tiempo de actualización podemos presionar la letra "s" y nos va a preguntar cada cuántos segundos queremos hacer un refresco de pantalla. Si colocamos (0.1) vamos a ver que se actualiza
mucho más rápido.
También nos muestra más información, como por ejemplo: • ¿cuándo se encendió el equipo?
• ¿cuántos procesos están corriendo?
• ¿cuántos de ellos son normales, daemon, o zombies? Todos estos datos los recoge del directorio /proc.
En este comando también aparecen dos columnas que antes no estaban: • una con encabezado PRI
• otra con encabezado NI
PRI: es la prioridad, la cantidad de recursos que el sistema le otorga a un programa que está
corriendo. Cuantos más recursos tiene un programa, mayor es la velocidad con la que corre. En el caso de GNU/Linux, es el kernel el que sabe con qué cantidad de recursos cuenta y le va preguntando a cada PID si necesita recursos. Si el programa no los necesita en ese momento se los devuelve al S.O. para que siga preguntando a los demás. Cuando termina vuelve a empezar y así sigue mientras el equipo está encendido.
La prioridad se mide en una escala que normalmente va desde:
|---|---| -20 0 20
|________usuarios_______|
|______________________root_____________________|
La prioridad negativa significa muchos recursos y la positiva pocos Conclusión
Los procesos que tienen prioridad negativa van a ir más rápido que los que tengan mucha. Solamente root puede usar toda la escala, mientras que los usuarios comunes sólo pueden usar la escala en su parte positiva.
Comando “nice”
otorgarnos la prioridad requerida. Si no pudiera hacerlo, nos daría lo máximo posible (siempre es menos que la prioridad requerida).
Ejecución del comando:
equipo1:~# nice --20 <comando>
Esta es la prioridad negativa, el primer menos es para pasar el parámetro el segundo para la prioridad.
Para el siguiente ejemplo tenemos que estar logueados en dos terminales, en una de ellas dejamos corriendo el comando top. En la otra mientras tanto ejecutaremos el siguiente comando.
equipo1:~# nice --20 updatedb
Luego vamos a la otra consola y veremos cuánta prioridad le otorgó el Sistema Operativo.
Una vez que sabemos cuál es el PID de este proceso podemos cambiarle la prioridad sobre la marcha.
Vamos a seguir... no cierren el comando top.
Comando renice
Este comando lo utilizamos para cambiar sobre la ejecución de un proceso su prioridad.
equipo1:~# renice 20 <pid del updatedb anterior>
Observemos que ahora este comando no lleva el "-" para pasar parámetros. En este caso estoy pasando a la prioridad positiva.
Veamos lo que está ocurriendo en la consola donde tenemos levantado el comando top.
También podemos cambiarle la prioridad a un proceso desde el comando top, para ello debemos presionar la letra "n", una vez que lo hagamos nos va a preguntar cuál va a ser el PID al que le queremos cambiar la prioridad y después de presionar <enter> nos va a preguntar cuál es la nueva prioridad que queremos asignar.
Entradas y salidas. Redirecciones.
Todos los procesos para poder lanzarse necesitan tener lo que se conoce como entrada stándar (stdin) y devuelven como resultado dos archivos que son capturados por la terminal en la cual estamos trabajando.
Esos dos archivos se conocen como standar output (stdout) y standar error (stderr).
Ejemplo:
Cuando se ejecuta el comando ls, esta es su standar input que generalmente la escribimos por el teclado, inmediatamente después el Sistema Operativo procesa el comando y como resultado de ello vemos los dos archivos. Uno no se ve porque está vacío, eso no quiere decir que no exista.
Gráficamente:
Como las salidas stdout y stderr son archivos, los podemos trabajar como archivos y los archivos pueden ser capturados; o bien por la terminal o (y esto es lo más interesante) también pueden direccionarse a otros archivos.
Para ello vamos a usar el símbolo ">". Pongamos un ejemplo:
equipo1:~# ls / > ls.txt
Como el directorio / existe, este comando direcciona el stdout al archivo y por la pantalla no vemos nada, esa nada que estamos viendo es en realidad la stderr.
Veamos ahora el contenido del archivo ls.txt ejecutando:
proc root sbin selinux serv srv sys tmp usr var
Para poder capturar ahora el sterr probemos lo siguiente.
equipo1:~# ls /noexiste 2> ls.txt
Ahora por pantalla no vemos nada, ese nada significa en realidad que el stout está vacío y el error se direccionó a ls.txt.
Hagan un cat al ls.txt para ver la salida de error.
Si queremos capturar los dos juntos stdout y stderr ejecutamos:
equipo1:~# ls / > ls.tx 2>&1
Esto hace que se unifiquen las salidas, que es en realidad lo que hace nuestra tty.
Observemos que si ejecutamos este comando varias veces veremos que solamente nos guarda en el archivo la ultima stdout ó stderr.
Para agregar las salidas al archivo debemos ejecutar:
equipo1:~# ls / >> ls.tx 2>&1
Con este doble mayor ">>" hacemos que las salidas se unifiquen y podemos ver en un archivo todas las salidas posibles.
Redirecciones usando tuberías
Tenemos otra forma de trabajar con las salidas, y es transformar la salida stdout de un comando en stdin de otro.
¿Cómo hacemos esto?
Lo hacemos con el símbolo "|", este procesamiento se conoce como pipes ó tuberías.
Vamos a aprovechar lo visto antes: como la salida stdout es un archivo podemos filtrarlo o pasarlo más lento.
Como es un archivo, lo podríamos pasar por un comando para manejar archivos y así visualizarlo del modo que nos guste. Veamos cómo hacerlo:
equipo1:~# ls -R / | less
En este ejemplo podemos ejecutar el comando haciendo que la salida stdout se pase por el comando less.
Otro ejemplo, queremos buscar dentro del directorio /etc todos los archivos que terminen con .conf.
equipo1:~# ls -R /etc | grep .conf$ cdrecord.conf esd.conf fam.conf gconf gpm-root.conf grub.conf host.conf ... ¿Qué sucedió?
Redireccionamos la salida del ls -R al grep con la orden de que filtre sólo los archivos que contengan .conf
Veamos ahora un ejemplo de una tubería de tres partes:
Queremos buscar todos los procesos que contengan la palabra apache, exceptuando los que digan grep apache2.
equipo1:~# ps -ax | grep apache2 | grep -v grep
8497 ? Ss 0:00 /usr/sbin/apache2 -k start 19489 ? S 0:13 /usr/sbin/apache2 -k start 19493 ? S 0:15 /usr/sbin/apache2 -k start 21340 ? S 0:08 /usr/sbin/apache2 -k start 21403 ? S 0:06 /usr/sbin/apache2 -k start 21548 ? S 0:07 /usr/sbin/apache2 -k start 21549 ? S 0:06 /usr/sbin/apache2 -k start 21550 ? S 0:08 /usr/sbin/apache2 -k start 22018 ? S 0:04 /usr/sbin/apache2 -k start 22020 ? S 0:05 /usr/sbin/apache2 -k start 22903 ? S 0:01 /usr/sbin/apache2 -k start 22919 ? S 0:00 /usr/sbin/apache2 -k start 23001 ? S 0:00 /usr/sbin/apache2 -k start
Con este comando estamos filtrando dos veces la stdout del comando ps.
Primero le decimos que nos muestre todo lo que dice apache y después que no nos muestre lo que diga grep.
Procesos en primer y segundo plano
Para que los procesos corran en segundo plano debemos usar otro símbolo: ̈& ̈
Ejemplo:
Si queremos correr una compilación y al mismo tiempo usar la consola para trabajar; o queremos descargar algo de internet y queremos seguir trabajando en la consola de texto. En ese caso podemos ejecutar el comando seguido del símbolo &.
equipo1:~# top& [1] 1567
Esto nos dice que el comando top ya no tiene una salida stdout por la consola sino que está corriendo con un PID igual a 1567 y tiene un número de trabajo asignado que es [1].
Para saber cuántos trabajos tenemos corriendo en segundo plano podemos ejecutar el comando jobs.
Ejemplo:
equipo1:~# jobs [1] stopped topg
Comando “bg"
Este comando permite que el proceso se reinicie en el segundo plano. ... continuemos con el ejemplo anterior:
equipo1:~# bg %1
Debemos tener en cuenta que aquí no se coloca el PID sino que en su lugar se coloca el número de job. Lo que hicimos fue reiniciar en background el trabajo número 1 que estaba detenido cuando tiramos en consola el comando jobs.
Comando “fg”
Este comando nos sirve para traer el proceso al primer plano. En él también se utilizan los números de trabajo.
equipo1:~# fg %1
Una vez pasado el comando al primer plano podemos enviarlo de nuevo al segundo plano presionando <ctrl>z. Control y la letra "z" simultáneamente.
Comando “nohup”
Este comando permite que los procesos corran en forma independiente de la terminal y del login del usuario.
Es muy útil cuando queremos bajar programas de internet que demoran mucho tiempo.
Sintaxis del comando:
equipo1:~# nohup ls /
Se creará en el directorio actual un archivo que se llama nohup.out. Podemos ver su contenido tipeando:
equipo1:~# cat nohup.out
Servicios en el sistema operativo
Los servicios son aquellos programas que corren como daemon. Cada uno tiene su propio script de arranque y parada. Como ya vimos estos scripts están guardados en el directorio /etc/init.d. Recordemos que nuestro sistema tiene cinco niveles de corrida, pero sólo un directorio para todos los scripts de arranque.
Esto nos lleva a la pregunta ¿Cómo se da cuenta GNU/Linux cual es el servicio que tiene que arrancar, por ejemplo para el nivel de corrida 2?.
El S.O. tiene directorios dentro de /etc/ que se llaman rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, cada uno de ellos tiene links de tipo soft a alguno de estos Scripts. Estos links a su vez comienzan con la letra K o la letra S.
Cuando el Sistema Operativo arranca, o se cambia de nivel de corrida, traduce los que empiezan con S como "arrancar" y los que empiezan con K "no arrancar".
