systemctl, cómo desenmascarar

27 
root@gcomputer:~# systemctl status x11-common
● x11-common.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

Lo intenté systemctl unmask x11-commony systemctl unmask x11-common.serviceeso no cambió nada.

¿Cómo lo desenmascaro?

systemd Albert
fuente

Respuestas:

35

Los comandos que está utilizando son correctos . Ver también el manual .

Parece que el unmaskcomando falla cuando no hay un archivo de unidad existente en el sistema que no sea el enlace simbólico /dev/null. Si es maskun servicio, eso crea un nuevo enlace simbólico /dev/nullen /etc/systemd/systemdonde systemd busca los archivos de la unidad para cargar en el arranque. En este caso, no hay un archivo de unidad real.

Otros parecen tener problemas similares

x11-common.serviceTambién estaba enmascarado en mi sistema. Puedes arreglarlo así:

Primero verifique que el archivo de la unidad sea un enlace simbólico a /dev/null

file /lib/systemd/system/x11-common.service

debería volver:

/lib/systemd/system/x11-common.service: symbolic link to /dev/null

en cuyo caso, elimínelo

sudo rm /lib/systemd/system/x11-common.service

Como ha cambiado un archivo de unidad, debe ejecutar esto:

sudo systemctl daemon-reload

ahora verifique el estado:

systemctl status x11-common

si no dice cargado y ejecutándose (si el círculo sigue siendo rojo), reinstale el paquete:

sudo apt-get install --reinstall x11-common

y vuelve a cargar el demonio

sudo systemctl daemon-reload

y verifique el estado una vez más

systemctl status x11-common

Ahora es verde y se está ejecutando :) El servicio no tiene un archivo de unidad systemd, pero systemd felizmente usa el script para ello /etc/init.d.

Zanna
fuente
Ok, pregunta de seguimiento: si incluso estaba enmascarado en su sistema, ¿para qué sirve este servicio? Parece que realmente no es necesario si está enmascarado para los dos.
Albert
@Albert [Ver aquí.] ( Askubuntu.com/questions/712276/… ) parece que el servicio funciona sin el archivo de unidad systemd (tiene un archivo en /etc/init/...). Es posible que desee hacer una nueva pregunta. Lo que hice no hizo ninguna diferencia aparente, solo el servicio se muestra como cargado, habilitado, detenido (está activo en el inicio) (verde) en lugar de cargado enmascarado muerto (rojo). Debería leer mis registros ...
Zanna
Si una actualización para systemd viene por, el archivo se vuelve a instalar la unidad, así que esto no es realmente una solución estructural
hbogert
@hbogert, ¿sucede eso incluso si no hubiera un archivo unitario aparte del enlace simbólico a /dev/null? Sin embargo, tienes razón sobre mi respuesta. Yo llamaría a esta solución una solución para un ... comportamiento confuso ... de systemd
Zanna
¿Podría describir su primera oración en términos de archivos exactos que importan en este caso (porque realmente no entiendo el escenario que describe)?
hbogert
2

Podría ser que su servicio tenga un archivo de anulación vacío, como este:

● redis-server.service - Almacén avanzado de valores clave Cargado: cargado (/lib/systemd/system/redis-server.service; enmascarado; proveedor preestablecido: habilitado) Drop-In: / etc / systemd / system / redis-server .service.d └─limit.conf

Compruebe si limit.conf es un archivo vacío. Si es así, quítelo. Entonces el servicio debe ser desenmascarado.

Erik Hensema
fuente
0

Siga los pasos a continuación:

  1. systemctl edit systemd-hostnamed

    Agregue las 2 líneas a continuación y salga del editor (no olvide guardar cuando se le solicite):

    [Service]
PrivateNetwork=no

  2. Esto creará un archivo override.conf con las 2 líneas anteriores en el directorio:

    /etc/systemd/system/systemd-hostnamed.service.d/

  3. La actualización systemd:

    systemctl daemon-reload

  4. Luego reinicie el servicio:

    systemctl restart systemd-hostnamed

Ahora debería poder correr hostnamectlsin que se cuelgue.

Hossein
fuente