The Fat Controller v0.0.4 released!

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).


Project web:

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


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!

This entry was posted in The Fat Controller and tagged . Bookmark the permalink.

11 Responses to The Fat Controller v0.0.4 released!

  1. Tom says:

    Hello Nick!

    I have few comments:

    1. information about bad long option

    ./fatcontroller –cmd
    program prints:
    Unrecognised option: –
    and I don’t know what option

    I suggest, change in file dgetopts.c line 264 on
    fprintf(stderr, “Unrecognised option: %s\n”, argv[optind-1]);

    2. segmentation fault

    ./fatcontroller -c

    and I get
    segmentation fault

    in non daemon mode you don’t check -l option.

    I suggest if no -l option, then set log file to /dev/null.

    3. information in syslog

    ./fatcontroller -c -l /dev/null
    when not exists in syslog i found
    Dec 30 16:19:59 hp-ux FatController[8067]: Could not replace child process – shutting down child
    in my opinion, this information does not say anything

    When program run in daemon mode in syslog i found

    Dec 30 17:01:53 hp-ux FatController[8406]: Daemon starting up
    Dec 30 17:01:53 hp-ux FatController[8406]: Daemon exiting

    program runs with pid=8407, and I know nothing about starting daemon with pid=8407

    when I kill the proccess 8407 in syslog is correct information
    Dec 30 17:06:54 hp-ux FatController[8407]: Daemon exiting

    4. -p –path option

    In changelog you write that :
    -p –path is deprecated
    but still using this option in function parseOptions.

    As for suggestions on the program, about which I wrote 28.12.2011 ie, reading options from a configuration file, I have it almost complete.
    If you are interested to write.

    Best regards

  2. Nick says:

    Hi Tom – thanks for this, I’m currently working through it. With regards to point 2, I think the easiest solution is to make -l a required argument. However, if not running in daemon mode it might actually be desirable to tell The Fat Controller not to log anything and instead had STDOUT and STDERR of all sub-processes piped to the STDOUT and STDERR of the Fat Controller process.

    Concerning point 4, I left in support for the -p argument so that old configurations will still work. Although, perhaps it can be taken out now so that was a few versions ago.

    Great that you’ve been writing something concerning configuration, would be great to see it – I’ll email you so you can send it to me.

  3. Nick says:

    Hi Tom. I’ve gone through your list, points 1 and 2 are fixed. As I mentioned previously, specifying a log file is not a required argument. If this is not ideal then it can always be refactored later but simply not starting the sub-process logging service (which would involve either always checking if it is started or for it not to return an error if called when not initialised).

    Regarding point 3 – it now gives more information, for example:

    “FatController[2025]: Failed to execute command /usr/bin/pytho Error: [2] No such file or directory”

    Just committed changes to SVN.

  4. Jeff says:

    Hey Nick, thanks for TheFatController, currently using it for one of my background processing tasks.

    I’m pretty sure I went over the documentation, but I couldn’t find any way to have multiple configuration scripts for the fat controller? For example I want to run two different background tasks with completely different options. All I have is /etc/fatcontroller to play with.

  5. Nick says:

    Hello Jeff,

    Thanks for the comment – it’s nice to hear The Fat Controller being used. Reminds me also that I should perhaps get on with releasing the next version!

    I’m sorry the documentation is a bit sparse (that’s another thing I need to spend some time on!) but it is indeed possible to run multiple instances. I wrote a comment some time ago on another post which explains how it works:

    If you need any more information or have any questions then please just let me know!

  6. Jeff says:

    If you want to deploy 0.05 soon I will definitely apply as a tester. The Fat Controller saved my life!

  7. Nick says:

    :-) Well, the next version will be 1.0.0. Basically it’s the same as v0.0.4 but I’ve fixed a few minor bugs (see comments above). If you want to give it a test then you can download the source from SVN:

    I’ve done a bit of testing myself but that was quite a while ago, I’m afraid I’ve been pretty busy with other stuff lately. But if you can give it a test and don’t find any bugs then I’d say we’re safe to release v 1.0.0.

    Any new ideas for v1.1.0?

  8. Jeff says:

    We’re just talking about revisions 51 and 52? I’ve reviewed them, not sure I need to test.

    My only issue was running multiple jobs, as long as the doc is clearer on that, then I have no other ideas for the moment.

  9. Daniel says:

    Hey man, great tool.

    move over to git, or

  10. Shamik says:

    Hi Nick,

    Thanks for a great tool. Just started to use it. Will surely write back once I have used it for a while.

    Meanwhile, came across a minor typo/bug in the latest revision (52). You might want to fix it.

    In the startup script ‘scripts/fatcontrollerd’: 76
    should be

    Guess the sourceforge support list would have a better place to report it. My apologies for that.

  11. Nick says:


    Thanks for the feedback, always nice to hear that people are using it and finding it useful!

    Also thank you very much for the bug report. I’ve corrected the issue (revision #53) and with some luck (and a bit of time!) I’ll release version 1.0.

Leave a Reply

Your email address will not be published. Required fields are marked *