El directorio /proc en Linux

#1   Curioso, no sabía que estaba en memoria.

#2   #1 creo que ni está en la memoria ni es un directorio, es un sistema de ficheros virtual que no accede a ningún disco, implementa el acceso a la memoria y a las estructuras de datos que en ella maneja el kernel. Aquí habrá alguien que lo sepa.

#3   #1 #2 Lo cojonudo de unix es que todo es un archivo

#4   #2 Creo que es exactamente lo que se dice en el artículo. Te copio y pego una frase del post:
"¿De dónde salen entonces todos estos archivos y directorios? La respuesta es: directamente del Kernel."

#5   Bastante flojo el artículo. Sólo una explicación genérica. Apenas explica los subdirectorios y archivos que hay más allá de una breve descripción (y no de todos).

#3 Cojonudo cuando tienes que hacer scripts de administración. Cuando estás haciendo aplicaciones en lenguajes compilados ya no es tan cojonudo tener que andar “parseando” archivos para obtener esa información en lugar obtenerla directamente mediante llamadas a funciones.

Pero, ojo, que no lo critico, al contrario, me parece una idea excepcional que “todo” en Linux/UNIX sea un archivo.

#6   #5 Pero flojo y generico. Si al menos hubiera mencionado que cada directorio "numerado" se refiere al proceso con ese PID, y una descripción rápida del contenido de ellos.

#7   Ya ha terminado la crisis?

#8   #4 Exacto. No he podido leer el artículo (efecto meneame?), pero ejemplo típico de manipulación del comportamiento del sistema a través de proc siempre fue activar el ip_forwarding (para que tu máquina hiciera de router, por ejemplo pasando los paquetes de la wifi a traves de eth0 y así compartir el cable). Eso sí, hace tanto que no lo hago que no se si sigue haciendose así

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/ip_forward

#9   #5 ¿De verdad prefieres esto msdn.microsoft.com/en-us/library/ms682629.aspx y andar peleándote con estructuras que leer ficheros de nombres conocidos (como cmdline) de directorios bajo /proc?

Yo lo veo más sencillo, y debugeable, bajo UNIX... pero bueno, allá cada uno. Y tengamos en cuenta que no hay que leer en ningún disco, está todo en RAM.

iSaludos!

#10   #5 puedes acceder a exactamente la misma informacion mediante llamadas al sistema. Desde C es muy sencillo, pero ya te toca leerte un poco de documentacion (parametros, valores devueltos...).

#11   #8 En teoria, hace ya un tiempo que la manera correcta seria con sysctl:

sysctl -w net.ipv4.ip_forward=1

#12   #4 #8 O para ver el estado de la batería cat /proc/acpi/battery/BAT0 (si es la única que tienes)

O ver cuántas CPUs tienes: cat /proc/cpuinfo | grep vendor_id | wc -l

Es básicamente lo que hace el SO, crear una capa de abstracción del sistema para que lo usen las aplicaciones, Windows lo hace mediante un montón de llamadas de sistema mediante interrupciones software para las que necesitas un montón de libracos (u hoy en día, el MSDN) mientras que en UNIX es bastante asequible navegar por los directorios del sistema buscando lo que necesitas.

#13   #5 #10 UNIX y C están integrados a la perfección.

en.wikipedia.org/wiki/System_call

#14   #3 Lo cojonudo es que hoy en día /proc casi que sólo se ve en Linux, que no es UNIX
#5 Échale un vistazo al código del comando ps, utiliza /proc/ y no llamadas a funciones.

#15   #10 Uhmm, ¿seguro que para toda la información que es posible conseguir en /proc hay llamadas al sistema equivalentes? Yo diría que no, más bien al contrario, las llamadas al sistema cubren un subconjunto relativamente pequeño de esa información que es tan relevante como para programar librerías en C que accedan a ellas. Pero vamos, hablo un poco por intuición.

#16   Y no habla de /sys? supuestamente era el sistema que debia destronarlo, pero no se en qué quedó. Hoy dia se usan los dos, pero no se si uno más que otro para ciertas cosas

#17   #11 Si lo haces con sysctl tu ordenador hara ip forwarding siempre,si solo quieres probarlo lo recomendable es hacerlo con /proc ya que al reiniciar volverá al estado normal.
A parte creo que para que se apliquen los cambios de sysctl al instante debes hacer un sysctl -P o sino se aplicaran cuando reinicies

#18   #2 ni tiene ningún sentido que eso esté en disco si lo piensas un poco

#19   #17 No. Por un lado los cambios son tb inmediatos. Y para que queden fijos tienes que modificar /etc/sysctl.conf, o incluir el comando en algun script de arranque. Con sysctl -p (con -P no hace nada, al menos en ubuntu y según man), vuelves a cargar /etc/sysctl.conf, o el fichero que le indiques. p.e.:

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/ip_forward

se convertiria en:

sysctl -w net.ipv4.ip_forward=1
sysctl -p

El mayor coñazo, es que no puedes usar el autocompletar . También creo recordar que había alguna distro, que no permitía usar el echo para cambiar a la manera antigua, imagino que por la configuración del sudo, SElinux o Apparmor.

#20   #17 #19 Sysctl es la forma "portable" de hacer las cosas, al existir en BSD y por extensión en OSX.
De por sí, en linux los siguientes son equivalentes:

cat /proc/sys/net/ipv4/ip_forward
sysctl net.ipv4.ip_forward

echo 1 > /proc/sys/net/ipv4/ip_forward
sysctl net.ipv4.ip_forward=1
sysctl -w net.ipv4.ip_forward=1

No hay que confundir el sysctl a secas, llamada equivalente a "syscall(SYS__sysctl, &args)" (man 2 sysctl), con el fichero de configuración /etc/sysctl.conf y el directorio asociado /etc/sysctl.d, que contienen los valores a cargar al arrancar el sistema, o en cualquier momento con sysctl -p.

#21   Y todo en 5 lineas de fáciles y sencillos comandos...

#22   #14 Cuando dije lo que en unix todo es un archivo parafraseaba una de las principales features de Unix, y por ende Linux que es un sistema operativo que imita el núcleo de este, pero vamos que si quieres ir de listillo allá tu.

en.wikipedia.org/wiki/Everything_is_a_file

#23   Desde la version 2.5 se usa /sys

#24   #14 /proc nació en PLAN9 ... Y más "UNIX®" que ese, no creo...

/proc también puede montarse en los BSD, para usar programas de Linux ya que implementa la ABI en el kernel.

#22 Ciertamente GNU= Gnu's not Unix. La verdad es que GNU es UNIX+POSIX+Extensiones propias.

Su "organización" se parece más a Emacs/GNUstep/NeXTStep que la minimalista con comandos y tuberías a lo BSD o Plan9Port, o bien las utiliades de Suckless.org.

#25   #22 Se que parece trolleo peeero aquí se ve la filosofía GNU y similares vs UNIX "pura":

harmful.cat-v.org/software/

Hablo de filosofía, que no licencias, puesto que habrá por ahí aplicaciones GPL con DJVU y demás.

#26   Pero que es esta mierda de enlace ??!! Este es el bueno: www.kernel.org/doc/man-pages/online/pages/man5/proc.5.html

#27   #25 a juzgar por el enlace que pones, parece que la filosofía sea "si un lammer no sabe usarlo, es que es una mierda". XML? Uuuy qué mierda!! Con lo comodísimo que es reinventar la rueda en cada programa que se hace!

#28   #27 Info es más complejo que man. man es una paǵína a leer mientras que info son cientos de vínculos con teclas raras como ctrl-b, ctrl-n ... tipo emacs.

Subversión es intragable, GIT se entiende más rápido.

Y OpenBSD sí, es más facil de instalar que FreeBSD y recomiendan paquetes binarios frente a ports, por lo que la instalación es más sencilla.

Tmux > Screen. El primero permite subdividir la pantalla en vertical, screen no puede hacer eso.

Aún asi, cada cual que use la mejor herramienta de la que disponga. A fin de cuentas, todo funciona mas o menos igual.

GNU=Rendimeinto, funcionalidad y facilidad de uso pero con un diseño barroco.
BSD=Minimalismo, características avanzadas en opciones pero sencillez en el diseño.

#29   #28 OpenBSD no es más facil de instalar que FreeBSD.

En FreeBSD puedes instalar paquetes binarios, también.

#30   #29 Sí pero en OpenBSD recomiendan instalar binarios ya que los parchean ellos mismos por seguridad. E internamente, a la hora de administrar y actualizar, OpenBSD es el BSD más simple de los tres.

#31   #39 ¿A que te refieres con fácil de instalar?

Porque OpenBSD requiere más conocimientos técnicos que FreeBSD, por ejemplo(al menos desde la última vez que los instalé).

#32   #31 No te creas, leéte el manual de instalación de OpenBSD, verás que hay muchos menos pasos de instalación.

Al menos desde la 4.8, y ahora van por la 5.2. Apenas hay diferencias, pero FreeBSD tiene algo más de complejidad, y eso que he probado los 3 BSD más conocidos.

Una de las cosas que me gustan de OpenBSD es que hay menos rotura de ports que en FreeBSD. Meter GNuSTEP y Wmaker es cosa de crios, en FreeBSD algún que otro me ha cascado.

Es que GNUStep avanza bastante y cada aplicación está diseminada por ahí, pero es la única alternativa a programar en Cocoa+Objective C (OSX) que existe...

#33   [edit]

#34   #24 en.wikipedia.org/wiki/Procfs Parece que el primer sitio donde apareció fue en UNIX 8th Edition, pero fue Plan9 donde se implementó de forma real y de aquí el resto de Unix-likes actuales clonaron el proc implimentado en Plan9.

#35   #32 Creo que con FreeBSD tienes que compilar el kernel, a mi me ha dado problemas con las pcmcias en ordenadores antiguos que no venían compilados en el kernel del instalador, en cambio con OpenBSD no he tenido ningún problema. Eso sí, FreeBSD tiene versiones más amigables como PC-BSD donde lo dejan listo para usarlo.

#36   #35 Sí, es más amigable para el usuario final, no lo niego, pero instalar un entorno con Gnome3 fallback en OpenBSD es cosa de editar un archivo, conectarlo a internet e instalar unos pocos paquetes.

Y tales archivos de configuracion, para ser sinceros, ya me gustaría que fuesen en los sistemas de GNU la mitad de simples...

/etc/rc.conf es casi casi para tontos.

#37   #1 técnicamente creo que todo esta en memoria...

#38   #36 me refería al instalador

#39   #38 Por eso te digo, que el instalador de PCSBD solo mete un Freebsd con escritorio y algunos servicios levantados. Bueno en este caso OpenBSD contra FreeBSD tiene ventaja. En FreeBSD tienes que coger mucho desde los ports, con OpenBSD, tienes Gnome completito en binario.

FreeBSD mola, pero eso de tener que meter medio sistema desde los ports y tener que configurar dependencias para obtener funcionalidades no me convence demasiado...

#40   He de probar si se puede enviar /proc a /dev/null

#41   #40 Proc no puede escribirse en algunos casos ni con root.

#42   #28 Tmux > Screen. El primero permite subdividir la pantalla en vertical, screen no puede hacer eso.

Primero deberías aprender a utilizar screen...
C-a S (split) Split the current region into two new ones.
C-a Q (only) Delete all regions but the current one.
C-a X (remove) Kill the current region.
C-a F (fit) Resize the window to the current region size.
C-a tab (focus) Switch the input focus to the next region.


#3 Es lo bueno y es lo malo, lo bueno que puedes aceder directamente a todo.
El problema es que los nuevos sistemas de ficheros para buscar los ficheros de forma mas eficiente almacenan las entradas de los directorios en arboles binarios en lugar de la clásica lista de nombre+inodo. Así que para mantener la compatibilidad guardan ambas.

#43   #42 Screen no tiene división vertical... primero deberías releer lo que puse

#44   #37 imposible, no hay memoria suficiente para guardar todo un sistema de ficheros. Lo que hay es un trasiego de información entre disco y memoria.

#45   #9 No es que prefiera eso (es que me has puesto el peor ejemplo), es que prefiero tener una clase que pueda instanciar mediante una función del kernel y que me lo devuelva todo. Además, es lo mismo recordar las propiedades del objeto devuelto que los archivos dentro de un directorio debajo de /proc.

#13 No es que estén integrados a la perfección, es que UNIX (y el kernel de Linux) están escritos en C con su API en C y con el ABI que se genera con C.

#14 Ya, pero aún así, si quieres una aplicación que lea muy rápido ciertos valores para tenerlos en tiempo real, siempre será más rápido mediante una llamada al kernel y que lo devuelva en una estructura que procesando archivos de texto.

#46   #37 Técnicamente el disco duro o cualquier otro medio de almacenamiento también es considerado un tipo de memoria

#47   #43 División vertical es poco explicito, lo divide en regiones una encima de otra, eso es vertical.
División en columnas es mas explicito.

screen lo hace en filas. Personalmente nunca lo utilizo.

#48   #47 Yo con Tmux bastante, al tener un framebuffer con KMS y nouveau de alta resolución.

#49   Nada como /dev/null
Sirve para hacer los backups, nunca se llena...

#50   #22 #24 No pretendía ir de listillo, perdón si he dado esa impresión. Me extenderé en mis comentarios para no dar lugar a malentendidos:
Me resulta curioso que, aunque procfs se inventó en UNIX a modo de estandar (lucasvr.gobolinux.org/etc/Killian84-Procfs-USENIX.pdf), hoy en día pareciera que sólo se usara en sistemas Unix Like (Linux), lo que lo convierte en no estandar, entendiendo estandar como aquello que todos usan y que permite cierta compatibilidad.

#45 No te hablo con la sabiduría del mundo, pero diría que ya que /proc es un sistema de ficheros virtual y, por ejemplo, cat /proc/0/stat es en realidad una llamada al kernel, tendría que hacer muchas pruebas antes de afirmar con certeza que una llamada al kernel sin pasar por /proc es más rápida. Dejando a un lado la rapidez, lo "molón" de procfs es que simplemente accediendo a una estructura tipo sistema de ficheros tienes información de los procesos uses el lenguaje de programación que uses. Lo que por ejemplo, hace poco me ha permitido programar un task manager en Android sin necesidad de usar C.

#51   #50 'cat /proc/0/stat' no es una llamada al kernel. La llamada al kernel se produce cuando 'cat' ejecuta la llamada al kernel 'read(FILE*...)' y el 'procfs' (sí, con otra llamada al kernel) devuelve los datos en forma de cadena de caracteres.

Entonces, si en lugar de usar 'cat' usas un 'ifstream' de C++ (o un FILE* de C) para meter en un 'char*' los datos devueltos por '/proc/0/stat', tienes que procesarlos en forma de cadena de caracteres, y eso consume mucho más tiempo que si existiera una llamada al sistema directamente que te devolviera una estructura con todos los datos.

Y sí, repito, yo no estoy en contra de que exista un sistema de archivos en memoria que te de todos esos datos, en absoluto, es una idea excelente. Pero lo que sí debería haber es una llamada al kernel que hiciera lo mismo por cuestiones de velocidad.