Page Comparison

Key Points

...

alias. dothis='my cmd string eg ls -Al ./"my folder" ' 

unalias x

trap commands - similar to monmsg

https://linuxhandbook.com/bash-trap-command/?ref=lhb-linux-digest-newsletter

bash script to send a signal when user interrupts a sleep function in the script

#!/usr/bin/env bash

function sig_int() {
    echo "The sleep was disturbed by Jarasandha"
}

trap sig_int SIGINT

sleep 10m

It is listening for the SIGINT signal and upon receiving it, it will call the sig_int function.

Let's try this!

$ ./trap-script.sh
^CThe sleep was disturbed by Jarasandha

As soon as I pressed the Ctrl + C key (as evident by ^C), the echo statement inside the body of the sig_int function was called.

Sending other signals

SIGINT is not the only signal that you might want to monitor for. Therefore, you may want to verify whether your script is correctly listening for intended signals. In that case, you can send a signal externally using the kill command.

Following is the syntax for this particular use:

kill -s SIGNAL PID

As it might be obvious now, use the -s option to specify which signal you intend to send. Then, specify the PID of the program to which you want to send the signal.

I will make a slight modification to the way I execute this script... I will run it in the background so I can use the same shell to run the kill command to send the signal.

$ ./trap-script.sh &
[1] 28550

$ kill -s SIGINT 28551

$ The sleep was disturbed by Jarasandha

[1]  + exit 130   ./trap-script.sh

Look closely. The PID of the script that was put in the background is 28550 but I am sending SIGINT to the shell script's PID + 1 PID (28551). The reason is that the active process is the sleep command which is running inside our bash script ;)

You are actually monitoring the signals for the commands running inside the script. Not the script itself.

Creating a system service with systemd

https://linuxhandbook.com/create-systemd-services/?ref=lhb-linux-digest-newsletter

a service is a "background process" that is started or stopped based on certain circumstances. You are not required to manually start and/or stop it. A 'systemd service file' is a file that is written in a format such that systemd is able to parse and understand it, and later on do what you told it to do.

The systemd service file has three important and necessary sections. They are [Unit], [Service] and [Install] sections. The systemd service file's extension is .service and we use the pound/hash symbol (#) for single line comments.

Below is an example of a systemd service file. Please note that this is NOT an actual systemd service file. I have modified it so that it helps you understand.

[Unit]
Description=Apache web server
After=network.target
Before=nextcloud-web.service

[Service]
ExecStart=/usr/local/apache2/bin/httpd -D FOREGROUND -k start
ExecReload=/usr/local/apache2/bin/httpd -k graceful
Type=notify
Restart=always


[Install]
WantedBy=default.target
RequiredBy=network.target

This is the most basic structure of a systemd service file. Let us understand what each of these words mean.

Example - Systemd service for root user

I have written a script, that I want to run at the time of system boot, as the root user. The script is called sys-update.sh, and it's absolute file path is /root/.scripts/sys-update.sh; Below is the script:

#!/usr/bin/env bash

if [ ${EUID} -ne 0 ]
then
	exit 1 # this is meant to be run as root
fi

apt-get update 1>/dev/null 2>>/root/logs/sys-update.log

Let us first understand what this script does. First, it will check if the user is root or not. If the user is the root user, then the apt-get update command will be executed. Any errors from the output of that command will be appended to the /root/logs/sys-update.log file. And any additional output will be redirected to the /dev/null file.

Usually, it is considered a good practice to put these systemd service files inside the /etc/systemd/system/ directory.

Therefore, I will create a file update-on-boot.service; its full path being /etc/systemd/system/update-on-boot.service. Below are the contents of this service file:

[Unit]
Description=Keeping my sources fresher than Arch Linux
After=multi-user.target

[Service]
ExecStart=/usr/bin/bash /root/.scripts/sys-update.sh
Type=simple

[Install]
WantedBy=multi-user.target

This is a very simple systemd service file. All it does is use the bash interpreter to interpret the /root/.script/sys-update.sh script and execute it.

Enabling the service

Now that the systemd service file is ready and placed under the /etc/systemd/system/ directory, let us look at how to enable it.

To tell systemd to read our service file, we need to issue the following command:

sudo systemctl daemon-reload

Doing so will make systemd aware of our newly created systemd service file.

Now, we can enable our systemd service. 

In our case, the service is named update-on-boot.service, so I will run the following command:

sudo systemctl enable update-on-boot.service

Below is the output of checking the status of the service:

$ sudo systemctl is-enabled update-on-boot.service
enabled

Systemctl Status Command to Check Service Status

https://linuxhandbook.com/systemctl-check-service-status/?ref=lhb-linux-digest-newsletter

systemctl status <service-name>

you can always list systemd services and get the name.

Status

• active (running): Service is actively running in the background.
• active (exited): Indicates the service was meant to be executed one time or periodically. So the service did its job and then exit upon completion.
• active (waiting): It indicates the service is running but it is waiting to be triggered by some condition like a specific event.
• inactive: Service is not currently running.
• enabled: Service will be enabled at system boot time.
• disabled: Service is disabled and won't be started at system boot.
• static: It means the specific service can't be managed using systemd (or the systemctl command) and you'd need to have another init service or manage it manually.
• masked: This means the service is masked and can't be stated directly using the systemctl command. This can be helpful when you want to prevent accidental starting of service.
• alias: It indicates the service name is an alias and the service is a symlink pointing to another unit file.
• linked: It indicates that the service or the unit file is symbolically linked to another unit file.

sudo systemctl start | stop <service_name>

sudo systemctl enable | disable <service_name>

Windows Gitbash shell

Windows 10 offers download of Gitbash

...