High Fibre Programming

I’m sorry it wasn’t in time for Christmas, I hope everyone managed to have at least a little bit of fun on Christmas day without it – but finally it’s here – version 0.0.4! This version involved the rewriting of the entire logging system for sub-processes, so plenty of testing was needed which wasn’t always compatible with Christmas festivities, (oddly enough).

Download: sourceforge.net/projects/fat-controller/files/

Project web: fat-controller.sourceforge.net

Continuous logging

The main aim for this release was to fully support the “daemonise anything” point of the Fat Controller raison d’etre. Prior to this release, output from sub-processes was collected and then written to the log file only once the process had ended. This was bad for two reasons:

• it only logs output on STDOUT, anything on STDERR is ignored
• no good for long-running daemon processes as nothing is logged until it ends

The Fat Controller now continually monitors STDOUT and STDERR of all sub-processes and immediately writes anything to the log file.

The whole logging system can be re-initialised by sending SIGHUP to The Fat Controller. So if, for example, your log files get deleted due to log rotation, simply send SIGHUP and The Fat Controller will re-open file descriptors to the log files. This can be easily added to your log rotation mechanism.

So, what else is new in v0.0.4? Here’s a brief summary taken from the changelog:

ADDED –run-once
Also to support daemon processes, using the –run-once argument it is possible to tell The Fat Controller to, (cunningly) run a process only once and then end.

ADDED –test-fire
If this argument is specified then The Fat Controller initialises but does not actually run, i.e. it does not daemonise (if it is specified to be in daemonise mode) nor does it run any processes. It is useful combined with the –debug option when testing to check arguments have been correctly read and interpreted.

CHANGED Debug mode
Debug mode is turned on by using the –debug argument when running The Fat Controller. Previously this was added by the init script /etc/init.d/fatcontrollerd if the file fatcontroller.debug was found in the current directory. In addition to turning on debug mode, it also looked for the configuration file in the current directory, and not in /etc/

This has now been substantially simplified. All you need to do to enable debug mode is instead of running the Fat Controller with:

sudo /etc/init.d/fatcontrollerd start

Use:

sudo /etc/init.d/fatcontrollerd debug

My plan is that if no major bugs are found in this release then I will re-release it as v1.0.0 as it will finally be everything that I imagined when I first started this project over a year ago.

I’ve still got plenty more ideas for development and I’m eager to hear any other ideas people may have. Please let me know if you have a great idea or suggestion!

I’ve just about finished the next version of The Fat Controller, v0.0.4. I’ve completely refactored the way it writes output from sub-processes so it needs some careful testing. It would be great if other people could give it a try and do some testing as well, if you’re interested then just leave a comment and I’ll send you the source. Perhaps version 0.0.4 could be ready in time for Christmas – and what better Christmas present than a new version of The Fat Controller?!

Here are the main new features:

Continuous logging
One of the shortcomings of previous versions was that output from sub-processes was only written to the log file once the process had ended. This is of little important for scripts which run quickly, but this is obviously no good for longer scripts or even when used to daemonise a program.

Now, output is written immediately to the log file which means that The Fat Controller can easily be used to daemonise other programs.   One of the issues I sometimes have with Java applications is that there’s not a simple way to run them as a daemon.   With The Fat Controller this is now possible, as well as provide handling should the Java application terminate for whatever reason.

Logging STDERR
In previous versions, only STDOUT from sub-processes was logged.   In v0.0.4 STDERR is also logged and you can specify either a separate log file for STDOUT and STDERR or simply log both into one file.

If you want to impress and amaze your friends and get your hands on the latest version before everyone else then just leave a comment below and I’ll send you the source and you can get testing!

Finally, after almost five months, version 0.0.3 is ready!

https://sourceforge.net/projects/fat-controller/files/

There are plenty of changes, mostly bug fixes which relate to startup options (not the actual running of The Fat Controller) and a new thread model – fixed interval – which runs processes like cron at fixed, regular intervals between each new process creation.

Here are some highlights from the changelog:

ADDED Fixed interval thread model
The ‘independent thread model’ and ‘dependent thread mode’ start another instance of the target program a specified number of seconds after the previous instance ends. The ‘fixed interval thread model’ starts another instance a specified number of seconds after the previous instance starts, hence the interval beteen new instances is fixed. The interval is specified using the -s,--sleep argument, just as for the other thread models. Note that the interval is respected even if a process returns status 64. Only if a process returns a status of -1 will the interval specified by -e,--sleep-on-error be used.

ADDED Long running instance termination
Using the --proc-run-time-max argument, it is now possible to specify that an instance be terminated if it runs longer than the specified number of seconds. Default behaviour is never to terminate processes unless the main Fat Controller process is requested to shutdown. (Processes terminated by sending SIGTERM). It is advised to specify this argument.

Plans for v0.0.4
I’ve already drawn up a rough list of features and improvements for v0.0.4, the most important being changing the logging of sub-processes. Rather than collecting from STDOUT and writing everything to the log file once a sub-process ends, The Fat Controller will continually write whatever arrives from STDOUT and STDERR to log files. This will make things much better for long running sub-processes.

If you have any ideas or suggestions then please comment or file a report on the Sourceforge Fat Controller tracker page:

https://sourceforge.net/tracker/?group_id=386594

It’s been ages in development (sorry about that) but the next version of The Fat Controller is almost ready! Apart from really quite a lot of bug fixes the main new feature is called “fixed interval mode” which works more like CRON in that scripts are executed at precise time intervals, unlike measuring the interval from when a script ends. This brings in a whole host of new problems, such as multiple instances, maximum instances, what to do when we’ve reached the maximum number of instances and so on, and yes, there are plenty of new configuration options to address all of this!

After finding quite a few embarrassing bugs in v0.0.2, I’ve decided to spend some time on Quality Assurance, which is what I’m currently doing before releasing v0.0.3. If anyone wants to help out with this then please let me know – any and all help is appreciated!