Wow, that was a lot of time without me posting anything (five months), mostly because I am investing most of my spare time after work here in Finland for socializing. Still, from time to time one has to take a break, and there is no better way than just staying at home watching a good TV series, or doing some coding on pet projects. The later means that DMon got some love, and that version 0.4.1 is now available (tarball here, mirror there).
So… What’s new?
Most changes in this release are not user-visible, because I have been rewriting the insides of DMon to use libwheel, which enables some nice features and allowed to reduce the amount of code (less is more!). Anyway this is a summary of what’s new since version 0.3.7:
- Long command line options are now supported. Parsing and error reporting of arguments was improved.
- It is now possible for
dmonto read options from text files, by passing
-C) as first command line option, followed by a path to a file. File format is dead easy: long command line options (without trailing dashes) followed by arguments, one option per line, and lines starting with dashes are ignored.
- Real-time updates on the status of the processes being monitored can
be written now to a file (which may be a FIFO), using the
--write-infooption. This may be useful to integrate
dmonwith other tools. The manual page has now a section documenting the format of the generated status information.
drloglog tool, which supersedes
rotlog, was added. Use it to log to a directory of auto-rotated log files.
- A multicall binary is now built by default (that is: one binary
contains all tools, which can be symlinked under different names).
Separate binaries can still be built by passing
- A number of small cleanups and fixes, both in the code and manual pages.
Those are some vague ideas of things I would like to implement at some point:
- Add support for control groups. This would allow to do nice tricks like isolating processes more reliably, killing subprocesses spawned by daemons that create new process groups in the wild, finer controls on resource usage limits… As this is a Linux-specific feature, it will be a compile-time option.
- Handling of lock files. It may be interesting to have the ability of
locking some particular file before launching processes. This would
be mostly useful for tasks that are ran once under control of
start-stop-daemoncompatible replacement that uses DMon under the hood. This would allow for easily hooking it in traditional SysV init scripts.
- DInit: This would be a replacement for init(8), which would use
dmonto monitor processes. Why implementing another contender when there’s already systemd, upstart and a bunch of other implementations? First of all, I like hacking this kind of system-level things so I will be doing it “for fun”; second, I would like to focus on making it suitable for embedded devices and diskless operation (e.g. cluster nodes or minimal/rescue boot images).
Some final words…
Also, I will be in Berlin in August, from 5th to 12th… Yes, you guessed it: I’m attending the Desktop Summit:
See you around… and happy monitoring!