The Fat Controller v0.0.4 almost ready – testers wanted!

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!

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

16 Responses to The Fat Controller v0.0.4 almost ready – testers wanted!

  1. Nick says:

    Thinking about it, for testing you can just download the latest source from SVN:

    https://fat-controller.svn.sourceforge.net/svnroot/fat-controller/trunk/

    Open issues include:
    – Reacting if the logging sub-system fails to initialise or if logging fails during runtime
    – Continue logging when shutting down and waiting for current sub-processes to complete
    – SIGHUP signal should reinitialise the logging system in case log rotation or other has caused the log files to be deleted (ala cron: http://linux.die.net/man/8/crond)

  2. Charley says:

    Thanks Nick!

    I’ll give it a try with a small/basic PHP script I want to daemonise.

    I was also taking a look at Kevin van Zonneveld’s “System_Daemon” but I’ve decided to give your code a try first. Both of you seem to have done something pretty darn great!

  3. Nick says:

    Thanks for the feedback – be sure to let me know how you get on, comments and feedback are most appreciated!

  4. Wayne says:

    I will be glad to co and test 0.0.4.

    Sometimes my php script runs for > 3600s — probably my bug — and I don’t have any visibility on why, maybe STDERR will enlighten me.

  5. Wayne says:

    How to specify the new params –error-log-file, –run-once in /etc/fatcontroller?

  6. Wayne says:

    Sorry to spam, how do I report issues?

  7. Nick says:

    That’s great that you’d like to test v0.0.4 – thanks! You can get the sources from SVN (see link above) but probably tomorrow I will release it as v0.0.4 and then if there are no bugs then it can become v1.0.0.

    Issues can be reported in the Fat Controller section on Sourceforge:
    http://sourceforge.net/tracker/?group_id=386594

    But if that doesn’t work then just post a comment here and I’ll look into it!

  8. Tom says:

    Hello Nick!

    I install your program fatcontroller version 0.0.4 and I’m trying to test it.
    I have a few comments:

    1. cosmetics

    ./f​Fatcontroller -h

    -o, –run-once Run script only once, e.g. if daemon proc

    when I run
    ./fatcontroller -o

    Unrecognized option: -o

    2. Error in statement chdir(rundir) ( function demonize() ) could be logged.

    3. Can be useful option like –debug, but without run daemon, only show configuration an exit.

    I will continue testing.

    Tom

  9. Nick says:

    Hello Tom!

    Thank you so much for your feedback! I will take a look at those three topics and report back.

  10. Nick says:

    Hi Tom, all three topics are now resolved.

    I removed the -o argument, just use –run-once now.

    I’ve added in a syslog message if chdir() fails in function daemonize().

    I’ve added a new argument, –test-fire, which stops it daemonising and creating processes. So when used with –debug it will simply print a list of arguments and then end.

    Thanks again for your help!

  11. Tom says:

    Thanks Nick !

    I found another little bug:

    –debug option don’t writes information about name of error log file.

    I have a suggestion:

    Currently, to run program I have to give many options or use script fatcontrollerd and configuration file fatcontroller.

    I propose that ( shortly ):

    move the options to the standard configuration file ( default /etc/fatcontroller )

    leave only command line options:

    -f –config-file ( configuration in another file )
    –help
    –debug
    –test-fire
    –nodaemonise ( same as daemon = 0 in configuration file, useful to run without daemon )

    read setup from a configuration file.

    To run :
    /usr/local/bin/fatcontroller

    To view configuration :
    /usr/local/bin/fatcontroller –test-fire

    To run without demonise:
    /usr/local/bin/fatcontroller –nodemonise

    For me it will be easier.

    What do you think about it?.
    Maybe in the next version?

    Tom

  12. Nick says:

    Hi Tom!

    Thanks for the bug report – I’ve fixed it! As for your suggestion – I’m terrible with bash scripting, but I think what you’re proposing would be possible using a bash script to read the config file and also accept parameters itself. If you fancy giving it a try and get something working then we can add it to the repository. One thing to bear in mind is that people like to be able to have several different configuration files and specify which one to use when calling fatcontrollerd.

    Generally I agree – the focus for the next release should be configuration in general – how it is configured and how it checks those parameters before startup.

  13. Tom says:

    A small note to my previous post.

    I suggest adding the option:
    –config-file = filename
    and read the configuration from a file instead from the command line.
    Other options need to test.

    Then you can run if needed with the various configuration files:

    fatcontroller –config-file = config1
    fatcontroller –config-file = config2
    fatcontroller –config-file = config3
    and so on.

    Probably in many cases, only one configuration will be needed, and then run the program without a configuration file ( configuration in /etc/fatcontroller ).

    Tom

  14. Nick says:

    Thanks for the great ideas – please keep them coming! I think in order to start working on these ideas I need to get v0.0.4 out the door so unless anyone finds any more bugs then I will release it. Now to update the manual and web page…

  15. Simmy Transie says:

    This looks great but I am confused – I can only use this to daemonise 1 (for example) script on PHP? If I wanted want too use fatcontroller to launch several processes? Fatcontroller looks exactly like what I have been looking for – it was easy to set it up and get running but I need to daemonize several scripts not just once.

    Thanks!

  16. Nick says:

    Hi Simmy,

    Glad you find it useful! Indeed it is possible to run multiple scripts, the way to do it is to run one instance of The fat Controller per script, which means you will need to make a separate configuration file for each script you want to run.

    I wrote a comment a while ago explaining how to do it:
    http://www.4pmp.com/2011/08/the-fat-controller-v0-0-3-released/#comment-1207

    I’m afraid I haven’t had time to write this into the documentation yet but I will do soon. If you need any more help then please just let me know!

Leave a Reply

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