I changed the init system from sysvinit to systemd on a raspbian installation. The install boots fine, but now starts lightdm on boot. I don't want it to do that.

I noticed lightdm.service is started on boot. Stopping the service with

systemctl stop lightdm.service

works fine.

systemctl disable lightdm.service should disable it, but gives me

Failed to issue method call: No such file or directory

systemctl status lightdm.service gives me

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

I'm assuming that lightdm is started from an init.d script rather than a systemd script, and systemctl disable doesn't work if the source is an init.d script. What should I do instead to disable lightdm starting at boot?

edit: More info

output of $ 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

output of systemctl --all -t target:

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

output of 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

migrated from serverfault.com Jul 3 '14 at 11:56

This question came from our site for system and network administrators.

  • We don't consider RPi/raspian to be topical with the meaning of Server Fault. The enthusiast nature of the device is better suited to Unix & Linux, Super User or in the case of non unix related questions Raspberry Pi. – Iain Jul 3 '14 at 10:05
  • Thanks. Odd question, where can I find the exact scopes of these different sites to read up on the exact scopes of each? – Martijn Jul 3 '14 at 10:12
  • Yeah it's difficult, the tour and help center for each is a good place to start. We also have clarification of certain points on our meta in particular and relevant to you meta.serverfault.com/questions/5586/… . – Iain Jul 3 '14 at 10:15
  • Hrm. While I disagree with that, I'm way too much of a newcomer here for that opinion to have any weight. At the same time, it is at least as much on topic on Unix & Linux I guess. I'll ask for a migration. – Martijn Jul 3 '14 at 10:31

Try (as root):-

systemctl disable graphical.target

After a restart, you should be in multi-user mode as opposed to graphical.

If that fails, check what your default target is with:-

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

Note that the only difference in the paths is the top level directory - either /lib or /etc.

The above should be a soft link to multi-user.target. If it points to graphical.target then change it using (as 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

depending on where the soft link was found in the previous ls -l command.

Reboot and hopefully your display manager won't start.

To see what targets you have, run:-

systemctl --all -t target
  • possibly surprisingly, that still lands me in lightdm – Martijn Jul 3 '14 at 13:45
  • Hmm. Suprised too. I've done a bit more digging - the problem is that I can only SSH to a VPS at the moment and haven't a 'graphical' system in front of me to check my thoughts! – garethTheRed Jul 3 '14 at 14:01
  • I've edited, now that I've access to a real system. – garethTheRed Jul 3 '14 at 20:15
  • Oddly, it's still starting lightdm, even though default.target in /etc/systemd/system/default.target is symlinked to /lib/systemd/system/multi-user.target, and systemctl list-units ==type=target doesn't list graphical.target as active. I have the feeling it's because of the specific fallback init.d scripts present; I haven't found what's causing it yet, but my personal issue is veering away from being a useful general purpose question, and is becoming more of a "help me fix my problem" forum question. I'd be grateful for more help, but acknowledge it doesn't belong on stack exchange anymore. – Martijn Jul 4 '14 at 10:45
  • 1
    The correct way is systemctl set-default multi-user – Majenko May 3 '15 at 13:31

systemctl disable doesn't work if the source is an init.d script. What should I do instead to disable lightdm starting at boot?

Ironically, neither of the "official" ways of doing this have been mentioned in any answer so far. So for completeness, here they are:

You "mask" the service:

systemctl mask lightdm.service

Or you create a unit file of your own as /etc/systemd/system/lightdm.service that then becomes a proper first-class systemd citizen that can be enabled and disabled with the enable and disable commands. Unit files supersede init.d files of the same basename. You can nick the lightdm.service that was written by Debian people, if you like. ☺

Further reading


You can enable and disable init scripts with update-rc.d on Debian. Use update-rc.d lightdm disable.

The reason disabling graphical.target does not work is that lightdm has no knowledge of graphical.target. It is an init script and starts on all multi-user runlevels (2-5).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.