¡Trata de arrancarlo, por Dios!
¿Qué haríamos sin Veritas Volume Manager, me pregunto?. La cantidad de frustraciones y malos ratos que nos ha ahorraro… al tiempo que nos ha producido frustraciones y malos ratos nuevo es legandaria. Se puede odiar o se puede adorar a Veritas y conozco ambos tipos de gente, e incluso gente que pasa por ambos estado según el día.
Lo que es innegable es la necesidad de usar un buen gestor de volúmenes, que sea fiable, robusto y sencillo de manejar. En mi opinión, VXVM y VXFS lo son.
Sin embargo, nada es de color de rosa, y en ocasiones, al intentar arrancar una máquina que haya caído por cualquier cuestión (Un panic causado por una CPU en mal estado, por ejemplo), puede haber problemas (vaya novedad) y provocar que los volúmenes queden en estado disabled.
root@madhatter:/root# vxprint -htr [...] v crash - DISABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
Este problema es fácilmente solucionable. Únicamente hace falta deshabilitar uno de los plexes del volumen.
root@madhatter:/root# vxmend off crash-01 [...] v crash - DISABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash DISABLED OFFLINE 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
Tras ello, lo habilitamos de nuevo, dejando el plex en DISABLED CLEAN, y lo limpiamos. Es necesario psaar por estos estados, ya que de otro modo VXVM se quejará y no nos dejará continuar.
root@madhatter:/root# vxmend on crash-01 root@madhatter:/root# vxmend fix clean crash-01 root@madhatter:/root# vxprint -htr
[...] v crash - DISABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash DISABLED CLEAN 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
El último paso es arrancar el volumen completo.
root@madhatter:/root# vxvol start crash root@madhatter:/root# vxprint -htr [...] v crash - ENABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash ENABLED ACTIVE 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash ENABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
Repetir el proceso en todos los volúmenes afectados. Y ya tenemos la máquina limpita.
Y para acabar, les remito al excelente tutorial de Veritas FS y Veritas VM de Ben Rockwood Aunque se trata de versiones antiguas del software es un punto de partida excelente para comprender esta tecnología.
Espejito, espejito…
Odio Solaris Volume Manager. Si fuera por mí, lo quemaba con fuego mientras reía a carcajadas.
Pero claro, viene de serie con el sistema operativo Y entre tener que pagar una licencia de Veritas Volume Manager que cuesta un riñon y poder contar con un gestor de volúmenes por la patilla, adivina que es lo que se va a quedar la gente en una gran mayoría de los casos 
Efectivamente, con uno de los gestores de volúmenes mas antiintuitivos y despreciables que existen. Para matarlos, Oiga.
Menos mal que en Solaris 10 viene incluído por defecto ZFS, que además de ser un tiro y fiable, es absurdamente sencillo de administrar, aunque lo mismo de ello hablamos otro día.
En todo caso, y para todas aquellas veces que tengamos que hacer un mirror de sistema con esta herramienta, una pequeña guía.
Supongamos que nuestra máquina tiene cuatro discos internos:
AVAILABLE DISK SELECTIONS: 0. c0t0d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107> /pci@1f,4000/scsi@3/sd@0,0 1. c0t1d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107> /pci@1f,4000/scsi@3/sd@1,0 2. c0t2d0 <SUN18G cyl 7506 alt 2 hd 19 sec 248> /pci@1f,4000/scsi@3/sd@2,0 3. c0t3d0 <SUN18G cyl 7506 alt 2 hd 19 sec 248> /pci@1f,4000/scsi@3/sd@3,0
Un listado de la tabla de particiones del disco de arranque muestra lo siguiente:
Total disk cylinders available: 24620 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 root wm 0 - 4355 6.00GB (4356/0/0) 12584484 1 swap wu 4356 - 10163 8.00GB (5808/0/0) 16779312 2 backup wm 0 - 24619 33.92GB (24620/0/0) 71127180 3 unassigned wm 0 0 (0/0/0) 0 4 unassigned wm 0 0 (0/0/0) 0 5 var wm 10164 - 14519 6.00GB (4356/0/0) 12584484 6 unassigned wm 14520 - 20327 8.00GB (5808/0/0) 16779312 7 unassigned wm 20328 - 20509 256.74MB (182/0/0) 525798
Lo primero es asegurarnos de que el disco que va a hacer mirror tiene la misma tabla de particiones, para lo cual:
root@madhatter # prtvtoc /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t1d0s2
Continuamos inicializando la base de metadispositivos. Emplearemos el slice 7 ya que cuenta con espacio suficiente.
root@madhatter # metadb -a -f -c3 /dev/dsk/c0t0d0s7 /dev/dsk/c0t1d0s7
Tras ello, podemos comenzar a crear los mirrors, comenzando por /
root@madhatter # metainit -f d10 1 1 c0t0d0s0 d10: Concat/Stripe is setup root@madhatter # metainit d20 1 1 c0t1d0s0 d20: Concat/Stripe is setup root@madhatter # metainit d30 -m d10 d30: Mirror is setup root@madhatter # metaroot d30
Lo mismo para swap:
root@madhatter # metainit -f d11 1 1 c0t0d0s1 d11: Concat/Stripe is setup root@madhatter # metainit d21 1 1 c0t1d0s1 d21: Concat/Stripe is setup root@madhatter # metainit d31 -m d11 d31: Mirror is setup
Para /var
root@madhatter # metainit -f d15 1 1 c0t0d0s5 d15: Concat/Stripe is setup root@madhatter # metainit d25 1 1 c0t1d0s5 d25: Concat/Stripe is setup root@tesol025 # metainit d35 -m d15 d35: Mirror is setup
Y finalmente para /var/crash
root@madhatter # metainit -f d16 1 1 c0t0d0s6 d16: Concat/Stripe is setup root@madhatter # metainit d26 1 1 c0t1d0s6 d26: Concat/Stripe is setup root@madhatter # metainit d36 -m d16 d36: Mirror is setup
Ahora podemos añadir los cambios realizados a /etc/vfstab para que se cojan los cambios en arranque. Recordemos que conviene hacer siempre una copia de seguridad antes de las modificaciones, para evitar futuras lágrimas 
root@madhatter #/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1 yes - fd - /dev/fd fd - no - /proc - /proc proc - no - /dev/md/dsk/d31 - - swap - no - /dev/md/dsk/d30 /dev/md/rdsk/d30 / ufs 1 no - /dev/md/dsk/d35 /dev/md/rdsk/d35 /var ufs 1 no - /dev/md/dsk/d36 /dev/md/rdsk/d36 /var/crash ufs 2 yes - swap - /tmp tmpfs - yes -
Tras ello, realizamos un reboot de la maquina. En el momento en que este de nuevo arriba, entramos como root y comprobamos si el disco esta inicializado para arrancar desde mirror:
root@madhatter # eeprom |grep boot [...] boot-file: data not available. boot-device=disk
Tenemos que añadir el otro disco. Para ello, comprobamos cual es:
root@madhatter # prtconf -vp |grep disk
[...]
disk: '/pci@1f,4000/scsi@3/disk@0,0'
disk0: '/pci@1f,4000/scsi@3/disk@0,0'
disk1: '/pci@1f,4000/scsi@3/disk@1,0'
disk2: '/pci@1f,4000/scsi@3/disk@2,0'
disk3: '/pci@1f,4000/scsi@3/disk@3,0'
[...]
Comprobamos que ambos discos sean iguales:
root@madhatter # format
AVAILABLE DISK SELECTIONS:
[...]
1. c0t1d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
/pci@1f,4000/scsi@3/sd@1,0
[...]
Y cambiamos los valores correspondientes:
root@madhatter # eeprom boot-device="disk disk1"
Comprobamos:
root@madhatter # eeprom |grep boot [...] boot-file: data not available. boot-device=disk disk1
Y procedemos a atachar los metadevices entre si.
# metattach d30 d20 submirror d20 is attached # metattach d31 d21 d31: submirror d21 is attached # metattach d35 d25 d35: submirror d25 is attached # metattach d36 d26
Tras ello, los disco comenzaran a realizar la sincronizacion. Podemos comprobar el estado de la misma con el comando:
root@madhatter # metastat |grep % Resync in progress: 4 % done Resync in progress: 2 % done Resync in progress: 2 % done Resync in progress: 1 % done
Una vez terminada, se habra creado correctamente el mirror.
MPXIO para el nene y la nena. Segunda parte
Una vez comprendidas las generalidades, vamos a proceder a la implementación del asunto, que es lo más interesante.
MPXIO está implementado en Solaris desde la versión 8, pero su configuración ha sido cambiada en Solaris 10, de modo que un caveat antes de ponernos en harina: Imaginemos que el artículo ha sido escrito para las versiones 8 y 9 de Solaris. Haré las matizaciones necesarias para la última versión.
Retomando el ejemplo de la última entrada, vamos a examinar el total de discos que habría en la máquina:
root@madhatter $ format
Searching for disks...done
AVAILABLE DISK SELECTIONS: 0. c0t0d0 /pci@83,4000/FJSV,ulsa@2,1/sd@0,0 1. c0t1d0 /pci@83,4000/FJSV,ulsa@2,1/sd@1,0 2. c2t50060168082006E2d0 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060168082006e2,0 3. c2t50060160082006E2d0 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060160082006e2,0 4. c2t50060168082006E2d1 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060168082006e2,1 5. c2t50060160082006E2d1 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060160082006e2,1 6. c3t50060169082006E2d0 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060169082006e2,0 7. c3t50060161082006E2d0 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060161082006e2,0 8. c3t50060161082006E2d1 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060161082006e2,1 9. c3t50060169082006E2d1 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060169082006e2,1 Specify disk (enter its number): ^D
Antes de nada, será necesario instalar el software de SAN más los parches correspondientes. Diríjanse a Sunsolve a golpe de atambores para recoger el SAN Foundation Kit, así como los drivers y parches para HBA Emulex, que será las que utilicemos en este ejemplo. En caso de Solaris 10, no será necesario, ya que está incluído con el sistema operativo.
Una vez instalado todo, editaremos el fichero /kernel/drv/scsi_vhci.conf
Vamos a buscar la entrada mpxio-disable=”yes”;
Y la cambiaremos para que diga mpxio-disable=”no”;
Nota: En Solaris 10 el fichero a editar es /kernel/drv/fp.conf
Por último, y en caso de que estemos utilizando un dispositivo de almacenamiento externo, habrá que rellenar la parte correspondiente del final del fichero. El ejemplo que pongo a continuación está hecho usando una cabina IBM.
# For enabling MPxIO support for 3rd party symmetric device need an # entry similar to following in this file. Just replace the "SUN SENA" # part with the Vendor ID/Product ID for the device, exactly as reported by # Inquiry cmd. # # This functionality requires patch 113039-02 (or higher). # # device-type-scsi-options-list = # "SUN SENA", "symmetric-option"; # # symmetric-option = 0x1000000; # device-type-scsi-options-list = "IBM 2105800", "symmetric-option"; symmetric-option = 0x1000000;
Eso es todo, ahora será necesario realizar un reboot con reconfiguración. Una vez terminado, podremos ver que los discos en el sistema han cambiado:
AVAILABLE DISK SELECTIONS: 0. c0t0d0 /pci@83,4000/FJSV,ulsa@2,1/sd@0,0 1. c0t1d0 /pci@83,4000/FJSV,ulsa@2,1/sd@1,0 2. c4t6006016061B71000AD0810C9979CD911d0 /scsi_vhci/ssd@g6006016061b71000ad0810c9979cd911 3. c4t6006016061B7100055B12704989CD911d0 /scsi_vhci/ssd@g6006016061b7100055b12704989cd911 Specify disk (enter its number): ^D
De hecho, la correcta composición del dispositivo nuevo se puede ver en el arranque:
Dec 18 11:42:24 madhatter mpxio: [ID 669396 kern.info] /scsi_vhci/ssd@g600c0ff000000000086ab238b2af0600 (ssd11) multipath status: optimal, path /pci@9,600000/SUNW,qlc@1/fp@0,0 (fp1) to target address: 216000c0ff886ab2,0 is online. Load balancing: round-robin
En caso de que haya algún problema con los caminos, sería reportado en el messages:
Aug 24 07:09:01 madhatter mpxio: [ID 669396 kern.info] /scsi_vhci/ssd@g600c0ff000000000086ab238b2af0600 (ssd11) multipath status: degraded, path /pci@9,600000/SUNW,qlc@1/fp@0,0 (fp1) to target address: 216000c0ff886ab2,0 is online. Load balancing: round-robin
Y asimismo, podemos ver lo que hay por debajo, así como los caminos independientes, haciendo un luxadm de los discos. De la misma forma, podemos ver si hay problemas con los caminos de las tarjetas hacia las LUN.
root@madhatter# luxadm display /dev/rdsk/c4t6006016061B71000AD0810C9979CD911d0s2 DEVICE PROPERTIES for disk: /dev/rdsk/c4t6006016061B71000AD0810C9979CD911d0s2 Vendor: SUN Product ID: StorEdge 3510 Revision: 413C Serial Num: 086AB238B2AF Unformatted capacity: 1397535.000 MBytes Write Cache: Enabled Read Cache: Enabled Minimum prefetch: 0x0 Maximum prefetch: 0xffff Device Type: Disk device Path(s):
/dev/rdsk/c4t6006016061B71000AD0810C9979CD911d0s2 /devices/scsi_vhci/ssd@g600c0ff000000000086ab238b2af0600:c,raw Controller /pci@83,2000/pci@2/lpfc@4/fp@0,0 Device Address 216000c0ff886ab2,0 Host controller port WWN 210000e08b14cc40 Class primary State ONLINE Controller /pci@83,2000/pci@2/lpfc@4/fp@0,0 Device Address 266000c0fff86ab2,0 Host controller port WWN 210000e08b144540 Class primary State ONLINE
MPXIO para el nene y la nena. Primera parte
Voy a comenzar una serie de artículos comentando la tecnología MPXIO con un doble objetivo: Hacer algo un poco más extenso que las entradas anteriores que puedan servir a quien lo lea, si es que esto lo llega a leer alguien alguna vez 
y refrescar mis conocimientos sobre el tema, que nunca viene mal.
Así que vamos a comenzar por lo básico…
MPXIO, también llamado Solaris Multiplexed I/O o Sun StorageTek Traffic Manager (Ogh!) permite acceder a un disco a través de varias instancias I/O, pero tratándolas como si fueran una única instancia a nivel de sistema operativo.
¿Suena la pera de complicado?. Les aseguro que no es para tanto, buena señora.
Vamos a suponer que tenemos una máquina llamada Madhatter (Que original!. Gracias, gracias). Esta máquina cuenta con dos discos internos, que se encuentran en mirror para asegurar redundancia y, digamos, cuatro LUN adicionales que nos provee una cabina de discos a los que se accede por un par de HBAs Emulex. El tinglado habitual, pero dejemos una imagen para que no haya líos…
En caso de que no tuviéramos MPXIO implementado, veríamos nada menos que diez discos en el sistema operativo al hacer un format, ya que tenemos los dos discos internos más los cuatro discos externos ofrecidos por los dos caminos.
Ahora bien, al implementar MPXIO estamos “encapsulando” las LUN en un dispositivo virtual por cada una de las HBA que tengamos en la máquina. Y dejaremos de ver los discos anteriores, sustituyéndose estos por un dispositivo nuevo.
Esto tiene dos ventajas muy claras. La primera es que, en caso de que uno de los dispositivos I/O falle (Imaginemos que una de las HBA de la máquina se queda frita), tendremos redundancia ya que el propio software de MPXIO se encarga de hacer el failover hacia un dispositivo de backup.
Y, en segundo lugar, tenemos un incremento en el rendimiento de la lectura en disco externo, ya que estamos repartiendo la carga a través de varios canales. Vamos, que todo el mundo gana
La teoría es siempre un rollo. En el próximo artículo nos ponemos en harina. Ya verán que sencillo 
Este disco ¿De quien es?
Los mensajes de error en almacenamiento, tanto interno como externo, en sistemas Solaris tienen la particularidad de no ser especialmente amistosos con el que los lee por primera vez. Un ejemplo:
Apr 13 06:22:06 madhatter scsi: [ID 107833 kern.warning] WARNING: /pci@7c,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d03,49 (ssd356): Apr 13 06:22:06 madhatter SCSI transport failed: reason 'timeout': retrying command Apr 13 06:22:36 madhatter scsi: [ID 107833 kern.warning] WARNING: /pci@fc,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d13,49 (ssd986): Apr 13 06:22:36 madhatter SCSI transport failed: reason 'timeout': retrying command Apr 13 06:23:06 madhatter scsi: [ID 107833 kern.warning] WARNING: /pci@7c,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d03,49 (ssd356): Apr 13 06:23:06 madhatter SCSI transport failed: reason 'timeout': giving up
El problema es descodificar el chorro que sale en un disco en concreto. Afortunadamente para nosotros, Solaris pone un acceso al nombre de disco concreto dentro del directorio /dev/dsk
De este modo, se trata de una simple cuestión de filtrado.
madhatter:root:/dev/dsk# ls -l *s2 |grep w50060e8003ea6d03,49 lrwxrwxrwx 1 root root 72 Sep 5 2005 c6t50060E8003EA6D03d73s2 -> ../../devices/pci@7c,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d03,49:c
Tachan!. Sabía que ese almacenamiento externo del todo a un euro me iba a causar problemas
¿Y si son muchos los discos que están fallando?. Ah, pues entonces viene a nosotros el poder de la shell:
madhatter:root:/dev/dsk# for i in `grep WARNING /var/adm/messages |nawk ' {print $10}'`;
do ls -arlit *s2 |nawk ' {print $10}'; done
Esto nos sacaría por pantalla únicamente el disco con problemas.
Ahora ya podemos examinar la cabecera del disco para ver si se puede leer correctamente, así como los caminos físicos, por si hubiera problemas en alguna parte de la cadena.
Otro día hablamos de las HBA, esas grandes desconocidas
Escuchando bajo el radar
Iba a escribir hoy una entrada sobre la forma de sacar los discos físicos desde los errores del /var/adm/messages, que es tema fácil y agradecido, pero ya que hemos tenido una pequeña movida con una máquina, aprovecharé para comentar cosas sobre monitorización de procesos en Solaris. Es tema conocido, pero nunca está de mas revisar temas de base.
ps: El que todo el mundo conoce, lista los procesos que se encuentran ejecutándose en ese momento en la máquina. Tiene buena cantidad de operandos, pero los más habituales son -ef (Listar todos los procesos actuales y sacar lista completa de los mismos). Es el punto de partida desde el que comenzaremos a explorar el sistema con los demás comandos.
ptree: Nos permite ver el árbol de procesos completo y qué cuelga por debajo del principal. Un ejemplo curioso en el que vemos como sshd tiene por debajo una sesión desde la que se lanza el propio comando ptree.
bash-3.00# ptree 876
876 /usr/lib/ssh/sshd
21670 /usr/lib/ssh/sshd
21673 /usr/lib/ssh/sshd
21675 -sh
21679 bash
21729 ptree 876
prstat: Vista a pantalla completa de procesos, que se puede separar por distintos operandos (-J para agrupar por proyectos, -L para lightweight process, etc… Es similar al top de Linux. Para más operandos, examinar el man.
bash-3.00# prstat -J
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3416 root 131M 69M sleep 59 0 23:33:21 1.7% java/20
3831 root 115M 52M sleep 59 0 12:26:17 0.8% java/23
21670 root 11M 5648K sleep 59 0 0:00:00 0.4% sshd/1
3936 root 102M 31M sleep 49 0 6:15:39 0.2% java/14
21680 root 3376K 2928K cpu1 39 0 0:00:00 0.1% prstat/1
2184 noaccess 166M 86M sleep 59 0 3:24:06 0.1% java/23
3896 root 71M 13M sleep 59 0 4:16:51 0.1% gnome-netstatus/1
21673 root 11M 2488K sleep 59 0 0:00:00 0.1% sshd/1
648 root 94M 19M sleep 59 0 3:46:56 0.1% poold/8
21679 root 3096K 2280K sleep 59 0 0:00:00 0.1% bash/1
157 daemon 4592K 2432K sleep 59 0 0:00:01 0.1% kcfd/3
21675 root 1360K 1128K sleep 59 0 0:00:00 0.0% sh/1
3915 root 70M 12M sleep 59 0 0:51:34 0.0% mixer_applet2/1
3693 root 77M 19M sleep 59 0 0:57:05 0.0% gnome-panel/1
1411 root 20M 14M sleep 59 0 1:00:41 0.0% Xsun/1
775 daemon 183M 182M sleep 59 0 0:13:21 0.0% nfsmapid/4
150 root 5112K 3840K sleep 59 0 0:07:56 0.0% nscd/31
3805 root 9808K 5216K sleep 59 0 0:07:27 0.0% gnome-vfs-daemo/2
PROJID NPROC SWAP RSS MEMORY TIME CPU PROJECT
1 37 187M 320M 31% 37:23:39 2.8% user.root
0 47 392M 480M 47% 20:27:06 1.1% system
Total: 84 processes, 313 lwps, load averages: 0.13, 0.12, 0.12
pfiles: Muestra los descriptores del proceso, asociados al mismo. Con el proceso anterior, podremos ver inodos, uis, gid y hasta el puerto en el que está escuchando.
bash-3.00# pfiles 876
876: /usr/lib/ssh/sshd
Current rlimit: 256 file descriptors
0: S_IFCHR mode:0666 dev:308,0 ino:6815752 uid:0 gid:3 rdev:13,2
O_RDWR|O_LARGEFILE
/devices/pseudo/mm@0:null
1: S_IFCHR mode:0666 dev:308,0 ino:6815752 uid:0 gid:3 rdev:13,2
O_RDWR|O_LARGEFILE
/devices/pseudo/mm@0:null
2: S_IFCHR mode:0666 dev:308,0 ino:6815752 uid:0 gid:3 rdev:13,2
O_RDWR|O_LARGEFILE
/devices/pseudo/mm@0:null
3: S_IFSOCK mode:0666 dev:314,0 ino:14371 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK
SOCK_STREAM
SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET6 :: port: 22
7: S_IFREG mode:0666 dev:309,1 ino:65539 uid:0 gid:0 size:0
O_RDWR|O_LARGEFILE
/system/contract/process/template
pstack: Muestra la pila de memoria del proceso. Es útil para saber qué está pasando a alto nivel, pero prefiero truss para estos casos.
bash-3.00# pstack 876
876: /usr/lib/ssh/sshd
ff0457c8 pollsys (ffbff3a8, 1, 0, 0)
fefe6d00 pselect (ffbff3a8, ff072528, ff072528, 40, 0, 0) + 1c8
fefe7078 select (6, 7f4d0, 0, 0, 0, 28) + a0
0001d084 main (8, ffffffff, a, 0, 0, a) + e58
0001acc0 _start (0, 0, 0, 0, 0, 0) + 108
pmap: Muestra el mapa de los procesos, junto con las librerías de las que está tirando en un momento concreto y la memoria que consume. Resulta sorprendente todo lo que se carga para un proceso concreto.
bash-3.00# pmap 876
876: /usr/lib/ssh/sshd
00010000 328K r-x– /usr/lib/ssh/sshd
00072000 16K rwx– /usr/lib/ssh/sshd
00076000 64K rwx– [ heap ]
FEEF0000 40K r-x– /usr/sfw/lib/libcrypto_extra.so.0.9.7
FEF0A000 8K rwx– /usr/sfw/lib/libcrypto_extra.so.0.9.7
FEF10000 24K r-x– /lib/libnvpair.so.1
FEF26000 8K rwx– /lib/libnvpair.so.1
FEF30000 16K r-x– /lib/libsecdb.so.1
FEF44000 8K rwx– /lib/libsecdb.so.1
FEF50000 80K r-x– /lib/libmd.so.1
FEF74000 8K rwx– /lib/libmd.so.1
FEF80000 888K r-x– /lib/libc.so.1
FF06E000 32K rwx– /lib/libc.so.1
FF076000 8K rwx– /lib/libc.so.1
FF080000 1088K r-x– /usr/sfw/lib/libcrypto.so.0.9.7
FF190000 112K rwx– /usr/sfw/lib/libcrypto.so.0.9.7
FF1AC000 8K rwx– /usr/sfw/lib/libcrypto.so.0.9.7
FF1B0000 16K r-x– /lib/libcontract.so.1
FF1C4000 8K rwx– /lib/libcontract.so.1
FF1D0000 16K r-x– /lib/libcmd.so.1
FF1E4000 8K rwx– /lib/libcmd.so.1
FF1F0000 48K r-x– /usr/lib/libgss.so.1
FF20C000 8K rwx– /usr/lib/libgss.so.1
FF210000 32K r-x– /usr/sfw/lib/libwrap.so.1.0
FF228000 8K rwx– /usr/sfw/lib/libwrap.so.1.0
FF230000 128K r-x– /lib/libbsm.so.1
FF250000 24K rwx– /lib/libbsm.so.1
FF260000 32K r-x– /lib/libpam.so.1
FF270000 24K rwx– [ anon ]
FF278000 8K rwx– /lib/libpam.so.1
FF280000 584K r-x– /lib/libnsl.so.1
FF31E000 8K rwxs- [ anon ]
FF322000 40K rwx– /lib/libnsl.so.1
FF32C000 24K rwx– /lib/libnsl.so.1
FF340000 8K rwx– [ anon ]
FF350000 72K r-x– /usr/lib/libz.so.1
FF370000 8K rwx– /usr/lib/libz.so.1
FF380000 48K r-x– /lib/libsocket.so.1
FF390000 8K rwx– [ anon ]
FF39C000 8K rwx– /lib/libsocket.so.1
FF3A0000 16K r-x– /platform/sun4u/lib/libc_psr.so.1
FF3B0000 208K r-x– /lib/ld.so.1
FF3F0000 8K rwx– [ anon ]
FF3F4000 8K rwx– /lib/ld.so.1
FF3F6000 8K rwx– /lib/ld.so.1
FFBFC000 16K rw— [ stack ]
total 4168K
lsof: Muestra los ficheros y procesos abiertos. Resulta muy útil cuando queremos saber quien está accediendo a un directorio concreto o a un fichero específico.
bash-3.00# lsof /usr/lib/ssh/sshd
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 876 root txt VREG 276,0 350624 256405 /usr/lib/ssh/sshd
sshd 21670 root txt VREG 276,0 350624 256405 /usr/lib/ssh/sshd
sshd 21673 root txt VREG 276,0 350624 256405 /usr/lib/ssh/sshd
Otro día seguimos.
Amo a bash
Un par de trucos y atajos de teclado para los que utilizáis bash y que lo mismo no conocíais:
- Autocompletado de palabras usando la tecla TAB, pero esto lo conoce todo el mundo
- Ctrl-A nos manda al inicio de la línea. Ctrl-E al final de la línea
- Ctrl-L limpia la pantalla y nos evita tener que escribir “clear”
- Ctrl-R realiza búsquedas en los comandos anteriormente ejecutados.
Con las cintas de mi capaaaa…
Para la primera entrada, un tema ligero.
Supongamos queuna máquina de las gordas ha tenido un problema y nos encontramos con un core de varios gigas que es necesario analizar, pero la red está muy sobrecargada, o no tenemos espacio para almacenarlo en un punto intermedio, o nos corre prisa el envío.
La solución sería pasar los archivos a cinta y hacerlo llegar a quien se encargue del análisis.
Por defecto, los dispositivos de cinta en Solaris se encuentran en /dev/rmt/X y, usualmente, el primero es /dev/rmt/0.
Primero, rebobinamos la cinta:
# mt -f /dev/rmt/0 rewind
Despues comprobamos el estado:
# mt -f /dev/rmt/0 status
HP DAT-72 tape drive:
sense key(0×0)= No Additional Sense residual= 0 retries= 0
file no= 0 block no= 0
Tras ello, se copian los archivos a la cinta mediante tar
# tar -cvf /dev/rmt0 /var/tmp/core
a /var/tmp/core/ 0 tape blocks
a /var/tmp/core/core_maquina.tar.gz 1720321 tape blocks
Comprobamos que se haya copiado bien
# tar -tvf /dev/rmt/0
drwxr-xr-x 0/1 0 Sep 6 15:32 2007 /var/tmp/core/
-rw-r–r– 0/1 880804144 Sep 6 15:34 2007 /var/tmp/core/core_maquina.tar.gz
Una vez finalizado, comprobamos de nuevo el estado de la cinta y la expulsamos con:
# mt -f /dev/rmt/0 rewoffl
Y ya podemos mandar a un lacayo a recogerla. O ir nosotros mismos a por ella.
There is an obscure RPC error…
Vamos a ser originales con la primera entrada
En todo caso, esto es un comienzo. Poco a poco le intentaremos sacar partido a la página.
