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
Martijn
  • 233
  • 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.se], [su] or in the case of non unix related questions [raspberrypi.se]. –  Jul 03 '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 03 '14 at 10:12
  • Yeah it's difficult, the [about] and [help] for each is a good place to start. We also have clarification of certain points on our meta in particular and relevant to you http://meta.serverfault.com/questions/5586/are-raspberrypis-ever-on-topic-for-serverfault . –  Jul 03 '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 03 '14 at 10:31

3 Answers3

12

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

JdeBP
  • 68,745
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
garethTheRed
  • 33,957
  • possibly surprisingly, that still lands me in lightdm – Martijn Jul 03 '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 03 '14 at 14:01
  • I've edited, now that I've access to a real system. – garethTheRed Jul 03 '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 04 '14 at 10:45
  • Yes, it's definitely moving away from being a general purpose issue, but I've no problems with that. I've Googled (that's deseperate!). Does running sudo raspi-config give you the option to disable desktop at startup? – garethTheRed Jul 04 '14 at 10:53
  • I think I got a step closer in finding out that systemctl status lightdm has WantedBy multi-user. I haven't found a lightdm.service file nor have I seen lightdm.service in any wanted directories yet. Still, there must be some reason systemd thinks multi-user wants to have lightdm. – Martijn Jul 04 '14 at 11:12
  • Does dpkg -L lightdm show the lightdm.service file? – garethTheRed Jul 04 '14 at 11:16
  • dpkg -L lightdm | grep service gives me nothing. Nor does find / -name 'lightdm.service' as root – Martijn Jul 04 '14 at 11:18
  • I tried to move this to chat, but it was blocked by our firewall! What about trying sudo update-rc.d lightdm disable – garethTheRed Jul 04 '14 at 11:25
  • http://pastie.org/pastes/9354287 and something sort of close to success? lightdm doesnt start anymore. I would have expected (incorrectly?) that I would end up with a functioning terminal on booting, which I don't. I'm such a beginner that I don't know whether that's bad or good. – Martijn Jul 04 '14 at 11:33
  • This is very odd - it seems that Raspbian is using a mixture of both systemd and older rc.d init scripts which makes things more of a challenge. Did you try the sudo raspi-config command mentioned previously? – garethTheRed Jul 04 '14 at 11:39
  • rasbian is sysvinit, but there is a systemd package available. I think the last systemd step is running the LBS initv scripts (of which I was oblivious to just now), which leads to the odd hybrid situation. raspi-config already has the "Console text console" version still enabled. – Martijn Jul 04 '14 at 12:05
  • I found this http://raspberrypi.stackexchange.com/questions/1318/boot-without-starting-x-server – garethTheRed Jul 04 '14 at 12:10
  • after turning it off and on again, the last boot steps listed are ssh[426] starting OpenBSD Secure Shell server: sshd ssh[627] stopping OpenBSD Secure Shell server: sshd ssh[635] starting OpenBSD Secure Shell server: sshd and it "hangs" from there with a blinking cursor (no prompt) at the first line below it. I can SSH in now without problems, and ctrl-alt-f2 to a shell with no problem, but I expected the boot to end in a shell. – Martijn Jul 04 '14 at 12:10
  • I found this http://raspberrypi.stackexchange.com/questions/1318/boot-without-starting-x-server which is similar to what you've tried :-( On any other system, disabling the X server leaves you with a text login. If you can manage to login, check /etc/inittab (if you have one) and see what the default runlevel is. If you can, try change it to 3 which normally means text consoles instead of X. – garethTheRed Jul 04 '14 at 12:16
  • I see the default runlevel change resulted in a different boot order, but I still end with a shell that seems to be busy with something. It might still be wrong (well, it is), but it's workable for now (and I learned a lot). – Martijn Jul 04 '14 at 12:39
  • 1
    The correct way is systemctl set-default multi-user – Majenko May 03 '15 at 13:31
3

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

CameronNemo
  • 1,131