Curso Linux Admin Procesos
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 Servicios en el sistema operativo...17
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 Este comando es el encargado de mostrar todos los procesos que están ocurriendo en el sistema. Este comando no es interactivo, saca una foto de los procesos que están corriendo en ese mismo - 3 -
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 --exitwith-session gnome-session 1131? S 0:00 /usr/bin/dbus-launch --exit-with-session gnomesession 1244? S<sl 2:57 /usr/bin/pulseaudio --start --log-target=syslog 1302? Ssl 0:36 /home/jomax/.dropbox-dist/dropbox 1348? S 0:00 /usr/bin/python /usr/lib/ubuntu-ssoclient/ubuntu-sso-login 1549? Sl 0:34 update-notifier 1749? Sl 1:16 xchat 3680? Sl 1:06 gnome-terminal 3683? S 0:00 gnome-pty-helper 3684 pts/0 Ss+ 0:00 bash 4943? Sl 0:00 /usr/lib/d-conf/dconf-service 5296 pts/1 Ss 0:00 bash - 4 -
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 [bdidefault] 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 [ecryptfskthrea] 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 PID TTY STAT TIME COMMAND 1? Ss 0:00 /sbin/init 2? S< 0:00 [migration/0] - 5 -
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 1561? Ss 0:00 /usr/lib/postfix/master - 6 -
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. equipo1:~# pstree p init(1) apache2(8497) apache2(19489) apache2(19493) apache2(21340) apache2(21403) apache2(21548) apache2(21549) apache2(21550) apache2(22018) apache2(22020) apache2(22903) apache2(22919) apache2(23001) cron(1622) dd(1240) events/0(5) getty(1171) getty(1172) getty(1175) getty(1176) getty(1178) getty(1667) khelper(6) klogd(1242) ksoftirqd/0(3) master(1561) pickup(22564) qmgr(1572) tlsmgr(2225) memcached(1490) - 7 -
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. Para pasar una señal a un proceso necesito conocer el PID (Process ID ó Número del Proceso), de ahí la importancia del comando ps. - 8 -
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: equipo1:~# /etc/init.d/<nombre servicio> start - 9 -
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 Mem: 1048576k total, 766224k used, 282352k free, 69084k buffers Swap: 3145704k total, 65660k used, 3080044k free, 194004k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 15 0 4096 612 532 S 0 0.1 0:00.01 init 2 root RT -5 0 0 0 S 0 0.0 0:00.18 migration/0 3 root 34 19 0 0 0 S 0 0.0 0:00.00 ksoftirqd/0 4 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/0 5 root 10-5 0 0 0 S 0 0.0 0:00.00 events/0 6 root 10-5 0 0 0 S 0 0.0 0:00.00 khelper 7 root 10-5 0 0 0 S 0 0.0 0:00.00 kthread 9 root 10-5 0 0 0 S 0 0.0 0:00.00 xenwatch 10 root 10-5 0 0 0 S 0 0.0 0:00.00 xenbus 15 root RT -5 0 0 0 S 0 0.0 0:00.11 migration/1 16 root 34 19 0 0 0 S 0 0.0 0:00.00 ksoftirqd/1 17 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/1 18 root 10-5 0 0 0 S 0 0.0 0:00.00 events/1 19 root RT -5 0 0 0 S 0 0.0 0:00.16 migration/2 20 root 34 19 0 0 0 S 0 0.0 0:00.00 ksoftirqd/2 21 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/2 22 root 10-5 0 0 0 S 0 0.0 0:00.00 events/2 26 root 10-5 0 0 0 S 0 0.0 0:00.00 kblockd/0 27 root 10-5 0 0 0 S 0 0.0 0:00.00 kblockd/1 28 root 10-5 0 0 0 S 0 0.0 0:00.00 kblockd/2 29 root 20-5 0 0 0 S 0 0.0 0:00.00 cqueue/0 30 root 10-5 0 0 0 S 0 0.0 0:00.00 cqueue/1 31 root 10-5 0 0 0 S 0 0.0 0:00.00 cqueue/2 35 root 20-5 0 0 0 S 0 0.0 0:00.00 khubd 37 root 10-5 0 0 0 S 0 0.0 0:00.00 kseriod 111 root 15 0 0 0 0 S 0 0.0 0:00.00 khungtaskd 112 root 15 0 0 0 0 S 0 0.0 0:00.26 pdflush - 10 -
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 Cuando un proceso es nuevo podemos configurar con qué prioridad va a correr, es decir con cuántos recursos va a contar. Pero el usuario no le puede pedir directamente al Sistema Operativo prioridad sino que se lo puede pedir en forma de nice, y después el S.O. evaluará si puede - 11 -
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). Cuando el archivo stdout está lleno, el stderr está vacío. Y cuando el stderr está lleno, el que está vacío es el stdout. - 12 -
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: equipo1:~# cat ls.txt bin boot dev etc home lib lib64 lost+found media mnt opt - 13 -
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. Supongamos que queremos hacer un ls -R del directorio / este comando nos devuelve un archivo muy grande con todos los archivos y directorios que hay en el Sistema Operativo, pero las pantallas pasan demasiado rápido y no podemos ver qué es realmente lo que hay. - 14 -
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 Todos los procesos de tipo normal corren en primer plano pero los procesos de tipo daemon NO, estos corren en background. - 15 -
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. Genera un archivo que se llama nohup.out donde guarda las stdout (standar output) y la stderr (stderr) y permite que el usuario ejecute un logout sin que los procesos dejen de correr. - 16 -
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". Cuando queremos hacer que uno de estos servicios se levanten en el nivel de corrida por nosotros seleccionado debemos cambiar la letra "K" por la letra "S". - 17 -