sysmond is a daemon program that periodically (by default once a second)
reads system status.  It listens on a UDP port (default 12686) and
when it receives a message, returns its current readings.

The program is written in C to minimize execution time and size.
Since the program runs periodically (once a second by default), it
only takes about 2 milliseconds on one core for each cycle. Its 
only dependency is glibc.

One purpose of the program is to demonstrate some moderately advanced
techniques in a Linux environment.  It demonstrates the following:

- Parsing command line options
- Parsing a configuration file
- Reading from the /proc file system
- Reading from the /sys file system
- Using UDP (IPv4 and IPv6) to receive requests and to reply to the sender
- Locking a file to prevent running multiple instances
- Using the fork() system call
- Creating a thread 
- Handling signals
- Raising process priority
- Attaching a process affinity to a CPU core
- Using a mutex (mutual exclusion lock)

When the Linux kernel runs, it frequently updates files in the /proc
and /sys virtual file systems.  For the purpose of this program we
read:
/proc/loadavg
/proc/uptime
/proc/stat
/proc/meminfo
/sys/class/hwmon/hwmon<number>
  name  (interface name)
  temp<number>_label (sensor name)
  temp<number>_input (sensor value)

The program starts by parsing the command line and configuration file.
It then:

1. Blocks the signals it handles (SIGTERM, SIGINT, SIGHUP, SIGUSR1)
   so they are only received by the main loop
2. Creates and binds the UDP socket (IPv6 and IPv4)
   - Errors are still reported to the terminal at this point
3. Opens and locks the PID file
   - If another instance holds the lock, it is already running,
     so terminate
4. Forks the process
   - The original process:
     - Writes the PID of the forked process to /run/sysmond.pid
     - Terminates successfully
   - The forked process:
     - Starts a new session, detaching from the terminal
     - Changes to the / directory
     - Points stdin, stdout, and stderr at /dev/null
     - Raises its priority and attaches itself to CPU 1
     - Creates a separate thread (on CPU 0) to handle UDP input
       and output
     - Runs an infinite loop reading system data and waiting for
       a signal or the next scan

The lock on the PID file is released automatically when the process
exits, even after a crash, so a leftover PID file does not prevent a
restart.

The scanning process alternates writing its output to two different
locations, active and inactive. It writes to the inactive string and
then makes it active.

The UDP thread waits for UDP input (but ignores the content) and then
immediately responds by sending the active string to the sender.
To prevent abuse, a request must be at least 1024 bytes long, and each
source address gets at most one reply every 900 milliseconds.  The length of
the output depends on the number of temperature sensing devices and the number
of sensors on each device. Typically the length is in the range of 500 to 600
bytes.

The format of the output is as follows:

<hostname>;time:<time string>;uptime:<in seconds>;load:<three values>;cpu%:<0.00-1.00>;mem%:<0-100>

For each sensor device:
interface;<device name>,<sensor name>:<value>,[<sensor name>:<value>...]

These values are used by the client, sysmon3, for display.

Note:  
  The temperature values in /sys/class/hwmon are written by kernel drivers.
  These may be built into the kernel or built as modules, but must be selected
  when configuring the kernel. To help decide which drivers are needed for
  a specific system, the lm-sensors package has a program, sensors-detect, 
  that can be used. This program is a Perl script that walks through the 
  process of scanning a system for various hardware monitoring chips (sensors).


