nohup & systemd

To be honest, there won't be any need of such comparison if system admins did their research and understand fundamentals of a Linux based OS well, but recently via some of my peers I have come to across scenarios where experienced Linux Admins have been running background processes with nohup in production, and not even having slightest idea of harnessing the capabilities of systemd service unit.

Sadly it has come to this that the sysadmins of cloud era have been boasting their knowledge of cloud services but lacking the fundamental understanding of Linux, and how operating systems function. All due to fast paced learning and FOMO, they have been missing out important aspects of running servers and maintaining them reliably. Another factor recently observed is heavy reliance on AI tools to seek quick answers. With that said lets being with actually discussing the title.

What is nohup?

As the definition on Wikipedia says, nohup is a POSIX command which means "no hang up". Its purpose is to execute a command such that it ignores the HUP (hangup) signal and therefore does not stop when the user logs out.

It is usually helpful for admins to run ad-hoc background tasks across SSH sessions, or on their workstations, so that they don't have to worry about exiting the process upon accidental termination of sessions. ad-hoc background tasks are usually once in a while jobs that won't be repeated and don't require any availability or reliability, nohup only helps admins to run such tasks in background for time being to increase their productivity and perform many such tasks in parallel which don't require constant monitoring.

Some examples of such tasks are:

• syncing a large filesystem, object storages

• one off database migrations

• debugging services

• temporary webhooks

$ nohup s3 sync s3://large-bucket-old s3://large-bucket-new &
$ exit

What is systemd?

As the definition on Wikipedia says, systemd is a software suite that provides an array of system components for Linux operating systems. Its main aim is to unify service configuration and behavior across Linux distributions; Its primary component is a "system and service manager"—an init system used to bootstrap user space and manage user processes.

systemd has been integral part of many linux distributions as in init system and is at the root of process management that serves user experience for server and desktop users. Its a daemon that manages other daemons.

In multitasking computer operating systems, a daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user.

Using systemd you can not only configure your applications services as daemon processes, but also configure the sequence they start up, you can define dependencies, on other processes e.g an app process starting up after database.

Along with dependency on other systemd managed processes you can also define target you want your process to start into.

systemd targets are different states that your system can boot into, comparable to System V runlevels.

Systemd Unit file for nginx webserver.

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

The common configuration items are configured in the generic [Unit] and [Install] sections.

complete list of options available can be found in systemd man pages, by running man systemd.unit and man systemd.install respectively

The service specific configuration options are configured in the [Service] section.

Complete list of Service section options can be found by running man systemd.service

If you have observed almost any standard service you install on a linux server configures a systemd service unit file, because its the standard way of doing it. Though all of it is scripted and packaged to be installed by your package manager most of the time and you don't have to configure it yourself , it doesn't mean that you can't configure systemd for your own application services. You can use it to run your web apps built in java, python, nodejs etc. Anything you want to be running in background and orchestrate its start-up across system reboots, systemd is best way to do that.

Closing Note:

Although we have been talking about systemd all this time, its not only init system out there but a popular and default for many OSes, and what you can achieve with systemd can be achieved with other init systems also. Some of these are SysV, openrc, upstart etc.

Conclusion:

nohup, although being a quick and easy way to run background task, is ineffective for long running services in production, such as databases, application servers, webservers, etc, while systemd is at core of process management in multitasking linux operating systems and preferable way to run apps and web servers as daemon processes in Linux, in production.

References:

• https://documentation.suse.com/smart/systems-management/html/reference-managing-systemd-targets-systemctl/index.html

• https://www.shellhacks.com/systemd-service-file-example/

• https://www.slant.co/topics/4663/~linux-init-systems