Why doesn't pstree command show init in Ubuntu 16.04 LTS?

Question

I am trying to examine the output from pstree command. But for some reason it always starts from something called as systemd as opposed to it being init. I have checked to see the process ID's of both init and systemd using ps aux command and init has a PID of 1, while systemd has some other PID. So why isn't init being shown in my pstree's output? Is there an option that I need to give?

Also I did read about systemd vs init controversy, but ubuntu 16.04 LTS still uses init to start everything right?

Update as to why different PIDs?

It turns out that different PIDs that I thought were part of my ignorance. The init had a PID 1, whereas systemd wasn't the thing that I was talking about. Instead when I ran ps aux|grep systemd, I found PIDs for /lib/systemd/systemd-*, where * means some extra characters. So what I was talking about was not systemd, but some other processes that were extensions(is it the correct word?) of systemd I guess.

Some of the examples for that * are as follows

/lib/systemd/systemd-journald
/lib/systemd/systemd-udevd
/lib/systemd/systemd-timesyncd

Answer 1

Since 15.04, init on Ubuntu is systemd. It is possible to use Upstart, but the default is systemd. For example, /sbin/init will be a link to /lib/systemd/systemd. /sbin/{shutdown,reboot,telinit,halt,runlevel,poweroff} are links to /sbin/systemctl. Even in 16.04, Upstart was used as a session init, so you might see Upstart as the parent process or an ancestor process in your graphical login (though it seems to have changed in 16.10).

The other processes you see are systemd components; they're developed and distributed along with systemd but many are not essential to running systemd as init. Many components can be replaced or disabled. To quote the systemd homepage:

systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. ... Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.

And this blog post from one of the creators of systemd (Lennart Poettering):

29. Myth: systemd doesn't allow your to replace its components.

    Not true, you can turn off and replace pretty much any part of systemd, with very few exceptions. And those exceptions (such as journald) generally allow you to run an alternative side by side to it, while cooperating nicely with it.