- Revision: I’m now creating a Linux Daemon library from this project. See also the GitHub project page, wordptr.libwpd.
The response to my last post was really overwhelming, all things considered. Thanks once again to the Reddit community for all of the great suggestions, corrections and constructive criticisms leveled at the code I’ve written. Several brave souls even left comments on the post itself. For completeness, I suggest you review the previous post, the previous posts’ comments, and the reddit comments concerning this series.
- misc. bug fixes; add configuration options
As with all of the source code on this blog, I’ve pushed everything up to github under the repository. You can retrieve the latest like so:
This is the second in a series of posts concerning the construction of a Linux daemon from the ground up. This is a fledgling effort and there’s still quite a bit to flesh out:
- Improve the daemon interface
- Support configuration-driven options
- Make the daemon do something… fun. Nobody likes boring daemons.
In this post, I’ll discuss some of the design decisions concerning the interface and add support for command line and configuration file options. I’ll touch briefly on logging as well.
This post isn’t as exciting as the previous post (or posts to come), but it lays some important ground work.
Initialization code has changed dramatically. There’s now a callback to handle reconfiguration by the
wp_reconfigure_method_fn function pointer. Examine the following initialization routine, which creates the
daemon instance and handles client-side reconfiguration.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58
Note the call to
populate_from_file. The library can read options a configuration file. Update: I’ve removed
command-line argument handling. Code using this library should use their own command line argument processing technique,
handling arguments with the callback handler described above.
Configuration files have the following syntax:
1 2 3 4 5 6 7 8 9 10 11
Why Not libdaemon
It was suggested on the Reddit post that new deamon applications should simply utilize libdaemon. This isn’t a bad idea and I highly recommend that you examine both sources, but ultimately the code described in this series will become a full-fledged application and not simply a library for writing other daemons.
Changes to the Daemon Interface
If you’ve been following along, you may have noticed a couple of minor interface changes. The
name was renamed to
get_instance. This keeps the daemon interface naming convention consistent across classes and
methods. Second, a new type has been created,
wp_configuration_t which is passed to the
The purpose of this class is to encapsulate the various configuration options in a single source location.
Part of a nice application interface includes configuration settings. The
wp_configuration_t class describes the
interface for (primarily) the daemon (and may be extended later). Examine the new/delete interface below, as described
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
And the configuration interface:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
Hopefully the names are all self-explanatory. We have a load method (
populate_from_file) and a collection of
get and set properties. Note that
populate_from_file populates the configuration object from a configuration
/etc/wpd.conf for example).
For simplicity, the main loop of the method to populate from a configuration file utilizes fgets:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
A function pointer to a helper method is provided to properly populate the configuration object from the parsed token:
1 2 3 4 5
Logging is implemented through the ever-so-useful syslogd interface in
syslog.h. For the purpose of this project,
I abused the C preprocessor:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
With this in place, we now have a very simple logging mechanism in place:
For a daemon, this is absolutely essential. Once running, we’re blind to anything the daemon is doing since we’re not connected to a terminal. Our only visibility to anything is that which is logged.
With the daemonizer, configuration and logging utilities now in place, we have a very basic framework stitched together from which a much larger system can be built. Before we can get to that level, however, we still need to explore some additional ideas, including threading. As it stands, the configuration class isn’t thread safe, though we’ve made no guarantees in our interface that it’s threaded at all.
There’s a lot left to flesh out. Mostly, we need to make the daemon do something besides sit around taking up cycles. In the upcoming posts, I’ll look at:
- Improving the logging interface and configuration file parsing
- Rationalizing some of the configuration options
- Fix some outstanding TODOs scattered throughout the code
- Tackle the all-important purpose of the daemon
- Fix a memory leak when not started as a daemon
- Explore threading
- marcs notes on starting daemons
- beej’s guide to network programming
- unix programming faq
- Preventing buffer overflows
In this post, we looked at configuration options and logging. Code like this isn’t the most exciting or difficult to write, but it’s absolutely foundational for things to come.
Do you find these posts interesting? Useful? I’d appreciate whatever feedback you care to provide.
Thanks for reading!