systemd: getty-like service for htop

htop is an interactive program for monitoring processes; she is an alternative to top. Everyone who works behind a Linux machine on board has used it at least once: be it a search for the process (and its subsequent killing) or careful monitoring of the resources used.

For convenience, this program can be kept always running: in a separate terminal window, in its tabs, or on some desktop. But there is another solution: to run it on a fixed VT, which you can switch to at any time. The advantage of this approach is the clean environment and independence from X / Terminal.

This is possible (and right) to do with the initialization system, because we actually want to get a special getty-like service for htop.

How do VT1, ..., VT6 run?

agetty is a program that opens the tty port, issues a prompt for authentication and transfers the subsequent control to another program - login .

 $ which agetty login | xargs ls -l -rwxr-xr-x 1 root root 44104 Sep 29 05:21 /usr/bin/agetty -rwxr-xr-x 1 root root 35968 Sep 29 05:21 /usr/bin/login 

Traditional Linux init systems are configured to start a fixed amount of agetty on boot. In most cases, six instances are generated for six VTs: from tty1 to tty6, respectively. Systemd takes a different approach.

• The first is dynamic . The getty@.service .service service getty@.service runs on demand. That is, only if we need some specific VT. For this, logind is responsible, which, when switching to ttyN, starts the autovt@ttyN.service service, which is a symlink to getty@.service . This logic works for tty2-tty6.
• The second is static . The specific instance of the getty@.service is automatically pulled in via getty.target , which gives us always running getty on tty1.

systemctl cat getty@.service will show the contents of this service. We are not going to examine it in detail, because it is not so important for us.

Accordingly, if we assume that we have a certain htop@.service , then we can add it to autoload in two ways: either make a symlink under the name autovt@ttyN.service - then when switching to the selected VT, htop will start instead of getty, or disable getty@ttyN.service and enable htop@ttyN.service instead of it - it always gives us running htop on a fixed VT.

Write your own getty-like unit

Now go to /etc/systemd/system - one of the directories where the units are located - and create your own service:

 $ "$EDITOR" htop@.service 

The presence of the suffix ( @ ) means that it is not the service itself that starts, but one of its instances. And the suffix is ​​passed to it by the parameter ( %i and %I ).

It has already been noted above that the contents of getty@.service is not so important for us. All so, because it can be stuck in our service:

 .include /usr/lib/systemd/system/getty@.service 

If we consider that our service is getty-like, then this construction saves us from unnecessary copying of the code.

Unit Section

It describes the general parameters applicable to any type of unit.

 [Unit] Description=htop on %I Documentation=man:htop(1) 

Everything here is transparent: the Description directive sets a brief description of the unit, and Documentation path to the documentation. %I is the instance name. It is important to note that the two variables that specify the instance name are different in meaning: %I is the same as %i , but it does not escape the escape sequences.

Service Section

This section sets the configuration of a specific service. In other words, describes how to start the process.

 [Service] Environment= Environment=TERM=linux HOME=/root ExecStart= ExecStart=/usr/bin/htop StandardInput=tty-fail StandardOutput=tty 

We will leave the necessary inherited values ​​of directives alone, and some we need to reset (we set an empty value for them) and define it ourselves. These include Environment - setting variables, and ExecStart , - actually, starting the process.

 StandardInput=tty-fail StandardOutput=tty 

- this is an indication by systemd to run htop connected directly to the terminal.

You can, by the way, add not an instant launch, but with waiting for input. To do this, create a simple script on the bash:

 #!/bin/bash echo "Press a key to launch $(basename "$1")" read exec "$@" 

All he does is wait for input and start some program (which will be htop in our case). Place it anywhere, call it whatever you want, make it executable ( chmod +x ) and rule ExecStart in our service:

 ExecStart=/etc/systemd/scripts/run_wait /usr/bin/htop 

Restrict rights

If you need to impose any restrictions on the rights, then do it, of course, necessary. To do this, we will create another service and another script, now - htop_secure@.service and run_wait_su . We reconfigure them so that htop runs with the rights of a specific user and a specific group, and also requires an administrator password.

So, create a new service and a new script based on the two previous ones:

 $ cd /etc/systemd $ cp system/htop@.service system/htop_secure@.service $ cp scripts/run_wait scripts/run_wait_su 

And edit each of them. For the service in the Service section, change the Environment value and set the name of the user with his group:

 User=kalterfive Group=users Environment=TERM=linux 

And in the script, we refer to su(1) :

 #!/bin/bash echo "Press a key to launch $(basename "$1")" read exec su -c "$@" 

Service installation

Now our service is ready, it remains only to add it to the autoload:

 $ systemctl daemon-reload $ systemctl disable getty@tty2.service $ systemctl enable htop@tty2.service 

The first command updates the systemd configuration manager, and the second creates a symlink to our service in getty.target.wants .

Conclusion

Now reboot (or manually kill getty@ and turn on htop@ for the tty2 instance), switch to the second VT and see the successfully launched htop. The demonstrated trick touches only a small part of systemd, as the initialization system, from the whole scope of its capabilities, as a universal plumbing layer — a set of programs for solving completely different tasks. Successes!