I run all my EC2 workloads on Amazon Linux. It comes with a superb AWS integration, a secure default configuration, regular security updates, and I can open AWS Support tickets if I run into any problems.

In late December 2017, AWS announced the successor of Amazon Linux: Amazon Linux 2.

AWS also announced that Amazon Linux 2018.03 is the last release for the current generation of Amazon Linux and will be supported until June 30, 2020. Therefore, you have to come up with a migration plan.

Amazon Linux 2 comes with the same benefits as Amazon Linux, but it adds some new capabilities:

long-term support: Amazon Linux 2 supports each LTS release for five years

on-premises support: virtual machine images for on-premises development and testing are available

systemd: replacing SystemVinit

extras library: provides up-to-date versions of software bundles such as nginx

Let’s dive into some of the changes in more detail. At the end of the post, I will also outline some pitfalls I encountered when migrating our Free Templates for AWS CloudFormation to Amazon Linux 2.

Further reading: Release Notes, FAQs, AWS Blog Post, Announcement

Long-term support

The Amazon Linux delivers a continuous flow of updates that allow you to roll from one version of the Amazon Linux AMI to the most recent. A yum update always moves your system to the latest Amazon Linux version. There were no versions of Amazon Linux available, only snapshots.

Amazon Linux 2 changes this. You will have Amazon Linux 2 versions that are supplied with updates for five years. Once a new Amazon Linux 2 LTS release becomes available, no breaking changes will be introduced by AWS for this release.

systemd

Amazon Linux uses SysVinit to bootstrap the Linux user space and to manage system processes after booting. This procedure is usually called init. One of the major drawbacks of SysVinit is that it starts tasks serially, waiting for each to finish loading before moving on to the next. This can result in long delays during boot.

Amazon Linux 2 uses systemd as the init system. systemd executes elements of its startup sequence in parallel, which is faster than the traditional serial approach from SysVinit . systemd can also ensure that a service is running (e.g., it restarts a service if it crashed).

systemd is not just the name of the init system daemon but also refers to the entire software bundle around it, which includes:

journald : responsible for event logging (replaces syslog)

: responsible for event logging (replaces syslog) udevd : device manager for the Linux kernel, which handles the /dev directory and all user space actions when adding/removing devices

: device manager for the Linux kernel, which handles the /dev directory and all user space actions when adding/removing devices logind : manages user logins and seats in various ways.

I will not cover udevd and logind in this post. You should not get in touch with them as a normal user like me. Keep in mind that networking configuration is not controlled by networkd (also part of systemd software bundle). Instead, networking configuration is controlled by cloud-init which is triggered by systemd several times during boot. cloud-init handles early initialization of an EC2 instance (also works with other vendors).

Further reading: systemd man page

Reading logs from journald

To read all system logs (journal in journald terminology), starting with the oldest entry, run journalctl . The output is paged through less by default. Which means you can scroll down / up an entry with the DOWN / UP arrow keys, or scroll a full page down/up with the SPACE / b keys. Press the q key to quit. To reverse the order, run journalctl -r .

To show only the most recent journal entries, and continuously print new entries, run journalctl -f (like a tail -f ).

There are many ways to filter the output. Based on priority, run journalctl -p err to get levels alert, crit, and err (using syslog log levels). Based on the unit, run journalctl -u sshd to get all entries for sshd . Check the further reading links for more information.

Keep in mind that some applications still write logs to /var/log . Journald also forwards logs to rsyslog which is configured ( /etc/rsyslog.conf ) to write some of them to files in /var/log .

Further reading: journalctl man page

Controlling systemd services

To start a service (unit in systemd terminology), you run: