Ver la versión completa : Solaris 10, /proc lleno el disco
Qué tal?
La hago cortita proque 8:30 tuve que haber entrado a trabajar y son las 9:05 :P
Ayer me reportaron que el filesystem de un solaris 10 estaba lleno.
Efectivamente el raiz estaba lleno.
df -h, decía eso... y du -h, me daba que /proc era el que estaba llenando el disco.
/proc no existe, le hice un reboot al sistema, y :eek: el / seguia lleno.
ya no sabía bien que hacer, use una herramienta de análisis de disco para saber qué estaba ocuapando tanta memoria.. y me encuentro que dentro de /proc/817/root
Tenía otra vez el filesystem... pero no era un enlace.. estaba ahí.. como si fuera una copia.
Probe borrar un archivo ubicado en /proc/817/root/export/home/foo/archivogrande.war
me fijo en el /export/home/foo/archivogrande.war y sigue ahí.
pues bien.. la herramienta de analisis de disco, parecía que había entrado en loop dentro de proc.
Y como tenían que entregar en una hora ( todo se rompe el día de la entrega :P ) me mande la locura de borrar rm -Rf /proc/817/root/
ahí había logrado liberar un poco de espacio en disco.
Cuando reinicio la máquina, no booteaba el sistema y me salia la linea de comandos del grub.
:(
hoy tengo que reinstalar el solaris :$
alguien tiene alguna idea de por qué paso eso? por qué proc que no existe me lleno el disco?
otra pregunta de paso.. la primera vez que instale Solaris, no me dio pare elegir el sistema de particionado.. ¿ es normal ?
Saludos,!
j8k6f4v9j
05-11-2009, 15:46
Los archivos que hay bajo /proc no son reales, sino virtuales.
Lo que me extraña es eso de:
du -h, me daba que /proc era el que estaba llenando el disco.
sobre todo porque si yo lo hago ...
du -hsc /proc
0 /proc/
0 total
En /proc hay sobre todo información del sistema, para que se pueda acceder a ésta a través de archivos (virtuales en este caso). Hay cosas grandes, como por ejemplo kcore, que es una imagen del kernel, pero que yo sepa en ningún caso ocupan espacio en disco. De hecho, si intentas escribir a mano un archivo bajo /proc el sistema te dirá que no existe el archivo o directorio.
Algo andaba mal en ese sistema, ¿qué hacía un desplegable .war en /proc?
No me digas más, el desarrollo en tu empresa lo hacen con Java, pues sí, parece que han sido ellos los que la han cagado en algo. Seguramente se repetirá, así que cuando reinstales ve vigilando el proyecto y los archivos de /proc, para poder prever el desastre.
Salu2
En internet encontre algunas personas con el problema pero ninguna solución.
Ha de ser un mal manejo que hace Weblogic, el servidor de aplicaciones que usan, que estaba instalado como root.
En fin.. ahora ya lo estoy instalando como un usuario común. ( btw: una joya el manejo de usuarios en solaris )
Saludos y Gracias por la respuesta j8!
Volvi, ya reinstale el Solaris, aunque no me sigo avivando como ajustar el tamaño de las particiones en la instalación.
En fin.. volviendo al tema.
Instale el weblogic de nuevo, creamos el dominio. e hice esto:
foo@unknown:/proc $df -hk
Sistema de archivos tamaño usados aprovechar capacidad Montado en
/dev/dsk/c1d0s0 5,3G 3,7G 1,5G 72% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 636M 940K 635M 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
sharefs 0K 0K 0K 0% /etc/dfs/sharetab
/usr/lib/libc/libc_hwcap1.so.1
5,3G 3,7G 1,5G 72% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
swap 635M 44K 635M 1% /tmp
swap 635M 32K 635M 1% /var/run
/dev/dsk/c1d0s7 68G 967M 66G 2% /export/home
/export/home/foo 68G 967M 66G 2% /home/foo
foo@unknown:/proc $du -hs /proc/
3,2G /proc
foo@unknown:/proc $du -hs /
7,8G
foo@unknown:/proc $
Post Deployd del war
foo@unknown:/proc $df -hk
Sistema de archivos tamaño usados aprovechar capacidad Montado en
/dev/dsk/c1d0s0 5,3G 3,8G 1,4G 73% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 556M 940K 556M 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
sharefs 0K 0K 0K 0% /etc/dfs/sharetab
/usr/lib/libc/libc_hwcap1.so.1
5,3G 3,8G 1,4G 73% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
swap 556M 44K 556M 1% /tmp
swap 556M 32K 556M 1% /var/run
/dev/dsk/c1d0s7 68G 1022M 66G 2% /export/home
/export/home/foo 68G 1022M 66G 2% /home/foo
foo@unknown:/proc $du -hs
3,3G .
foo@unknown:/proc $du -hs /
8,0G
foo@unknown:/proc $
Notese que aumento el espacio aumentado en el raiz.
La diferencia con la instalación anterior es que la otra era root el que corria el servidor, ahora lo corre foo.
El tamaño de /proc aumento también
Dicho sea de paso, le pedi que saquen el war de la aplicacion.
foo@unknown:/proc $df -hk
Sistema de archivos tamaño usados aprovechar capacidad Montado en
/dev/dsk/c1d0s0 5,3G 3,8G 1,4G 73% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 803M 940K 802M 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
sharefs 0K 0K 0K 0% /etc/dfs/sharetab
/usr/lib/libc/libc_hwcap1.so.1
5,3G 3,8G 1,4G 73% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
swap 802M 40K 802M 1% /tmp
swap 802M 32K 802M 1% /var/run
/dev/dsk/c1d0s7 68G 994M 66G 2% /export/home
/export/home/foo 68G 994M 66G 2% /home/foo
foo@unknown:/proc $du -hs
939M .
foo@unknown:/proc $du -hs /
5,6G
Los tamaños en / siguen iguales, el proc disminuyo.
Realmente no entiendo.
Sumandole a mi no entendimiento, se hizo otro deployd
foo@unknown:~ $df -h
Sistema de archivos tamaño usados aprovechar capacidad Montado en
/dev/dsk/c1d0s0 5,3G 3,8G 1,4G 74% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 520M 940K 519M 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
sharefs 0K 0K 0K 0% /etc/dfs/sharetab
/usr/lib/libc/libc_hwcap1.so.1
5,3G 3,8G 1,4G 74% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
swap 519M 168K 519M 1% /tmp
swap 519M 36K 519M 1% /var/run
/dev/dsk/c1d0s7 68G 1023M 66G 2% /export/home
/export/home/foo 68G 1023M 66G 2% /home/foo
foo@unknown:/proc $du -hs
3,0G .
foo@unknown:/proc $du -hs /
7,7G
:S :S :S :S
Sin duda es el servidor. pero tampoco sé que es lo que borrar. voy a estar buscando, los mantendre al tanto si encuentro algo.
Saludos,
pues bien.. encontre que en /var/tmp/
varios archivos que estaban llenando el disco.
archivos que estaban ocultos.
por otro lado
foo@unknown:/ $espacio
1K bin
77M boot
3K cdrom
5K Desktop
450K dev
122K devices
1K Documents
58M etc
969M export
969M home
94M kernel
26M lib
0K lost+found
1K mnt
0K net
163K opt
56M platform
3,3G proc
1,7M sbin
5,6M system
100K tmp
2,8G usr
95M var
0K vol
foo@unknown:/ $alias
alias espacio='for i in `ls $(pwd)`; do du -hs $i; done'
/proc figura como que ocupa espacio. no sé como bien solaris resuelve las cosas.. pero tal vez a diferencia de linux le de un espacio fisico a proc..
lo cual sería ilogico.. pero en fin..
Saludos,
j8k6f4v9j
09-11-2009, 19:00
pues bien.. encontre que en /var/tmp/
varios archivos que estaban llenando el disco.
Sí, eso tiene más sentido, sin duda.
/
proc figura como que ocupa espacio. no sé como bien solaris resuelve las cosas.. pero tal vez a diferencia de linux le de un espacio fisico a proc..
lo cual sería ilogico.. pero en fin..
Más que una diferencia en la gestión de /proc, yo diría que se trata de una diferencia en el comportamiento de du. En Solaris, parece ser que du recorre el directorio y devuelve el tamaño de cada uno de los objetos, que viene a ser el tamaño total de los procesos cargados en memoria más el espacio de disco usado en la partición swap; mientras que la versión de du de Debian detecta que no se trata de un archivo físico y devuelve cero, lo que es más lógico.
Salu2
http://img359.imageshack.us/img359/6631/celliigy4.pngKeep on Rollin' :mad:
No he leído casi nada del thread, pero un par de veces que me paso que se me llenaba el raiz era por unos archivos 'core', son snapshots de memoria de cuando ocurre un core dump debido a algún problema.
Suelen ser bastante grandes (dependiendo de la memoria en usada), y salvo que estés desarrollando algo (lo que produjo el problema) y quieras hacer debugging, no le vas a encontrar utilidad. Asi que podés borrarlos tranquilamente.
Saludos
Sí, me hablaron de los archivos dump, pero no encontramos ninguno.
hoy volvi a pedir que hagan un deployd, y solo encuentro un aumento de memoria en proc no en /var/tmp. que supongo que si ha de ser por el aumento de memoria.
En fin.. vermos como se sigue desarrollando.