JavaScript is required to for searching.
Omitir V�nculos de navegaci�n
Salir de la Vista de impresi�n
Administración de Oracle Solaris: tareas comunes     Oracle Solaris 11 Information Library (Español)
search filter icon
search icon

Información del documento

Acerca de este manual

1.  Localización de información acerca de comandos de Oracle Solaris

2.  Gestión de grupos y cuentas de usuario (descripción general)

3.  Gestión de cuentas de usuario y grupos (tareas)

4.  Inicio y cierre de un sistema Oracle Solaris

5.  Trabajo con Oracle Configuration Manager

6.  Gestión de servicios (descripción general)

7.  Gestión de servicios (tareas)

8.  Uso del gestor de fallos

Descripción general de gestión de fallos

Notificación de fallos y defectos

Visualización de Información sobre fallos o defectos

Cómo mostrar información sobre componentes con fallos

Cómo identificar las CPU que están sin conexión

Cómo mostrar información sobre servicios defectuosos

Reparación de fallos o defectos

Comando fmadm replaced

Comando fmadm repaired

Comando fmadm acquit

Archivos de registro de gestión de fallos

Estadísticas de fallos

9.  Gestión de información del sistema (tareas)

10.  Gestión de procesos del sistema (tareas)

11.  Supervisión del rendimiento del sistema (tareas)

12.  Gestión de paquetes de software (tareas)

13.  Gestión del uso de discos (tareas)

14.  Programación de tareas del sistema (tareas)

15.  Configuración y administración de impresoras mediante CUPS (tareas)

16.  Gestión de la consola del sistema, dispositivos del terminal y servicios de energía (tareas)

17.  Gestión de información sobre la caída del sistema (tareas)

18.  Gestión de archivos del núcleo central (tareas)

19.  Resolución de problemas de software y sistemas (tareas)

20.  Resolución de diversos problemas de software y sistemas (tareas)

Índice

Reparación de fallos o defectos

Después de que la gestión de fallos haya determinado un fallo en un componente en el sistema, es posible que desee repararlo. Una reparación se puede realizar de dos maneras: implícita o explícitamente.

Una reparación implícita se puede producir cuando el componente defectuoso se reemplaza o elimina, teniendo en cuenta que el componente tiene información de números de serie que el daemon del gestor de fallos puede rastrear. En muchos sistemas basados en SPARC, la información de números de serie se incluye en los FMRI para que el daemon del gestor de fallos pueda determinar cuándo los componentes se han eliminado de la operación, ya sea mediante el reemplazo u otros medios (por ejemplo, lista negra). Cuando se producen esas detecciones, el daemon del gestor de fallo deja de mostrar el recurso afectado en la salida fmadm faulty. El recurso se mantiene en la antememoria de recursos interna del daemon hasta que el evento de fallo tenga 30 días de antigüedad, punto en que se depura.

Las reparaciones implícitas no se aplican a todos los sistemas. A veces, aunque existe un "Id. de chasis" en los FMRI, no hay información disponible de números de serie de FRU. Por lo tanto el daemon del gestor de fallos no puede detectar un reemplazo de FRU, lo que necesita una reparación explícita.

El comando fmadm se utiliza para marcar explícitamente un fallo como reparado. Cuatro sintaxis están asociadas con reparaciones para este comando:

Aunque estos cuatro comandos pueden tomar FMRI y UUID como argumentos, el argumento que se sugiere utilizar es la etiqueta. Si una FRU tiene varios fallos en contra de ella, deseará reemplazar la FRU sólo una vez. Si emite el comando fmadm replaced en contra de la etiqueta, la FRU se refleja como tal en cualquier caso pendiente.

Comando fmadm replaced

Puede utilizar el comando fmadm replaced para indicar que la FRU sospechosa se ha reemplazado o eliminado.

Si el sistema detecta automáticamente que se ha reemplazado una FRU (el número de serie ha cambiado), esta detección se trata de la misma manera que si se hubiese escrito fmadm replaced en la línea de comandos. El comando fmadm replaced no se permite si fmd puede confirmar automáticamente que la FRU no se ha reemplazado (el número de serie no ha cambiado).

Si el sistema detecta automáticamente que una FRU se ha eliminado pero no se reemplazó, el comportamiento actual no cambia: el sospechoso se muestra como not present, pero no se considera eliminarlo de manera permanente hasta que el evento de fallo tenga 30 días de antigüedad, punto en que se depura.

Comando fmadm repaired

Puede utilizar el comando fmadm repaired cuando se ha llevado a cabo alguna reparación física para resolver el problema, en lugar de reemplazar una FRU. Entre los ejemplos de dichas reparaciones se incluyen: reajustar una tarjeta o estirar un pin inclinado.

Comando fmadm acquit

Con frecuencia utiliza la opción acquit una vez que determina que el recurso no era la causa. La liberación también puede producirse implícitamente cuando se producen eventos de errores adicionales y se refina el diagnóstico.

El reemplazo tiene prioridad sobre la reparación y el reemplazo y la reparación tienen prioridad sobre la liberación. Por lo tanto, puede liberar un componente y, a continuación, repararlo, pero no puede liberar un componente que ya se ha reparado.

Un caso se considera reparado (se desplaza al estado FMD_CASE_REPAIRED y se genera un evento list.repaired) cuando se libera su UUID o todos los sospechosos se han reparado, reemplazado, eliminado o liberado.

Normalmente fmd automáticamente libera un sospechoso de una lista de sospechosos de varios elementos o los servicios de soporte le proporcionan instrucciones para llevar a cabo una liberación manual. Sólo debería liberar por FMRI o etiqueta si ha establecido que el recurso no era culpable en todos los casos actuales en que es un sospechoso. Sin embargo, para permitir que una FRU se libere manualmente en un caso pero siga siendo un sospechoso en todos los demás casos, la siguiente opción le permite especificar UUID y FMRI, o UUID y etiqueta:

fmadm acquit uuid [fmri|label]