En este apéndice se proporcionan algunas de las mejores prácticas recomendadas y se muestra cómo solucionar algunos problemas de servicio de SMF.
La mayoría de los servicios describen la política de configuración. Si la configuración que desea no está implementada, modifique la descripción de la política modificando el servicio. Modifique los valores de las propiedades de servicio o cree nuevas instancias de servicio con distintos valores de propiedad. No desactive las instancias de servicio y edite los archivos de configuración que serán gestionados por un servicio SMF.
No modifique los manifiestos y perfiles de sistema entregados por Oracle o proveedores de software de terceros. Estos manifiestos y perfiles se pueden reemplazar al actualizar el sistema y, entonces, sus cambios en estos archivos se perderán. En su lugar, cree un perfil de sitio para personalizar el servicio o utilice el comando svccfg o inetadm para manipular las propiedades directamente. Los directorios /lib/svc/manifest/site y /var/svc/manifest/site también se reservan para uso específico del sitio. Oracle Solaris no entrega manifiestos a estos directorios.
Para aplicar la misma configuración personalizada en varios sistemas, utilice el comando svcbundle o el comando svccfg extract para crear un archivo de perfil. Personalice valores de propiedad en ese archivo e incluya comentarios sobre el motivo de cada personalización. Copie el archivo a /etc/svc/profile/site en cada sistema y reinicie el servicio manifest-import en cada sistema. Consulte Configuración de varios sistemas.
Al crear un perfil de sitio, asegúrese de que la configuración definida no entre en conflicto con la configuración definida en otro perfil de sitio para el mismo servicio o instancia de servicio. Cuando SMF encuentra la configuración en conflicto en la misma capa del repositorio de configuración de servicio, la instancia de servicio afectada se coloca en el estado de mantenimiento.
No utilice ubicaciones no estándar para archivos de perfil y manifiesto. Consulte Paquetes de servicio para ubicaciones estándar de perfiles y manifiestos.
Al crear un servicio para su propio uso, utilice site al principio del nombre de servicio: svc:/site/service_name:instance_name.
No modifique la configuración del servicio de reiniciador maestro, svc:/system/svc/restarter:default, excepto para configurar niveles de registro como se describe en Especificación de la cantidad de mensajes de inicio.
Antes de utilizar el comando svccfg delcust, utilice el comando svccfg listcust con las mismas opciones. El subcomando delcust puede eliminar todas las personalizaciones administrativas en un servicio. Utilice el subcomando listcust para verificar que las personalizaciones se suprimirán mediante el subcomando delcust.
En secuencias de comandos, utilice FMRI de instancia de servicio completo: svc:/service_name:instance_name.
En esta sección se analizan los aspectos siguientes:
Confirmación de cambios de configuración en la instantánea en ejecución
Corrección de servicios notificados con problemas
Transición manual de una instancia al estado degraded o maintenance
Corrección de un repositorio de configuración de servicios dañado
Configuración de la cantidad de mensajes para mostrar o almacenar en el inicio del sistema
Transición o inicio a un hito especificado
Uso de SMF para investigar problemas de inicio
Conversión de servicios inetd a servicios SMF
En el repositorio de configuración de servicio, SMF almacena los cambios de propiedad por separado de las propiedades en la instantánea en ejecución. Al cambiar la configuración del servicio, los cambios no aparecen inmediatamente en la instantánea en ejecución.
La operación de refrescamiento actualiza la instantánea en ejecución de la instancia de servicio especificada con los valores de la configuración de edición.
De manera predeterminada, el comando svcprop muestra propiedades en la instantánea en ejecución, y el comando svccfg muestra propiedades en la configuración de edición. Si ha cambiado los valores de propiedad pero no realizó un refrescamiento de la configuración, los comandos svcprop y svccfg muestran diferentes valores de propiedad. Después de realizar un refrescamiento de la configuración, los comandos svcprop y svccfg muestran los mismos valores de propiedad.
Reiniciar no cambia la instantánea en ejecución. El comando svcadm restart no refresca la configuración. Use el comando svcadm refresho svccfg refresh para confirmar los cambios de configuración en la instantánea en ejecución.
Utilice el comando svcs -x sin argumentos para mostrar información explicativa sobre las instancias de servicio que cumplen cualquiera de las siguientes descripciones:
El servicio está activado, pero no está en ejecución.
El servicio impide que otro servicio activado se ejecute.
En la lista siguiente se resume cómo abordar problemas de servicio:
Diagnostique el problema, empezando por ver el archivo log de servicio.
Solucione el problema. Si solucionar el problema implica modificar la configuración de servicio, refresque el servicio.
Mueva los servicios afectados a un estado en ejecución.
Una instancia de servicio que está en mantenimiento está activada, pero no podrá ejecutarse.
La instancia puede estar transitando por el estado maintenance debido a que una acción administrativa aún no se ha completado. Si la instancia está en transición, su estado debería mostrarse como maintenance*.
En el ejemplo siguiente, las líneas “State”(Estado) y “Reason” (Motivo) muestran que el servicio pkg/depot está en el estado maintenance porque falló el método de inicio.
$ svcs -x svc:/application/pkg/depot:default (IPS Depot) State: maintenance since September 11, 2013 01:30:42 PM PDT Reason: Start method exited with $SMF_EXIT_ERR_FATAL. See: http://support.oracle.com/msg/SMF-8000-KS See: pkg.depot-config(1M) See: /var/svc/log/application-pkg-depot:default.log Impact: This service is not running.
Inicie sesión en el sitio de soporte de Oracle para ver el artículo de conocimientos de reparación automática predictiva al que se hace referencia. En este caso, el artículo le indica ver el archivo log para determinar el motivo del fallo del método de inicio. La salida svcs proporciona el nombre del archivo log. Consulte Visualización de archivos log de servicio para obtener más información sobre cómo ver el archivo log. En este ejemplo, el archivo log muestra la invocación de método de inicio y el mensaje de error fatal.
[ Sep 11 13:30:42 Executing start method ("/lib/svc/method/svc-pkg-depot start"). ]
pkg.depot-config: Unable to get publisher information:
The path '/export/ipsrepos/Solaris11' does not contain a valid package repository.
Uno o más de los pasos siguientes pueden ser necesarios.
Si para solucionar el problema informado necesita modificar la configuración de servicio, use el comando svccfg refresh o svcadm refresh para cualquier servicio cuya configuración haya cambiado. Verifique que la configuración se actualice en la instantánea en ejecución mediante el comando svcprop para comprobar los valores de propiedad o mediante otras pruebas específicas para este servicio.
A veces la línea “Impact” (Impacto) en la salida svcs -x le indica que servicios que dependen del servicio que está en estado maintenance no están en ejecución. Utilice el comando svcs -l para comprobar el estado actual de servicios dependientes. Asegúrese de que todas las dependencias requeridas estén en ejecución. Utilice el comando svcs -x para verificar que todos los servicios activados estén en ejecución.
Si el servicio que está en estado maintenance es un servicio de contrato, determine si los procesos iniciados por el servicio no se han detenido. Cuando una instancia de servicio de contrato está en un estado de mantenimiento, el ID de contrato debe estar en blanco, como se muestra en el ejemplo siguiente, y todos los procesos asociados con esa instancia de servicio deben estar detenidos. Utilice svcs -l o svcs -o ctid para comprobar que no existe contrato para una instancia de servicio en mantenimiento. Utilice svcs -p para comprobar si algún proceso asociado con esta instancia de servicio aún está en ejecución. Cualquier proceso mostrado por svcs -p para una instancia de servicio en mantenimiento debe finalizarse.
$ svcs -l system-repository fmri svc:/application/pkg/system-repository:default name IPS System Repository enabled true state maintenance next_state none state_time September 17, 2013 07:18:19 AM PDT logfile /var/svc/log/application-pkg-system-repository:default.log restarter svc:/system/svc/restarter:default contract_id manifest /lib/svc/manifest/application/pkg/pkg-system-repository.xml dependency require_all/error svc:/milestone/network:default (online) dependency require_all/none svc:/system/filesystem/local:default (online) dependency optional_all/error svc:/system/filesystem/autofs:default (online)
Cuando el problema indicado está solucionado, utilice el comando svcadm clear para devolver el servicio al estado online. Para servicios en el estado maintenance, el subcomando clear le indica al reiniciador para ese servicio que el servicio fue reparado.
$ svcadm clear pkg/depot:default
Si especifica la opción -s, el comando svcadm espera volver hasta que la instancia alcance el estado online o hasta que determine que la instancia no puede alcanzar el estado online sin la intervención de un administrador. Utilice la opción -T con la opción -s para especificar un límite superior en segundos para realizar la transición o determinar que no se puede realizar la transición.
Utilice el comando svcs para verificar que el servicio que estaba en mantenimiento esté ahora en línea. Utilice el comando svcs -x para verificar que todos los servicios activados estén en ejecución.
Una instancia de servicio que está fuera de línea está activada, pero no está en ejecución o disponible para ejecutarse.
La instancia puede estar transitando por el estado offline porque sus dependencias aún no se han cumplido. Si la instancia está en transición, su estado debería mostrarse como offline*.
Si las dependencias requeridas están desactivadas, actívelas con el siguiente comando:
$ svcadm enable -r FMRI
Un archivo de dependencia puede estar faltando o no se puede leer. Es posible que desee utilizar pkg fix o pkg revert para solucionar este tipo de problema. Consulte la página del comando man pkg(1).
Si la instancia está fuera de línea porque no se ha cumplido una dependencia necesaria, es posible que al solucionar o activar la dependencia se reinicie la instancia fuera de línea y vuelva a estar en línea sin necesidad de ninguna otra acción administrativa.
Si ha realizado alguna otra corrección para el servicio, entonces reinicie la instancia.
$ svcadm restart FMRI
Utilice el comando svcs para verificar que la instancia que estaba fuera de línea esté ahora en línea. Utilice el comando svcs -x para verificar que todos los servicios activados estén en ejecución.
Una instancia de servicio degradada está activada y en ejecución o disponible para su ejecución, pero está funcionando a una capacidad limitada.
Cuando el problema indicado está solucionado, utilice el comando svcadm clear para devolver la instancia al estado online. Para las instancias en estado degraded, el subcomando clear solicita al reiniciador que pase esa instancia al estado online.
$ svcadm clear pkg/depot:default
Utilice el comando svcs para verificar que la instancia que estaba degradada esté ahora en línea. Utilice el comando svcs -x para verificar que todos los servicios activados estén en ejecución.
Puede marcar una instancia de servicio que esté en estado degraded o maintenance. Es posible que desee hacer esto si la aplicación está parada en un bucle o en punto muerto, por ejemplo. La información sobre el cambio de estado se propaga a las dependencias de la instancia marcada, lo que puede ayudar a depurar otras instancias relacionadas.
Especifique la opción -I para solicitar un cambio de estado de inmediato.
Cuando se marca una instancia como maintenance, puede especificar la opción -t para solicitar un cambio de estado temporal. Las solicitudes temporales sólo se mantienen hasta el reinicio.
Si especifica la opción -s con el comando svcadm mark, svcadm marca la instancia y espera que la instancia ingrese al estado degraded o maintenance antes de volver. Utilice la opción -T con la opción -s para especificar un límite superior en segundos para realizar la transición o determinar que no se puede realizar la transición.
En el inicio del sistema, el daemon de repositorio, svc.configd, realiza una comprobación de integridad del repositorio de configuración almacenado en /etc/svc/repository.db. Si la comprobación de integridad svc.configd falla, el daemon svc.configd escribe un mensaje en la consola, similar al siguiente:
svc.configd: smf(5) database integrity check of:
/etc/svc/repository.db
failed. The database might be damaged or a media error might have
prevented it from being verified. Additional information useful to
your service provider is in:
/system/volatile/db_errors
The system will not be able to boot until you have restored a working
database. svc.startd(1M) will provide a sulogin(1M) prompt for recovery
purposes. The command:
/lib/svc/bin/restore_repository
can be run to restore a backup version of your repository. See
http://support.oracle.com/msg/SMF-8000-MY for more information.
El daemon svc.configd sale. Esa salida es detectada por el daemon svc.startd, y svc.startd inicia sulogin.
En el indicador sulogin, introduzca Ctrl-D para salir de sulogin. El daemon svc.startd reconoce la salida de sulogin y reinicia el daemon svc.configd, el cual comprueba el repositorio nuevamente. Es posible que el problema no vuelva a aparecer después de este reinicio adicional. No invoque directamente el daemon svc.configd. El daemon svc.startd inicia el daemon svc.configd.
Si svc.configd vuelve a informar una comprobación de integridad con fallos y está nuevamente en el indicador sulogin, asegúrese de que los sistemas de archivos no estén llenos. Utilizando la contraseña root, inicie sesión remotamente o en el indicador sulogin. Compruebe que haya espacio disponible en los sistemas de archivos system/volatile y root. Si alguno de estos sistemas de archivos está lleno, haga espacio y vuelva a iniciar el sistema. Si ninguno de estos sistemas de archivos está lleno, siga el procedimiento Cómo restaurar un repositorio desde una copia de seguridad.
El repositorio de configuración de servicio puede dañarse por cualquiera de los siguientes motivos:
Fallo de disco
Error de hardware
Error de software
Sobrescritura accidental del archivo
El siguiente procedimiento muestra cómo reemplazar un repositorio dañado con una copia de seguridad del repositorio.
Utilizando la contraseña root, inicie sesión remotamente o en el indicador sulogin.
# /lib/svc/bin/restore_repository
La ejecución de este comando lo guía por los pasos necesarios para restaurar una copia de seguridad que no está dañada. SMF realiza automáticamente copias de seguridad del repositorio como se describe en Copias de seguridad del repositorio.
SMF mantiene los datos de configuración persistentes y no persistentes. Consulte Repositorio de configuración de servicios para obtener descripciones de estos dos repositorios. El comando restore_repository sólo restaura el repositorio persistente. El comando restore_repository también reinicia el sistema, que destruye los datos de configuración no persistentes. Los datos no persistentes son datos de tiempo de ejecución que no son necesarios en el reinicio del sistema.
Al iniciar, el comando /lib/svc/bin/restore_repository muestra un mensaje similar al siguiente:
See http://support.oracle.com/msg/SMF-8000-MY for more information on the use of this script to restore backup copies of the smf(5) repository. If there are any problems which need human intervention, this script will give instructions and then exit back to your shell.
Después de que el sistema de archivos root (/) se monta con permisos de escritura, o si el sistema es una zona local, se le pide que seleccione la copia de seguridad del repositorio para restaurar:
The following backups of /etc/svc/repository.db exists, from oldest to newest: ... list of backups ...
Las copias de seguridad se nombran según el tipo y la hora en que la copia de seguridad se ha realizado. Las copias de seguridad que empiezan con boot se completan antes de que se realiza el primer cambio en el repositorio después del inicio del sistema. Las copias de seguridad que empiezan con manifest_import se completan después de que svc:/system/manifest-import:default termina su proceso. La hora de la copia de seguridad se proporciona en formato YYYYMMDD_HHMMSS.
Normalmente, se selecciona la opción de copia de seguridad más reciente.
Please enter either a specific backup repository from the above list to
restore it, or one of the following choices:
CHOICE ACTION
---------------- ----------------------------------------------
boot restore the most recent post-boot backup
manifest_import restore the most recent manifest_import backup
-seed- restore the initial starting repository (All
customizations will be lost, including those
made by the install/upgrade process.)
-quit- cancel script and quit
Enter response [boot]:
Si presiona Intro sin especificar una copia de seguridad para restaurar, se selecciona la respuesta predeterminada, encerrada entre []. Al seleccionar -quit-, se sale de la secuencia de comandos restore_repository y se regresa al indicador de shell.
Después de que la copia de seguridad para restaurar se ha seleccionado, se valida y se comprueba su integridad. Si hay problemas, el comando restore_repository imprime mensajes de error y le solicita otra selección. Una vez que se selecciona una copia de seguridad válida, se imprime la siguiente información y se le solicita confirmación final.
After confirmation, the following steps will be taken:
svc.startd(1M) and svc.configd(1M) will be quiesced, if running.
/etc/svc/repository.db
-- renamed --> /etc/svc/repository.db_old_YYYYMMDD_HHMMSS
/system/volatile/db_errors
-- copied --> /etc/svc/repository.db_old_YYYYMMDD_HHMMSS_errors
repository_to_restore
-- copied --> /etc/svc/repository.db
and the system will be rebooted with reboot(1M).
Proceed [yes/no]?
El sistema se reinicia después de que el comando restore_repository ejecuta todas las acciones enumeradas.
De manera predeterminada, cada servicio que se inicia durante el inicio del sistema no muestra un mensaje en la consola. Utilice uno de los siguientes métodos para cambiar los mensajes que aparecen en la consola y los que se registran sólo en el archivo log svc.startd. El valor de logging-level puede ser uno de los valores se muestran en la siguiente tabla.
Al iniciar un sistema SPARC, especifique la opción -m para el comando boot en el indicador ok. Consulte “Messages options” (Opciones de mensajes) en la página del comando man kernel(1M).
ok boot -m logging-level
Al iniciar un sistema x86, edite el menú GRUB para especificar la opción -m. Consulte Agregación de argumentos del núcleo mediante la edición del menú de GRUB en el inicio de Inicio y cierre de sistemas Oracle Solaris 11.2 y “Messages options” (Opciones de mensajes) en la página del comando man kernel(1M).
Antes de reiniciar un sistema, utilice el comando svccfg para cambiar el valor de la propiedad options/logging. Si esta propiedad nunca se ha cambiado en este sistema, no saldrá y tendrá que agregarla. El siguiente ejemplo cambia a mensajes detallados. El cambio se hace efectivo en el siguiente reinicio del daemon svc.startd.
$ svccfg -s system/svc/restarter:default listprop options/logging $ svccfg -s system/svc/restarter:default addpg options application $ svccfg -s system/svc/restarter:default setprop options/logging=verbose $ svccfg -s system/svc/restarter:default listprop options/logging options/logging astring verbose
|
Cuando se inicia un sistema, puede especificar el hito SMF con el que se va a iniciar.
De manera predeterminada, todos los servicios para los que el valor de la propiedad general/enabled es true se inician en el inicio del sistema. Para cambiar el hito con el que se inicia un sistema, utilice uno de los métodos siguientes. El valor de milestone puede ser FMRI de un servicio de hitos o una palabra clave como se muestra en Table A–2.
Al iniciar un sistema SPARC, especifique la opción -m para el comando boot en el indicador ok. Consulte la opción -m en la página del comando man kernel(1M).
ok boot -m milestone=milestone
Al iniciar un sistema x86, edite el menú GRUB para especificar la opción -m. Consulte Agregación de argumentos del núcleo mediante la edición del menú de GRUB en el inicio de Inicio y cierre de sistemas Oracle Solaris 11.2 y la opción -m en la página del comando man kernel(1M).
Antes de reiniciar un sistema, utilice el comando con svcadm milestone con la opción -d. Tenga en cuenta que con o sin la opción -d, este comando restringe y restaura servicios en ejecución inmediatamente. Con la opción -d, el comando también hace que el hito especificado sea el hito de inicio predeterminado. Este nuevo valor predeterminado persiste tras los reinicios.
$ svcadm milestone -d milestone
Este comando no cambia el nivel de ejecución actual del sistema. Para cambiar el nivel de ejecución actual del sistema, utilice el comando init.
Si especifica la opción -s, svcadm cambia el hito y luego espera que la transición al hito especificado se complete antes de volver. El comando svcadm vuelve cuando todas las instancias han pasado al estado necesario para alcanzar el hito especificado o cuando determine que se requiere la intervención del administrador para realizar una transición. Utilice la opción -T con la opción -s para especificar un límite superior en segundos para completar la operación de cambio de hito o devolución.
La siguiente tabla describe hitos de inicio SMF, incluyendo cualquier nivel de ejecución Oracle Solaris correspondiente. Un nivel de ejecución del sistema define los servicios y recursos disponibles para los usuarios. Un sistema sólo puede estar en un nivel de ejecución a la vez. Para obtener información sobre niveles de ejecución, consulte Cómo funcionan los niveles de ejecución de Inicio y cierre de sistemas Oracle Solaris 11.2 , la página del comando man inittab(4) y el archivo /etc/init.d/README. Para obtener más información sobre hitos de inicio SMF, consulte el subcomando milestone en la página del comando man svcadm(1M).
|
Para determinar el hito con el que un sistema se inicia actualmente, use el comando svcs. El siguiente ejemplo muestra que el sistema se inicia para nivel de ejecución 3, milestone/multi-user-server:
$ svcs 'milestone/*' STATE STIME FMRI online 9:08:05 svc:/milestone/unconfig:default online 9:08:06 svc:/milestone/config:default online 9:08:07 svc:/milestone/devices:default online 9:08:25 svc:/milestone/network:default online 9:08:31 svc:/milestone/single-user:default online 9:08:51 svc:/milestone/name-services:default online 9:09:13 svc:/milestone/self-assembly-complete:default online 9:09:23 svc:/milestone/multi-user:default online 9:09:24 svc:/milestone/multi-user-server:default
En esta sección se describen las acciones que se deben realizar si el sistema se bloquea durante el inicio o si un servicio clave no se puede iniciar durante el inicio.
Si se producen problemas al iniciar los servicios en el inicio del sistema, en ocasiones, el sistema se bloquea durante el inicio. Este procedimiento muestra cómo investigar los problemas de servicio que se producen en el momento del inicio.
El siguiente comando indica al daemon svc.startd que desactive temporalmente todos los servicios e inicie sulogin en la consola.
ok boot -m milestone=none
Consulte Especificación de hito SMF con el cual reiniciar para obtener una lista de hitos SMF que puede usar con el comando boot -m.
# svcadm milestone all
Cuando el proceso de inicio se bloquea, determine qué servicios no se están ejecutando mediante la ejecución de svcs -a. Busque mensajes de error en los archivos log, en /var/svc/log.
# svcs -x
Este comando verifica que el proceso login en la consola se ejecutará.
# svcs -l system/console-login:default
Los sistemas de archivos locales que no son necesarios para iniciar el sistema son montados por el servicio svc:/system/filesystem/local:default. Cuando algunos de esos sistemas de archivos no se pueden montar, el servicio filesystem/local entra en estado de mantenimiento. El inicio del sistema continúa, y cualquier servicio que no depende de filesystem/local se inicia. Los servicios que tienen una dependencia necesaria en el servicio filesystem/local no se iniciaron.
Este procedimiento explica cómo cambiar la configuración del sistema, de manera que un indicador sulogin aparezca inmediatamente después de que el servicio falla, en lugar de permitir que el inicio del sistema continúe.
$ svccfg -s svc:/system/console-login svc:/system/console-login> addpg site,filesystem-local dependency svc:/system/console-login> setprop site,filesystem-local/entities = fmri: svc:/system/filesystem/local svc:/system/console-login> setprop site,filesystem-local/grouping = astring: require_all svc:/system/console-login> setprop site,filesystem-local/restart_on = astring: none svc:/system/console-login> setprop site,filesystem-local/type = astring: service svc:/system/console-login> end
$ svcadm refresh console-login
Cuando se produce un fallo con el servicio system/filesystem/local:default, el comando svcs -vx se debe utilizar para identificar el fallo. Después de que se ha reparado el fallo, utilice el siguiente comando para borrar el estado de error y permitir que el inicio del sistema continúe:
$ svcadm clear filesystem/local
El archivo inetd.conf en el sistema no debe contener entradas. El archivo inetd.conf sólo debe contener comentarios de que se trata de un archivo heredado que ya no se utiliza directamente. Si el archivo inetd.conf contiene cualquier entrada, siga las instrucciones de esta sección para convertir estas configuraciones a servicios SMF. Los servicios que están configurados en el archivo inetd.conf pero no están configurados como un servicio SMF no están disponibles para su uso. Los servicios que se configuran en el archivo inetd.conf no son reiniciados por el comando inetd directamente. En cambio, el comando inetd es el iniciador delegado para los servicios convertidos.
Durante el inicio del sistema inicial, las configuraciones en el archivo inetd.conf se convierten automáticamente a servicios SMF. Después del inicio del sistema inicial, se pueden agregar entradas al archivo inetd.conf mediante la instalación de software adicional no entregado por paquetes Image Packaging System (IPS). El software entregado por paquetes IPS incluye cualquier manifiesto SMF requerido, y ese manifiesto SMF inicia esa instancia de servicio con los valores de propiedad correctos.
Si el archivo inetd.conf en su sistema contiene entradas, use el comando inetconv para convertir esas configuraciones a servicios SMF. El comando inetconv convierte entradas inetd.conf en archivos de manifiesto de servicio SMF e importa esos manifiestos al repositorio SMF para iniciar las instancias de servicio. Consulte la página del comando man inetconv(1M) para obtener información sobre opciones de comando y para ver ejemplos de uso del comando.
El nombre del nuevo manifiesto SMF incorpora service_name a partir de la entrada inetd.conf. La entrada del archivo inetd.conf se guarda como propiedad de la nueva instancia de servicio. El nuevo manifiesto SMF especifica los grupos de propiedades y las propiedades para definir las acciones enumeradas en la entrada inetd.conf. Después de ejecutar el comando inetconv, utilice los comandos svcs y svcprop para asegurarse de que la nueva instancia de servicio se haya creado y tenga los valores de propiedad correctos.
El comando inetd es el reiniciador delegado para servicios de Internet SMF. No utilice el comando inetd directamente para gestionar estos servicios. Utilice el comando inetadm sin opciones u operandos para ver una lista de los servicios controlados por inetd. Utilice los comandos inetadm, svcadm y svccfg para configurar y gestionar estos servicios convertidos.
El comando inetconv no modifica el archivo inetd.conf de entrada. Debe suprimir manualmente las entradas en el archivo inetd.conf después de ejecutar correctamente inetconv.
Para obtener más información sobre la configuración de servicios inetd que ya se convirtieron a servicios SMF, consulte Modificación de los servicios controlados por inetd.