Graphical interfaces for systemd


The Cockpit project [2] primarily concerns server management, but, thanks to the close combination with systemd, also provides the option to administer the session manager on the target system. The current version is 126 – apparently the developers no longer use the major number before it.

Red Hat maintains and further develops the software, and systemd is a mandatory requirement. Prebuilt packages and repositories are available for Fedora Server, CentOS, Red Hat Enterprise Linux, and RHEL Atomic. The application can be found in separate repositories for Debian and Ubuntu, while Arch Linux has unofficial support [14]. Additionally, the developers make the source code of the software available under LGPL on GitHub [15].

False Start

A shortcoming initially stood out during the test installation with the current Cockpit version 126: Unfortunately, the project developers failed to explain the exact specifications for using Cockpit with Ubuntu. If users want to install the program using the official archive in Ubuntu 16.10, the existing PPA archive does not integrate into the system because it is intended for Ubuntu 16.04. Installation on the slightly older Ubuntu version (which is, however, provided with long-term support) works easily using the three steps in Listing 1.

Listing 1

Install Cockpit in Ubuntu 16.04


In the end, the user starts the systemd-socket, which, using

sudo systemctl enable --now cockpit.socket

is no problem. The software is now ready for use, and its interface appears in the web browser of your intranet if you type https://<Server-IP-Address>:9090 into the address bar. With the exception of the installation on the server itself, Cockpit only uses a connection secured with SSL/TLS, whereby it creates a self-signed certificate when first started.

If no connection is established, this is probably due to a blockade of port 9090 via the firewall, and you'll need to unlock the port – Fedora Server does this innately by the way.

The Cockpit dashboard then appears with the login screen in the browser. The admin is authenticated and thus moves into the home screen. On the left are selection lists for various tasks, and the corresponding content appears in a large area on the right (Figure 11). To configure and manage systemd processes on the server, select Services on the left of the selection area. The software lists the existing processes and services in a table, whereby Cockpit initially considers all types, even the inactive ones.

Figure 11: Red Hat's Cockpit provides a clear dashboard.

The Cockpit user further manages servers that can be found on the intranet by clicking Dashboard at the top of the main window and using the + button in the vertical center of the window. The server can now be integrated into Cockpit via its IP address. The management software then logs in with the user's authentication information with the new server and collects the necessary information from it. The server then appears under its IP address in the list of server systems waiting at the bottom of the window. Here, the user can call up the performance data of one of the servers via mouse click.

The user can also access the systemd units here via the Services menu item on the left of the dashboard – depending on the device. Cockpit divides the list into the categories Enabled, Disabled, and Static, which serves as an overview. At the top of the list view are the Targets, System Services, Sockets, Timers, and Paths buttons, from which you can very quickly identify individual units (Figure 12).

Figure 12: Cockpit displays all units in three-column tables.

Regardless of a unit's operating status, after clicking on a unit, the user ends up on the unit in a log window, which displays the respective unit's log. This saves tediously searching for individual log entries in the journal.


To manage processes and daemons in Cockpit, you need to register the software with administrator rights beforehand. You can start new processes from the dashboard in a terminal with Tools | Terminal. Alternatively, you can select the desired unit from a list with the mouse. You will then see the unit's log entries and other information, including the path.

Two selection fields on the right provide various functions via mouse click: Here the administrator can enable, disabled, or reload systemd units. These also allow a unit to be force started. The user can also modify the configuration file via the integrated terminal. In all, it's very easy to manage systemd processes using Cockpit (Figure 13).

Figure 13: The Cockpit user can reload or disable units in the journal window.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Systemd GUIs

    Graphical frontends make it easier to take full advantage of the Systemd process manager. We examine some leading tools for the KDE environment.

  • Command Line: Systemd

    Wondering what all the fuss is about systemd? We explain the basic concepts and capabilities of the new system management suite – coming soon to a distro near you.

  • Professor Knopper's Lab – Removing systemd

    The systemd service manager has been widely adopted by many Linux distros, so why would you want to remove it? The professor reveals why and how.

  • Systemd Units

    Systemd units use files to control resources that Systemd manages.

  • Systemd Flatpak Updates

    You can automate Flatpak updates without a package manager using systemd's services and timers.

comments powered by Disqus