Day 14 : 21 June 2022 : Running Ava as a Service on Linux

 My 100 Daze of Code

https://github.com/davidjwalling/100-days-of-code

#14 : Running Ava as a Service on Linux

Now that we have Ava running as a service on Windows, we can set up Ava to run as a background task, or "daemon", on Linux. We'll add code in Driver to handle the "service" program argument just as we did on Windows. Only for Linux, we'll fork the process, set up handlers to termination signals and close standard streams.

Once this code is tested, we can setup Ava to be started automatically by systemd by defining a service configuration file (ava.conf).

Installing Ava as a Daemon on Linux

The ava.service file is new and defines characteristics of the ava service.  This file is copied into the /lib/systemd/system/ folder. The executable will fork its process on startup. The initial program arguments passed include the "service" parameter. When systemd stops the service, it will issue a simple "kill" command on the main process ID. This corresponds to the SIGTERM signal, which the Ava library will now capture and exit Mainline. The /var/opt/ava folder is defined to be the current working directory (cwd) for the service. Log file output will be stored there.

The ava.conf file is stored in the /etc/modules-load.d/ folder. This file simply contains a list of services to start at startup.


The installation commands for these files and the program artifacts are shown here. Note that we install Ava and its library in different folders than our cmake installer does. This is so that we can stop a "production" version of the service running in /usr/bin, compile and install a test version in /usr/local/bin, and then promote the tested code manually. In this way, "sudo make install" will never overwrite a working production service copy.

Using systemctl to Start and Stop the Service

Here we start the ava service, stop the ava service, check the service status and then inspect the log file written to /var/opt/ava.


The logging output in /var/opt/ava indicates that the Termination signal (SIGTERM) was observed by the program when systemctl stopped the service. We see in the systemctl status output above that the exit code is "0/SUCCESS" which is expected. 


Finally, we'll run Ava as a service on Linux, but started from the command line. This is as simple as entering "ava service". The process will run in the background. We can confirm by checking our TCP listener. Then "kill" the service to send it a SIGTERM signal that will set _stop to true and exit Mainline to shut down.


Today's version of Ava will also run as a daemon on macOS if started from the command line. However, macOS uses launchd instead of systemd. So we'll look at installing Ava as a daemon on macOS a little later on.









Comments

Post a Comment

Popular posts from this blog

Day 12 : 19 June 2022 : Adding Windows Service Logic

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #12 : Adding Windows Service Logic Today, we'll add some Win32 API logic in Ava to install, uninstall and run as a service on Windows. We'll add logic in Driver::Service that check if the program was started with the "service" argument as the first program argument. If so, the Service Control Manager will be invoked to start the program as a service. We'll also check for "install" and "uninstall" program arguments and handle these with logic that installs and uninstalls the program, respectively. In a later post, we'll do the equivalent on Linux and macOS and show how to enable Ava to run as a daemon configured in sysctl. Nowadays there are shortcut methods to install and run an executable as a service on Windows. But I prefer to illustrate the APIs that make this work. Some Code Refactoring Up to now we've been using a pointer-to-implementation (pimpl) method for exp...
Read more

Day 5 : 12 June 2022 : CMake on Windows

Image
 My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code Day 5 : 12 June 2022 : CMake on Windows So far, we've seen using CMake on Linux and MacOS. Also, we've looked at native compilation on Windows using Visual Studio (VS). Today, we'll look at using CMake on Windows. I decided to devote an entire day (hour) to this because there are several ways to invoke CMake on Windows, using different "Generators". A generator will write the inputs to the native build tools. But Wait, There's More ... Before heading to CMake, I wanted to first point out that VS' native tools can build just fine without using CMake, of course. To build using "msbuild," open an x64 Native Tools Command Prompt for Visual Studio - this is provided when VS is installed. Invoke msbuild and pass the solution name and the desired platform and configuration. msbuild ava.sln /p:Platform=x64 /p:Configuration=Debug Repeat for Debug and Release configurations for Win32 an...
Read more

Day 11: 18 June 2022 : Handling Program Arguments

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #11 : Handling Program Arguments Up to now we've been carrying around Ava's program argument count (argc) and value array (argv) into a Configure method. Now it's time to start doing something with those values. We'll define four program settings that can be set by passing program arguments: the logging level, path, prefix and suffix, and show examples of using them. Logging Parameter Storage The singleton theLog is instantiated inside the Ava library (libava). Default values for several logging parameters are set by the Log::Init method, which is called both by the Log class constructor and the destructor, by way of the Reset method, so that runtime values are not left in deallocated storage on operating systems that do not automatically clear memory upon deallocation. Logging Parameter Symbols We use namespaces and enums to define symbolic names for the logging parameters so that we have a single lo...
Read more