3

After an unexpected restart my debian machine is booting up to a terminal screen instead of gui.

I'm not sure what to do to diagnose the problem.. but I've noticed that all of the services in /etc/rc2.d/ (inittab says run level 2 ) are not running..

I look at cron for example : running cron

Someone please help me to understand why running S17cron doesn't work, but running the sym linked file directly works.

What am I missing? Does anyone know how or why my system is in this condition? how to fix?

  • I don't have anything to look at on my side but it's possible that it uses $0 when it tries to use systemctl to start the service. The root of the problem is that it's trying to find a service called s17cron which it can't because the unit file is called just cron apparently. – Bratchley May 18 '15 at 2:48
10

Forget about /etc/inittab and run levels.

As the systemd doco says, in the systemd world the concept of run levels is "obsolete". systemd itself works in terms of targets, not run levels.

Also obsolete is your /etc/inittab file. The upgrade from Debian 7 to Debian 8 switches the init system from System 5 init+rc to systemd. It leaves /etc/inittab lying around, because that file is not properly assigned as the property of a package in Debian 7.

What /etc/inittab says is entirely meaningless. Not only does systemd totally ignore that file; but systemd does not have a concept of current run level in the first place.

Forget about Systemv 5 rc scripts.

That's possibly a bit strong, but it's necessary to make the point that you have demonstrated several bad habits that you need to un-learn. One, indeed, you had to un-learn several version of Debian ago.

  • Don't run scripts in /etc/rc*.d/ directly. Firstly, you'll do it wrongly, as you are doing here, and things won't work. Secondly, there's no guarantee that that symbolic link farm exists even on non-systemd systems. One could be using file-rc instead of sysv-rc, for example.
  • Don't run scripts in /etc/init.d/ directly. On systemd operating systems there's no guarantee that those scripts even exist, let alone that they are what are specifying your service. Even on Debian 7, there were systemd units supplanting System 5 rc scripts; and this is more so on Debian 8. The correct commands to use are:
    • systemctl with its status, start, stop, enable, and disable subcommands
    • service
    • update-rc.d and invoke-rc.d, but only if you are a package maintainer script

The behaviour of the commands that you have observed is thus a complete red herring, and nothing to do with why your system is bootstrapping in the way that it is.

Diagnose your problem properly with the tools available.

There are several programs that you should be running at this point. These include:

  • systemctl get-default to determine whether your system is even configured to boot to graphical.target in the first place.
  • systemctl list-units to show what services and targets are running. Your X display manager is a service.
  • systemctl status to show why a failed service has failed.
  • journalctl -x -b to look at the log since boot time.

Further reading

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.