desativar o script init.d no systemd


11

Mudei o sistema init de sysvinit para systemd em uma instalação raspbian. A instalação é inicializada corretamente, mas agora inicia o lightdm na inicialização. Eu não quero fazer isso.

Notei que lightdm.serviceé iniciado na inicialização. Parando o serviço com

systemctl stop lightdm.service

funciona bem.

systemctl disable lightdm.service deve desativá-lo, mas me dá

Failed to issue method call: No such file or directory

systemctl status lightdm.service me dá

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

Estou assumindo que o lightdm é iniciado a partir de um script init.d em vez de um script systemd, e systemctl disablenão funciona se a fonte for um script init.d. O que devo fazer para desativar o lightdm iniciando na inicialização?

editar: Mais informações

saída 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

saída 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

saída 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

Não consideramos o RPi / raspian um tópico com o significado de Falha no servidor. A natureza entusiasta do dispositivo é mais adequada para Unix e Linux , Superusuário ou no caso de perguntas não relacionadas ao unix, Raspberry Pi .

Obrigado. Pergunta estranha, onde posso encontrar os escopos exatos desses sites diferentes para ler os escopos exatos de cada um?
287 Martijn

Sim, é difícil, o tour e o centro de ajuda de cada um é um bom lugar para começar. Também temos esclarecimentos sobre determinados pontos de nossa meta em particular e relevantes para você meta.serverfault.com/questions/5586/… .

Hrm. Embora eu discorde disso, sou novato demais para que essa opinião tenha algum peso. Ao mesmo tempo, acho que é pelo menos o mesmo tópico sobre Unix e Linux. Vou pedir uma migração.
287 Martijn

Respostas:


5

Tente (como root): -

systemctl disable graphical.target

Após uma reinicialização, você deve estar no multi-usermodo, por oposição a graphical.

Se isso falhar, verifique qual é o seu destino padrão: -

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

Observe que a única diferença nos caminhos é o diretório de nível superior - ou /libou /etc.

O acima deve ser um link para multi-user.target. Se apontar para graphical.targetalterá-lo 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

dependendo de onde o link virtual foi encontrado no ls -lcomando anterior .

Reinicie e esperamos que o seu gerenciador de telas não seja iniciado.

Para ver quais alvos você possui, execute: -

systemctl --all -t target

possivelmente, surpreendentemente, que ainda me aterra no LightDM
Martijn

Hmm. Surpreso também. Eu fiz um pouco mais de escavação - o problema é que eu só posso SSH para um VPS no momento e não tenho um sistema 'gráfico' na minha frente para verificar meus pensamentos!
precisa saber é o seguinte

Eu editei, agora que tenho acesso a um sistema real.
precisa saber é o seguinte

Estranhamente, ele ainda está iniciando o lightdm, apesar de default.target em /etc/systemd/system/default.target estar vinculado a /lib/systemd/system/multi-user.target e systemctl list-units == type = target doesn listar graphical.target como ativo. Eu sinto que é por causa dos scripts init.d específicos de fallback presentes; Ainda não encontrei o que está causando isso, mas meu problema pessoal está se tornando uma questão útil de propósito geral e está se tornando mais uma questão do fórum "me ajude a corrigir meu problema". Ficaria grato por mais ajuda, mas reconheço que não pertence mais à troca de pilhas.
Martijn

1
A maneira correta ésystemctl set-default multi-user
Majenko

7

systemctl disablenão funciona se a fonte for um init.dscript. O que devo fazer para desativar lightdma inicialização na inicialização?

Ironicamente, nenhuma das maneiras "oficiais" de fazer isso foi mencionada em nenhuma resposta até agora. Portanto, para completar, aqui estão elas:

Você "mascara" o serviço:

systemctl mask lightdm.service

Ou você cria um arquivo de unidade por conta própria, /etc/systemd/system/lightdm.serviceque se torna um cidadão do sistema de primeira classe adequado que pode ser ativado e desativado com os comandos enablee disable. Os arquivos de unidade substituem os init.darquivos com o mesmo nome de base. Você pode copiar o lightdm.serviceque foi escrito pelo pessoal do Debian, se quiser. ☺

Leitura adicional


2

Você pode habilitar e desabilitar os scripts init update-rc.dno Debian. Use update-rc.d lightdm disable.

O motivo de desativar o graphical.target não funciona é que o lightdm não tem conhecimento do graphical.target. É um script init e inicia em todos os níveis de execução multiusuário (2-5).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.