10

Acabo de instalar Ubuntu 16.04 LTS y descubrí que cuando ejecuto

usr@server:~$ sudo service <servicename> restart
usr@server:~$

El servicio se reinicia (puedo ver el estado con service <servicename> status), pero el shell vuelve directamente a la línea de comando sin lo esperado:

* Stopping <servicename>     [ OK ]
* Starting <servicename>     [ OK ]

— Eduardo Coria
fuente

¿Le echó un vistazo a los registros para ver si hay alguna información que pueda ayudar a diagnosticar el problema? Debería estar en / var / log /

— Diego

2

No hay problema con el servicio en sí. Es el símbolo del sistema que regresa sin salida lo que me desconcierta. Sucede con todos los servicios. El comando hace lo que se espera (iniciar / detener / reiniciar el servicio), pero no hay salida

— Eduardo Coria

9

No deberías esperar tal salida.

Para empezar, Ubuntu no se comportó de esta manera en versiones anteriores. Ubuntu fue un sistema emergente durante poco menos de una década, y el comportamiento del servicecomando en Ubuntu no se ha parecido durante todos esos años a lo que esperaba. Se puede ver el comportamiento inicial del servicecomando en la imagen en ¿Cómo obtengo el comando de servicio para imprimir la salida en 15.10? .

La respuesta es casi la misma para usted que para las personas con Ubuntu versión 15.10 el año pasado:

Estás utilizando Ubuntu versión 16.10, un sistema operativo systemd. La administración de servicios de su sistema ya no se realiza por arranque (o cualquier utilidad que lo haya hecho en cualquier sistema operativo que no sea Ubuntu que tenía antes). Lo realiza systemd.

El servicecomando puede ser el mismo ... pero el servicecomando Debian / Ubuntu es un script de shell que intenta detectar automáticamente si upstart o systemd es el administrador de servicios del sistema en ejecución, y ejecuta los comandos de administración de servicios nativos reales para upstart y systemd. Ejecuta dos rutas de código bastante diferentes para upstart y systemd.

comandos de gestión de servicios nativos de advenedizos son initctl start, initctl stop, initctl statusy así sucesivamente. Esos mensajes impresos a medida que avanzan.

comandos de gestión de servicios nativos de systemd son systemctl start, systemctl stop, systemctl statusy así sucesivamente. Esos no imprimen ninguna salida mientras operan.

Otras lecturas

— JdeBP
fuente

1

"No deberías esperar tal salida". No es un gran lugar para comenzar una respuesta. Básicamente estás diciendo: "Tu opinión es incorrecta". Creo que lo que querías decir es que "esto no es posible con systemd". Durante los días iniciales, la salida DID de Ubuntu ... está en la pregunta "¿Cómo obtengo el comando de servicio para imprimir la salida en 15.10?". Antes de 15.10, Ubuntu usaba upstart y upstart (como sysvinit) era detallado. Así que por favor no digas: "Ha sido así durante una década". No tiene Cambió en 15.10. Systemd no es detallado y ha sido súper irritante desde que las distribuciones comenzaron a implementarlo.

— bobpaul

El interrogador le dijo claramente qué esperaba xe, y el resultado inicial no se parece a eso. Estás confundido o no leíste la pregunta.

— JdeBP

0

En realidad no necesitas una salida correcta. Sin salida significa que está bien. Cuando un servicio no se inicia correctamente, Ubuntu le muestra algo como esto:

El trabajo para php5.6-fpm.service falló porque el proceso de control salió con el código de error. Consulte "estado de systemctl php5.6-fpm.service" y "journalctl -xe" para más detalles.

En mi caso, este ejemplo fue una configuración incorrecta en mi php-fpm.conf que no permitió que se iniciara el servicio. Después de seguir las instrucciones, ordené lo que estaba causando el error.

— Filipe Marques
fuente

Sin salida del comando de inicio / detención / reinicio del servicio

No deberías esperar tal salida.

Otras lecturas