disabilita lo script init.d in systemd


11

Ho cambiato il sistema init da sysvinit a systemd in un'installazione raspbian. L'installazione si avvia correttamente, ma ora avvia lightdm all'avvio. Non voglio che lo faccia.

Ho notato che lightdm.serviceè avviato all'avvio. Interruzione del servizio con

systemctl stop lightdm.service

funziona bene.

systemctl disable lightdm.service dovrebbe disabilitarlo, ma mi dà

Failed to issue method call: No such file or directory

systemctl status lightdm.service mi 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

Suppongo che lightdm sia avviato da uno script init.d anziché da uno script systemd e systemctl disablenon funzioni se l'origine è uno script init.d. Cosa devo fare invece per disabilitare lightdm a partire all'avvio?

modifica: maggiori informazioni

uscita di $ 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

uscita di 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

uscita di 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

Non consideriamo RPi / raspian di attualità con il significato di Server Fault. La natura entusiasta del dispositivo è più adatta a Unix & Linux , Super User o nel caso di domande non unix relative a Raspberry Pi .

Grazie. Domanda strana, dove posso trovare gli ambiti esatti di questi diversi siti da leggere sugli ambiti esatti di ciascuno?
Martijn,

Sì, è difficile, il tour e il centro assistenza per ognuno è un buon punto di partenza. Abbiamo anche chiarimenti su alcuni punti del nostro meta in particolare e rilevanti per te meta.serverfault.com/questions/5586/… .

Hrm. Mentre non sono d'accordo con questo, sono troppo un nuovo arrivato qui perché quell'opinione abbia un peso. Allo stesso tempo, immagino sia almeno tanto in tema su Unix e Linux. Chiederò una migrazione.
Martijn,

Risposte:


5

Prova (come root): -

systemctl disable graphical.target

Dopo un riavvio, dovresti essere in multi-usermodalità rispetto a graphical.

Se fallisce, controlla qual è il tuo obiettivo predefinito con: -

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

Si noti che l'unica differenza nei percorsi è la directory di livello superiore - o /libo /etc.

Quanto sopra dovrebbe essere un collegamento soft a multi-user.target. Se punta a graphical.targetcambiarlo usando (come 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

a seconda di dove è stato trovato il collegamento software nel ls -lcomando precedente .

Riavvia e speriamo che il tuo display manager non si avvii.

Per vedere quali obiettivi hai, corri: -

systemctl --all -t target

forse sorprendentemente, ciò mi atterra ancora nella luce
Martijn,

Hmm. Anche sorpreso. Ho scavato un po 'di più - il problema è che al momento posso solo SSH su un VPS e non ho un sistema "grafico" davanti a me per controllare i miei pensieri!
garethTheRed,

Ho modificato, ora che ho accesso a un sistema reale.
garethTheRed,

Stranamente, sta ancora avviando lightdm, anche se default.target in /etc/systemd/system/default.target è collegato a /lib/systemd/system/multi-user.target e systemctl list-units == type = target doesn elenca graphical.target come attivo. Ho la sensazione che sia a causa degli script init.d di fallback specifici presenti; Non ho ancora trovato la causa, ma il mio problema personale si sta allontanando dall'essere una domanda utile per scopi generali e sta diventando più una domanda sul forum "aiutami a risolvere il mio problema". Sarei grato per ulteriore aiuto, ma ammetto che non appartiene più allo scambio di stack.
Martijn,

1
Il modo corretto èsystemctl set-default multi-user
Majenko,

7

systemctl disablenon funziona se l'origine è uno init.dscript. Cosa devo fare invece per disabilitare l' lightdmavvio all'avvio?

Ironia della sorte, nessuno dei modi "ufficiali" per farlo è stato menzionato finora in nessuna risposta. Quindi per completezza, eccoli qui:

"Maschera" il servizio:

systemctl mask lightdm.service

Oppure si crea un proprio file di unità in quanto /etc/systemd/system/lightdm.servicediventa un vero cittadino di sistema di prima classe che può essere abilitato e disabilitato con i comandi enablee disable. I file di unità sostituiscono i init.dfile con lo stesso nome di base. Puoi intaccare lightdm.serviceciò che è stato scritto dalle persone Debian, se vuoi. ☺

Ulteriori letture


2

Puoi abilitare e disabilitare gli script di init con update-rc.dsu Debian. Usa update-rc.d lightdm disable.

Il motivo per cui la disabilitazione di graphical.target non funziona è che lightdm non ha alcuna conoscenza di graphical.target. È uno script init e si avvia su tutti i runlevel multiutente (2-5).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.