It's Time To Pack Up And How To Use Systemd

By

Systemd is a system and service manager for Linux operating systems. When run as the first process on boot (as PID 1), it acts as an init system that brings up and maintains userspace services.

It has mostly replaced the previous standard for Linux distributions. It is widely used and therefore being acquainted with systemd is definitely worth the effort. It will also make server administration much easier. Learning about and utilising the systemd tools and daemons can help you realise the power, flexibility, and possibilities it offers, or at the very least make your work easier.

For our server, we will be using a Raspberry Pi 4. This will enable us to test the prowess of systemd.


To setup Raspberry pi for headless support please refer to this Toms Hardware tutorial

Why systemd

The most common criticism levelled about systemd is that it suffers from mission creep and bloat. Subsequent criticism impacts other software that adds systemd dependencies, affecting compatibility with other Unix-like operating systems and making it difficult to shift away from systemd. Concerns have also been expressed regarding Red Hat and its parent firm, IBM, dominating the scene of Linux init systems. Some even question systemd's integrity against attackers, stating that its complexity leads to a vastly expanded attack surface, lowering the platform's overall security.

Systemd, on the other hand, has been lauded by developers and users of distributions who have embraced it for delivering a stable, easier bootup time - a quick out-of-the-box solution to issues that have plagued the Linux community for years. Systemd was the only software suite that enabled dependable parallelism at boot as well as centralised control of processes, daemons, services, and mount points when it was first adopted by most Linux distributions.

"Why systemd?" is a classical question where developers are split down the middle and picking up an argument about it will not last just like the distro's war. But as system developers, you have to ensure that you learn how to work with systemd as it is the majority init system in most Linux servers. You'll definitely have more consistent administration across the Linux distro.

Reading systemd configuration files is easier than reading plain text. This is one of the key benefits of systemd. We will demonstrate this using a sample configuration file later in this blog.

Go and check out the audit service that helps system administrators check on their system and better understand the system security as it logs the activity of users in this case a hacker. 


Why not

- Desktop users

- Server! You'll not have a choice


Demo

Here at the Nakuja project, we are building a logger for our static test and also base station for the actual flight test.


Our backend system is mainly of docker services managed with systemd. At first, we want to read serial data when we plug in the USB cable from which we will be streaming out data. The read serial should be initiated after the backend docker services are up and also when the user triggers start logging from our web dashboard.

First, we will be writing a python service that reads data from a serial port. 

What does our main file do?


Most versions of Linux have systemd out of the box, and  if yours does not, just execute the following command to get it:

Simply execute the following command to determine the version of systemd you have:


Service file

Service units, which have unit files ending in .service, will be the target unit for service management operations. However, for most service management tasks, you may omit the .service suffix since systemd is sophisticated enough to recognise that you are most likely attempting to operate on a service when using service management commands.


- [Unit] - provides general options that are not reliant on the unit's kind.

Available unit types

1. Service unit `.service` - A system service.

2. Target unit `.target` - A group of systemd units.

3. Device unit `.device` - A device file recognized by the kernel.

4. Socket unit `.socket` - An inter-process communication socket.


- [unit type] - If a unit has type-specific directives, they are organised in a section titled after the unit type.

- [Service] section, for example, can be found in service unit files.

- [Description] - A concise description of the unit. This text appears in the output of the systemctl status command, for example.

- [After] - Determines the sequence in which units are launched. Only once the units stated in After and are active does the unit begin. In contrast to Requires, After does not explicitly activate the units given. The functionality of the Before option is the inverse of that of the After option.

- [Requires] - Sets the unit's dependencies on other units. The units specified in Requires are activated at the same time as the unit. The unit is not activated if any of the prerequisite units fail to start.

- [Type] - Configures the unit process startup type, which impacts ExecStart's functionality and associated settings. e.g Simple – The default value. 

- [ExecStart] - Specifies the instructions or scripts that will be run when the device is powered on.

- [ExecStop] - Specifies which instructions or scripts should be run when the unit is turned off.

- [ExecReload] - Specifies commands or scripts to be executed when the unit is reloaded.

- [Install] — includes information about the unit installation that is used by the systemctl enable and disable commands

- [WantedBy] A list of units that are only slightly dependent on the unit.


For more information check out the reference materials, especially RedHat documentation

The restart flag is set to always because I want my service to restart if the server is rebooted. You may find out more about this by clicking on this link. We must now reload the daemon.


Use the start command to start a systemd service by executing the instructions in the service's unit file.


As previously stated, systemd understands to check for `.service` files when looking for service management commands, therefore the command might be worded as follows:


Our service is now operational. To stop an already operating service, use the stop command instead:


You may use the restart command to restart a running service:


You must enable them to inform systemd to start services automatically at boot. Use the enable command to start a service at boot:


This will build a symbolic link from the system's copy of the service file (often located in /lib/systemd/system or /etc/systemd/system) to the location on disc where systemd looks for autostart files (usually /etc/systemd/system/some_target.target.wants).

To disable the service from starting automatically


This will delete the symbolic link indicating that the service should start automatically. Remember that activating a service does not initiate it in the current session. If you want to start the service as well as activate it at boot, you must use both the start and enable commands. You may use the status command to verify the status of a service on your system:

This will show you the service status, the cgroup hierarchy, and the first few lines of log data. When checking the status of an Nginx server, for example, you could see something like this:


All these operations are managed by a makefile


So we have started the application

make start_read_serial

also to stop the service you 

make stop_read_serial

If you want to watch the logs streaming from the service you can use

make logs_read_serial


For more information check out our Github Repository


References

1. http://0pointer.de/public/systemd-man/systemd.html

2. https://www.linuxvoice.com/linux-101-get-the-most-out-of-systemd/

3. https://www.cvedetails.com/vulnerability-list/vendor_id-7971/product_id-38088/Freedesktop-Systemd.html

4. https://wiki.debian.org/Debate/initsystem/systemd

5. https://fedoraproject.org/wiki/F15_one_page_release_notes

6. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/chap-managing_services_with_systemd

7. https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files

8. https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units

Comments

Post a Comment

Popular posts from this blog

USING NEO-6M GPS MODULE AND INTERFACING IT WITH ESP32

By
Image
  This tutorial will cover NEO-6M GPS Module and how to interface it with ESP32. 1.1 The NEO-6M GPS module The NEO-6M GPS module is a type of GPS receiver that utilizes the u-blox 6 positioning engine to provide location and timing information. Many GPS-based projects, including tracking gadgets and navigation systems, frequently employ this module. It supports the GPS, GLONASS, Galileo, and QZSS satellite systems and has a very sensitive receiver that can track satellites in difficult terrain. The module is a popular option for a variety of applications due to its small form size, compact form factor, low power consumption, and multiple communication interfaces. NEO-6M GPS module can track 22 satellites and identify locations anywhere in the world. Some of its specifications are: ·        GPS chipset: u-blox NEO-6M ·        GPS module frequency: L1, 1575.42 MHz ·        C/A c...
Read more

PCB ETCHING PROCESS

By
Image
 Are you tired of having to use a bread board for your projects? Do you get tired of all the wires that you use and the hustle of remembering which wire goes to which hole on the bread board😕? Well look no further, you are in the right place😌. This is a simple guide to being able to design and fabricate your own PCB at home for either a personal project of a school project. At the Nakuja project we design our PCB's for avionics and flight control systems using design software such as EasyEDA, print the designs, etch the PCB and do our own soldering of the components onto the PCB.  This blog is designed to give you a step by step guide of the etching process. I hope you enjoy making your PCB!! Materials required Board design (after using EasyEDA, Eagle, etc. to design it) clothes iron copper clad board sand paper cupric chloride water plastic dish or basin PCB drill soldering iron solder wire NOTE: the etching solution is CORROSIVE and toxic hence should be handled with care...
Read more

Second Test Flight Report

By
Image
Avionics report As we are the brains of the rocket we have some tasks we want to achieve at the end of each launch: - Log flight data - Transmit flight data - Check for apogee - Fire parachute - Build the flight computer 1. Log flight data We were not able to equip the rocket with an SD card is it was throwing some errors just before flight. We had tested it and it worked previously. So we didn't want to take more time debugging the problem as we had a backup for that. If we could be able to transmit the data well and good. As we would be able to log the data on the ground station. Recommendations - Test the SD card and make sure it is working prior to launch - Figure out a way to write to the internal flash system of the rocket 2. Transmit flight data We were able to transmit flight data from the rocket to the ground station. We used the Lora module and we were able to send a packet back to the base station Recommendations - Beef up the base station as to not rely on Putty and bor...
Read more