The new features of RedHat Enterprise Linux 7 – Part 1

I know what your thinking, “come on man, RedHat EL 7 has been out for nearly two freaking years now, get up to date”. Well, if you’re already familiar and using RedHat EL 7, please feel free to go back to watching clips of flower arranging on Youtube or whatever it is you normally do when you’re not reading tech blogs.

OK, now we’ve got rid of the too-kool-for-skool-I’ve-got-a-selfie-with-Linus-Torvalds brigade, I’ll continue. If, like me, you work in an enterprise IT environment, you’ll understand that the pace of change can be a little slow (unless it’s a change requested by a senior manager, then it’s warp factor 8). I suspect that many of you are only just starting to roll out RHEL 7. This is the situation I found myself in. I’d also heard stories about it being different. So I decided I better find out what had changed. The problem was that all I could initially find were sites with a summary of the new features but not much detail or links to paid courses (I did later find some good resources but I still haven’t found a single site covering all of  what I wanted to know). So I decided to find out for myself and document what I found. In other words, I’ve read the manuals so you don’t have to! Aren’t I a lovely bloke!

This blog is an overview of the new features. For a more technical perspective with the commands and examples, see this article in our Unix & storage wiki .


Forget init scripts, service, chkconfig and run levels pretty much. This is a biggie. The media were reporting that grey beards (I think they meant people like me) were up in arms about systemd (I wasn’t but that was mainly because I was totally oblivious to this controversy). It was called un-unix like. You know, that stuff about small components doing one thing well. And I can see what they were getting at. The last thing we want is our beloved OS becoming more Windows like. And what was wrong with system V init anyway?

Well, having investigated systemd I can see why it’s been developed. One of the big advantages is it’s much faster starting up. I saw one RedHat 7 presentation on Youtube (yes, I lead a sad life) in which one of the presenters claimed a RedHat container with systemd could be started in less than a second (I’m definitely going to check this out so look out for that in a future blog). First off I thought, so what? We usually book maintenance slots for reboots and who cares if a reboot takes a minute or five minutes? If it’s a physical install, the server diagnostics routines hold everything up anyway. Then I started thinking about cloud. If you’re running autoscaling, the quicker the start up the better. And that’s what it’s all about in my opinion, a cloud/container enabling technology. Of course there’s loads of other use cases and a quick boot certainly doesn’t do any harm.

So how does systemd perform this miracle? By using sockets. As soon as a process is available, it can be detected via a socket and other dependent processes started.  Process dependencies are defined so, for example,  sshd is dependent on sshd-keygen.service. By using sockets, as soon as sshd-keygen.service is available, it can be detected and  sshd can start (see below for the sshd dependency tree). Stuff that isn’t dependent on each other starts up at the same time. The result, fast boots.

ip-10-51-72-53:root> #systemctl list-dependencies sshd
│ ├─-.slice
│ └─system.slice
│ ├─dbus.socket
│ ├─dm-event.socket
│ ├─rpcbind.socket
│ ├─systemd-initctl.socket
│ ├─systemd-journald.socket
│ ├─systemd-shutdownd.socket
│ ├─systemd-udevd-control.socket
│ └─systemd-udevd-kernel.socket
│ ├─dev-hugepages.mount
│ ├─dev-mqueue.mount
│ ├─kmod-static-nodes.service
│ ├─lvm2-lvmetad.socket
│ ├─lvm2-monitor.service
│ ├─plymouth-read-write.service
│ ├─plymouth-start.service
│ ├─proc-sys-fs-binfmt_misc.automount
│ ├─sys-fs-fuse-connections.mount
│ ├─sys-kernel-config.mount
│ ├─sys-kernel-debug.mount
│ ├─systemd-ask-password-console.path
│ ├─systemd-binfmt.service
│ ├─systemd-journal-flush.service
│ ├─systemd-journald.service
│ ├─systemd-modules-load.service
│ ├─systemd-random-seed.service
│ ├─systemd-sysctl.service
│ ├─systemd-tmpfiles-setup-dev.service
│ ├─systemd-tmpfiles-setup.service
│ ├─systemd-udev-trigger.service
│ ├─systemd-udevd.service
│ ├─systemd-update-utmp.service
│ ├─systemd-vconsole-setup.service
│ ├─
│ ├─
│ │ ├─-.mount
│ │ ├─app.mount
│ │ ├─boot.mount
│ │ ├─rhel-import-state.service
│ │ ├─rhel-readonly.service
│ │ ├─systemd-remount-fs.service
│ │ └─var.mount
│ └─
│ ├─dev-disk-by\x2did-dm\x2dname\x2dvg00\x2dlvswap.swap
│ ├─dev-disk-by\x2did-dm\x2duuid\x2dLVM\x2dcQOwTgrrdeaVP3eeblvBaQWPcuj6419oSlKySxHJNYC1u0dyOt9vSEmMdvNvU0qO.swap
│ ├─dev-disk-by\x2duuid-3c4ae18e\x2d9f50\x2d425f\x2d9cb1\x2d74f5e023cd5b.swap
│ ├─dev-disk-by\x2duuid-3c4ae18e\x2d9f50\x2d425f\x2d9cb1\x2d74f5e023cd5b.swap
│ ├─dev-dm\x2d0.swap
│ ├─dev-mapper-vg00\x2dlvswap.swap
│ └─dev-vg00-lvswap.swap

Two concepts to be aware of are units and targets. A unit is a file which contains the configuration of a service to be started. A target is a grouping mechanism to group services that need to be started at the same time. Some targets have been put together to correspond to the old run levels, e.g. corresponds  to run level 3 and to run level 5. So which services will start in One way to find out is to cd /etc/systemd/system/ and list the files. You’ll see something like the following:

ip-10-51-72-53:root> #pwd
ip-10-51-72-53:root> #ls -l
total 0
lrwxrwxrwx. 1 root root 38 Aug 18 2015 auditd.service -> /usr/lib/systemd/system/auditd.service
lrwxrwxrwx. 1 root root 37 Aug 18 2015 crond.service -> /usr/lib/systemd/system/crond.service
lrwxrwxrwx. 1 root root 42 Aug 18 2015 irqbalance.service -> /usr/lib/systemd/system/irqbalance.service
lrwxrwxrwx. 1 root root 37 Aug 18 2015 kdump.service -> /usr/lib/systemd/system/kdump.service
lrwxrwxrwx. 1 root root 46 Aug 18 2015 NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
lrwxrwxrwx. 1 root root 36 Aug 21 2015 ntpd.service -> /usr/lib/systemd/system/ntpd.service
lrwxrwxrwx. 1 root root 39 Aug 18 2015 postfix.service -> /usr/lib/systemd/system/postfix.service
lrwxrwxrwx. 1 root root 40 Aug 18 2015 -> /usr/lib/systemd/system/
lrwxrwxrwx. 1 root root 39 Aug 18 2015 rsyslog.service -> /usr/lib/systemd/system/rsyslog.service
lrwxrwxrwx. 1 root root 36 Aug 18 2015 sshd.service -> /usr/lib/systemd/system/sshd.service
lrwxrwxrwx. 1 root root 37 Aug 18 2015 tuned.service -> /usr/lib/systemd/system/tuned.service

So these are the services that will start once the server transitions to multi-user target, ( the command for controlling systemd is systemctl and I’m sure there’s a option for showing this but I couldn’t work out what it is!). And what do the *.service files contain? The parameters allowing systemd to control the service, for example here’s sshd.service

ip-10-51-72-53:root> #cat /usr/lib/systemd/system/sshd.service
Description=OpenSSH server daemon sshd-keygen.service

ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID


It describes dependencies, commands to run and the target to run at for systemd to interpret. There’s no start up scripts.

So that’s a brief overview of how systemd work. As already mentioned, for practical details and examples of how to use systemd see this wiki article .


journald is part of systemd . Why integrate a logging service with a server initialisation service? Well, one reason is so you can run cool commands like this:

ip-10-51-72-53:root> #systemctl status sshd
sshd.service – OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Thu 2016-02-18 14:05:44 GMT; 32min ago
Main PID: 923 (sshd)
CGroup: /system.slice/sshd.service
+-923 /usr/sbin/sshd -D
Feb 18 14:05:44 ip-10-51-72-53 systemd[1]: Started OpenSSH server daemon.
Feb 18 14:05:44 ip-10-51-72-53 sshd[923]: Server listening on port 22.
Feb 18 14:05:44 ip-10-51-72-53 sshd[923]: Server listening on :: port 22.
Feb 18 14:16:20 ip-10-51-72-53 sshd[2039]: Accepted password for tony from port 36403 ssh2
Feb 18 14:28:46 ip-10-51-72-53 sshd[2111]: Accepted password for tony from port 37930 ssh2

This one command tells you everything you need to know about the sshd process including the last 5 log entries. I think that’s cool and it fits in well with the lazy system administrator philosophy .

By default journald saves the latest log entries in the non persistent /run/log/journal. It can be configured to either replace rsyslog by enabling persistent mode (done by  creating directory /var/log/journal) or work in tandem. Whether you want to replace rsyslogd depends on whether you need to send log entries across the network to a remote syslog server. Currently journald can’t do this so you’ll need rsyslogd. The default configuration in RedHat 7 is for journald to pass the messages to rsyslogd. The journalctl command can be used to display messages from journald. Some useful journalctl options can be found in the new features of RHEL 7 wiki article previously mentioned.

That’s it for part 1. Look out for part 2 coming soon in which we’ll take a look at yet more new features in RedHat EL 7.


Leave a Reply