deshabilitar script init.d en systemd


11

Cambié el sistema init de sysvinit a systemd en una instalación raspbian. La instalación arranca bien, pero ahora comienza lightdm en el arranque. No quiero que haga eso.

Me di cuenta de que lightdm.servicese inició en el arranque. Detener el servicio con

systemctl stop lightdm.service

funciona bien.

systemctl disable lightdm.service debería deshabilitarlo, pero me da

Failed to issue method call: No such file or directory

systemctl status lightdm.service me da

lightdm.service - LSB: Light Display Manager
      Loaded: loaded (/etc/init.d/lightdm)
      Active: inactive (dead) since Thu, 03 Jul 2014 09:33:00 +0000; 22min ago
     Process: 762 ExecStop=/etc/init.d/lightdm stop (code=exited, status=0/SUCCESS)
     Process: 411 ExecStart=/etc/init.d/lightdm start (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/lightdm.service

Supongo que lightdm se inicia desde un script init.d en lugar de un script systemd, y systemctl disableno funciona si la fuente es un script init.d. ¿Qué debo hacer para deshabilitar lightdm a partir del inicio?

editar: más información

salida de $ ls -l /etc/systemd/system:

total 20
lrwxrwxrwx 1 root root   42 Jul  3 09:04 dbus-fi.epitest.hostap.WPASupplicant.service -> /lib/systemd/system/wpa_supplicant.service
lrwxrwxrwx 1 root root   37 Jul  3 13:03 default.target -> /lib/systemd/system/multi-user.target
drwxr-xr-x 2 root root 4096 Jul  3 09:00 getty.target.wants
drwxr-xr-x 2 root root 4096 Jul  3 09:04 graphical.target.wants
drwxr-xr-x 2 root root 4096 Oct 11  2013 local-fs.target.wants
drwxr-xr-x 2 root root 4096 Jul  3 09:04 multi-user.target.wants
drwxr-xr-x 2 root root 4096 Oct 11  2013 sysinit.target.wants
lrwxrwxrwx 1 root root   35 Mar 20  2013 syslog.service -> /lib/systemd/system/rsyslog.service

salida de systemctl --all -t target:

UNIT                LOAD   ACTIVE   SUB    JOB DESCRIPTION
all.target          error  inactive dead       all.target
basic.target        loaded active   active     Basic System
cryptsetup.target   loaded active   active     Encrypted Volumes
emergency.target    loaded inactive dead       Emergency Mode
final.target        loaded inactive dead       Final Step
getty.target        loaded active   active     Login Prompts
local-fs-pre.target loaded active   active     Local File Systems (Pre)
local-fs.target     loaded active   active     Local File Systems
multi-user.target   loaded active   active     Multi-User
network.target      loaded inactive dead       Network
nss-lookup.target   loaded inactive dead       Name Lookups
remote-fs.target    loaded active   active     Remote File Systems
rescue.target       loaded inactive dead       Rescue Mode
shutdown.target     loaded inactive dead       Shutdown
sockets.target      loaded active   active     Sockets
sound.target        loaded active   active     Sound Card
swap.target         loaded active   active     Swap
sysinit.target      loaded active   active     System Initialization
syslog.target       loaded active   active     Syslog
time-sync.target    loaded inactive dead       System Time Synchronized
umount.target       loaded inactive dead       Unmount All Filesystems

salida de ls -l /etc/systemd/system/multi-user.target.wants/:

total 8
drwxr-xr-x 2 root root 4096 Jul  3 09:04 .
drwxr-xr-x 7 root root 4096 Jul  3 13:03 ..
lrwxrwxrwx 1 root root   36 Oct 11  2013 remote-fs.target -> /lib/systemd/system/remote-fs.target
lrwxrwxrwx 1 root root   33 Jul  3 09:04 rsync.service -> /lib/systemd/system/rsync.service
lrwxrwxrwx 1 root root   35 Mar 20  2013 rsyslog.service -> /lib/systemd/system/rsyslog.service
lrwxrwxrwx 1 root root   32 Jul  3 09:04 sudo.service -> /lib/systemd/system/sudo.service
lrwxrwxrwx 1 root root   42 Jul  3 09:04 wpa_supplicant.service -> /lib/systemd/system/wpa_supplicant.service

No consideramos que RPi / raspian sea tópico con el significado de Falla del servidor. La naturaleza entusiasta del dispositivo se adapta mejor a Unix y Linux , Superusuario o en el caso de preguntas no relacionadas con Unix Raspberry Pi .

Gracias. Pregunta extraña, ¿dónde puedo encontrar los alcances exactos de estos diferentes sitios para leer sobre los alcances exactos de cada uno?
Martijn

Sí, es difícil, el recorrido y el centro de ayuda para cada uno es un buen lugar para comenzar. También tenemos aclaraciones sobre ciertos puntos en nuestro meta en particular y relevantes para usted meta.serverfault.com/questions/5586/… .

Hrm. Si bien no estoy de acuerdo con eso, soy demasiado recién llegado aquí para que esa opinión tenga algún peso. Al mismo tiempo, supongo que es al menos tanto en el tema de Unix y Linux. Pediré una migración.
Martijn

Respuestas:


5

Prueba (como root): -

systemctl disable graphical.target

Después de reiniciar, debería estar en multi-usermodo en lugar de hacerlo graphical.

Si eso falla, verifique cuál es su objetivo predeterminado con: -

ls -l /lib/systemd/system/default.target
# or, depending on your distro
ls -l /etc/systemd/system/default.target

Tenga en cuenta que la única diferencia en las rutas es el directorio de nivel superior, ya sea /libo /etc.

Lo anterior debe ser un enlace suave a multi-user.target. Si apunta a, graphical.targetentonces cámbielo usando (como root): -

ln -sf /lib/systemd/system/multi-user.target /lib/systemd/system/default.target
# or
ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

dependiendo de dónde se encontró el enlace flexible en el ls -lcomando anterior .

Reinicie y esperemos que su administrador de pantalla no se inicie.

Para ver qué objetivos tienes, ejecuta: -

systemctl --all -t target

posiblemente sorprendentemente, eso todavía me deja en lightdm
Martijn

Hmm Sorprendido también. He cavado un poco más: ¡el problema es que solo puedo enviar SSH a un VPS en este momento y no tengo un sistema 'gráfico' frente a mí para verificar mis pensamientos!
garethTheRed

He editado, ahora que tengo acceso a un sistema real.
garethTheRed

Curiosamente, todavía está iniciando lightdm, aunque default.target en /etc/systemd/system/default.target está enlazado a /lib/systemd/system/multi-user.target y systemctl list-units == type = target doesn No enumere graphical.target como activo. Tengo la sensación de que se debe a las secuencias de comandos initback fallback específicas presentes; Todavía no he encontrado qué lo está causando, pero mi problema personal se está desviando de ser una pregunta útil de propósito general, y se está convirtiendo en una pregunta del foro "ayúdenme a solucionar mi problema". Estaría agradecido por más ayuda, pero reconozco que ya no pertenece al intercambio de pila.
Martijn

1
La forma correcta essystemctl set-default multi-user
Majenko

7

systemctl disableno funciona si la fuente es un init.dscript. ¿Qué debo hacer para deshabilitar el lightdminicio en el arranque?

Irónicamente, ninguna de las formas "oficiales" de hacer esto se ha mencionado en ninguna respuesta hasta ahora. Entonces, para completar, aquí están:

Usted "enmascara" el servicio:

systemctl mask lightdm.service

O puede crear un archivo de unidad propio ya /etc/systemd/system/lightdm.serviceque luego se convierte en un ciudadano de systemd de primera clase que se puede habilitar y deshabilitar con los comandos enabley disable. Los archivos de la unidad reemplazan a los init.darchivos del mismo nombre base. Si lo desea, puede lightdm.serviceescribir lo que escribió la gente de Debian. ☺

Otras lecturas


2

Puede habilitar y deshabilitar scripts de inicio con update-rc.dDebian. Uso update-rc.d lightdm disable.

La razón por la que deshabilitar graphical.target no funciona es que lightdm no tiene conocimiento de graphical.target. Es un script de inicio y comienza en todos los niveles de ejecución multiusuario (2-5).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.