Custom solutions for system monitoring and control

Reacting to Logins

From these building blocks, you can create small scripts with easy tools that respond to events on your system. For example, you can quite easily use logins to trigger actions – for example, to avoid discussions with the kids every evening if they have been sitting in front of the computer too long. When the bell tolls, you can then log them off the system automatically whether they are happy with it or not.

The script in Listing 8 relies on users to discover the users currently logged on to the system and then on grep to filter the output. This gives you an exit code of   in case of a match and of 1 in case of a miss. Based on the results, and the current time (assuming the hours between 21:00 and 07:00 are off limits), the script then allows user simon to use the system or throws him out without so much as a by your leave (Figure 4).

Listing 8

Automatic Logoff

01 #! /bin/sh
02 while true; do
03   # Discover the time
04   TIMENOW=$(date +%H)
05   # Is Simon logged on?
06   users | grep -q simon
07   # Evaluate exit code
08   A=$?
09   if [ $A -eq 0 ]; then
10     # Simon is logged on
11     if [ $TIMENOW -le 7 ]  || [ $TIMENOW -ge 21 ]; then
12     # before 07:00 or after 21:00 hours
13       killall -u simon
14     fi
15   fi
16   sleep 60
17 done
Figure 4: Automatically logging off the user if they exceed their time window.

The principle can also be applied to convenience and automation functions. For example, with a slightly modified script (Listing 9) you can launch a web server as soon as a specific user (jefe in this example) logs on. In this case, the script is designed for use with a systemd computer; you might also need to change the name for the web server service (in this example, httpd.service).

Listing 9

Launching a Web Server Conditionally

01 #! /bin/sh
02 while true; do
03   # Is jefe logged on?
04   users | grep -q jefe
05   # Evaluate exit code
06   A=$?
07   if [ $A -eq 0 ]; then
08     # jefe logged on
09     # Check status of web server
10     systemctl status httpd.service
11     # Evaluate exit code
12     B=$?
13     # Start web server if needed
14     if [ $B -gt 0 ]; then
15       systemctl start httpd.service
16     fi
17   else
18     # jefe not logged on
19     # Check status of web server
20     systemctl status httpd.service
21     # Evaluate exit code
22     C=$?
23     if [ $C -eq 0 ]; then
24       # Stop web server if needed
25       systemctl stop httpd.service
26     fi
27   fi
28   sleep 60
29 done

The user does not need to enter any commands or initiate any actions, and you don't even need to make any changes to home directories or user accounts. For example, in ~/.profile or ~/.bashrc), all you need is an active session. This approach lets you assign important tasks, such as starting a service or a backup, to a non-privileged user account. Of course, you need to call the shell script automatically when the computer boots. The approach is different, depending on the init system.

As a general rule, you would want to store the executable shell script in the /usr/local/sbin directory. For older systems, such as Debian 7 with SysVinit, you would typically copy the skeleton template, which is already in place on most systems, to a new file with an appropriate name below /etc/init.d (this example uses weblogon). Next, edit the init script to suit your needs, save the changes, and make the file executable by running chmod +x. To enable the script for the typical runlevel, enter:

update-rc.d weblogon defaults

If you work on a computer with systemd, you need to create a new unit file named weblogon.service, as shown in Listing 10, under the /usr/local/lib/systemd/system directory, which you might have to create, and run the code in Listing 11 to link the instructions with the system and ensure an automatic start at bootup.

Listing 10


Description=Start web server when jefe logs on

Listing 11

Setting Up Autostart at Bootup

$ sudo systemctl enable weblogon.service
Created symlink from /etc/systemd/system/
  wants/weblogon.service to /usr/local/lib/systemd/system/weblogon.service.
$ sudo systemctl start weblogon.service
$ sudo systemctl status weblogon.service
* weblogon.service - Start web server when jefe logs on
   Loaded: loaded (/usr/local/lib/systemd/system/weblogon.
           service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2015-10-27 14:16:13 CET; 6s ago

Messages via Email

Optionally, you can also tell your computer to notify you by email in case of important events. To do so, you need a mail transport agent (MTA), such as SSMTP [1] on your computer. The agent forwards email via a regular SMTP server so that the server mail is not discarded automatically as spam by the receiving email service.

Listing 12 shows a simple shell script that notifies you of all users still logged on to the computer after 22:00 hours. To handle this task, the script creates a helper file named mail.txt, which ssmtp then uses as input for the email to be sent.

Listing 12

User Notification

01 #!/bin/sh
04 while true; do
05   timenow=$(date +%H)
06   if [ $timenow -eq 22 ]; then
07     echo "To: $RECEIVERADDRESS" > mail.txt
08     echo "From: $SENDERADDRESS" >> mail.txt
09     echo "Subject: User query" >> mail.txt
10     echo "" >> mail.txt
11     users >> mail.txt
12     ssmtp $RECEIVERADDRESS < mail.txt
13     sleep 15
14     #sleep 3600
15   fi
16 done

Before starting the script, you first need to set up SSMTP. To do so, use the configuration files ssmtp.conf (Listing 13) and revaliases (Listing 14) from the /etc/ssmtp directory. Depending on which email provider you want to address, you need to enter different configuration details at this point. If you are having difficulty finding the right information, searching the Internet with <Provider> ssmtp will typically help.

Listing 13

AuthUser=<Login for SMTP Server>
AuthPass=<Password for SMTP Server>

Listing 14


The examples in the configuration files are applicable for a normal FreeMail provider. For test purposes, you can run ssmtp in the shell script with the -v option. The program is then far more verbose, allowing you to discover problems with the transmission more quickly and make the necessary changes.

Make sure that only root, or the user in whose context SSMTP runs, can see the SSMTP configuration file. Check the documentation of your Linux distribution for instructions on doing this (e.g., for Arch Linux [2]).


The examples shown here only cover a fraction of the possibilities that shell scripts offer for system monitoring. To create scripts, you do not need advanced programming capabilities; experience with terminal applications and simple constructs such as while loops and if statements are typically sufficient.

The Author

Harald Zisler has focused on FreeBSD and Linux since the early 1990s. He is the author of various articles and books on technology and IT topics. The third edition of his book Computer-Netzwerke (Computer Networks) was recently published by the Rheinwerk Verlag publishing company. He also works as an instructor, teaching Linux and database topics in small groups.

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

  • Charly's Column

    HTTPing may be the perfect tool to check on the health of your web server.

  • systemd Tips

    Sure, you've heard about systemd, which is rapidly replacing the old System V init system as the go-to service management daemon for the Linux world. But what can you do with systemd really? We'll show you some tricks for improving security, managing processes, and analyzing boot times with systemd.

  • Linux Dash and Cockpit

    Linux Dash and Cockpit are small-scale solutions for monitoring a cloud-hosted virtual server from home.

  • Nagios Traffic Light

    A clever combination of Nagios and a doityourself traffic lights lets you know how your network is feeling.

  • Monitoring with incron

    The incron utility provides an easy way to initiate commands and scripts triggered by filesystem events.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More