On 14.04 LTS there was a /var/log/boot.log file but this has gone on 16.04. All advice I have seen says to use systemd's journalctl command.


Journalctl gives in depth syslog style log entries, what boot.log on 14.04 gave you was a log of what actually appeared on the console, i.e. <Service Name> .... [OK] or <Service Name> ....[FAIL]. It is this summary information that I wish to access on a headless server. I found this gave a very useful summary and then if something was unhappy I could investigate further. Also some daemons would only spout useful diagnostic info on the console and not in the log (maybe systemd deals with this better).

Is there such a typescript style log of console output on 16.04?

This is not a duplicate of the aforementioned query as I know about journalctl. It is that journalctl gives different information from what boot.log did (i.e. the latter logged what appeared on the console screen).

  • 1
    Possible duplicate of No more boot logging since 16.04? – Android Dev Feb 10 '17 at 13:04
  • Also, you would have to filter the output if you don't run it right after you finished booting up, but you could do dmesg > bootlog.txt – Android Dev Feb 10 '17 at 13:06
  • dmesg gives low level log information rather like journalctl. I'd say its not a duplicate as boot.log and jounralctl give very different levels of logs. The former was a scrape of the console done by plymouth I believe, the latter is very similar to what goes into syslog. – John Hobbins Feb 10 '17 at 13:18

If you want to see which services failed or started, use systemctl:

$ sudo systemctl --type=service
  UNIT                        LOAD      ACTIVE SUB     DESCRIPTION
  accounts-daemon.service     loaded    active running Accounts Service
  acpid.service               loaded    active running ACPI event daemon
  alsa-restore.service        loaded    active exited  Save/Restore Sound Card Stat
  apparmor.service            loaded    active exited  LSB: AppArmor initialization
  atd.service                 loaded    active running Deferred execution scheduler
  avahi-daemon.service        loaded    active running Avahi mDNS/DNS-SD Stack
  binfmt-support.service      loaded    active exited  Enable support for additiona
  cgmanager.service           loaded    active running Cgroup management daemon
  click-system-hooks.service  loaded    active exited  Run Click system-level hooks
  colord.service              loaded    active running Manage, Install and Generate
  console-setup.service       loaded    active exited  Set console font and keymap
  cron.service                loaded    active running Regular background program p
  cups-browsed.service        loaded    active running Make remote CUPS printers av
  cups.service                loaded    active running CUPS Scheduler
  dbus.service                loaded    active running D-Bus System Message Bus
  deluge-web.service          loaded    active running Deluge Bittorrent Client Web
  deluged.service             loaded    active running Deluge Bittorrent Client Dae
  ebtables.service            loaded    active exited  LSB: ebtables ruleset manage
  getty@tty1.service          loaded    active running Getty on tty1
  grub-common.service         loaded    active exited  LSB: Record successful boot 

It opens in a pager by default.

If you want to see what failed during boot, again use systemctl:

$ systemctl --state=failed
  UNIT                      LOAD   ACTIVE SUB    DESCRIPTION
● var-www-archlinux.mount   loaded failed failed /var/www/archlinux
● openvpn.service           loaded failed failed OpenVPN service
● openvpn@auth-ldap.service loaded failed failed OpenVPN connection to auth-ldap
● openvpn@server.service    loaded failed failed OpenVPN connection to server

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

4 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

Note that this isn't limited to just services - failed mounts, and other systemd units are also listed. You can restrict the output to a type of systemd unit using the --type option.

Also some daemons would only spout useful diagnostic info on the console and not in the log (maybe systemd deals with this better).

systemd-journald does a pretty thorough job of capturing all output from services.

  • I have used those commands you mentioned above (with less filtering) and noticed that say with a service like ntpd, systemctl said loaded active exited when in fact on the console it had reported an error (marked as [FAILED]). In fact it couldn't bind to port - I've fixed that issue. This led to the `where is the console scrape of output/boot.log' question as the only way you knew there was a problem was because it was marked as exited by systemd, which wouldn't be picked up by your failed filter above. Whereas on 14.04 it would have shown up as failed in boot.log. – John Hobbins Feb 10 '17 at 13:55
  • sudo apt-get install systemctl ---> E: Unable to locate package systemctl. What repo is it in? – Geoffrey Anderson Aug 2 '18 at 17:01
  • @GeoffreyAnderson either the command is already installed or there's no point in installing it. Are you using 14.04 or running in a container? – muru Aug 2 '18 at 18:34

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.