13

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:

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

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
Improve this question
4
  • 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. Commented Jul 3, 2014 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? Commented Jul 3, 2014 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/… . Commented Jul 3, 2014 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. Commented Jul 3, 2014 at 10:31

3 Answers 3

Reset to default
13

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

Improve this answer
5

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
Improve this answer
17
  • possibly surprisingly, that still lands me in lightdm Commented Jul 3, 2014 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! Commented Jul 3, 2014 at 14:01
  • I've edited, now that I've access to a real system. Commented Jul 3, 2014 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. Commented Jul 4, 2014 at 10:45
  • 1
    The correct way is systemctl set-default multi-user Commented May 3, 2015 at 13:31
4

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).

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.