New user - How long are the 'test' supposed to run?

[Bob Gustafson]

I am in the process of trying to bring up CloudI on two different machines.

Macbook Air using Xcode & Homebrew

  On one of my recent attempt, the tests ran for more than a day (until I stopped CloudI) and created about 450 MB of log messages.

  Is this expected? How long should it run until it 'completes'.

  Also, is there any way to disable the testing, once they have run (to completion?)

Fedora 21 - 32GB

  It seems to compile and link fine, but terminates soon after I try to run it (sudo cloudi start).

  I have been clicking around on the documentation for cloudi and there doesn't seem to be a 'quick guide to problems'.

  I wonder if it is the systemd starting method on Fedora rather than the /etc/init.d/cloudi method on Ubuntu

----

Even just a few clues would be welcome.

Bob G

[Michael Truog]

On 05/14/2015 09:21 AM, Bob Gustafson wrote:

I am in the process of trying to bring up CloudI on two different machines.

Macbook Air using Xcode & Homebrew

  On one of my recent attempt, the tests ran for more than a day (until I stopped CloudI) and created about 450 MB of log messages.

  Is this expected? How long should it run until it 'completes'.

This is expected.  The only integration test that completes is the hexpi test which stops once it does the first 65k hexadecimal digits of pi.  The messaging tests run continuously and other tests stay running for manual usage to allow testing of any possible race combinations or deadlocks that might happen if there were any problems.  The tests are also meant to provide some examples to show how various features work and many are implemented in all the supported programming languages, so you can pick the programming language you are interested in to look at the example.

  Also, is there any way to disable the testing, once they have run (to completion?)

Yes, you should just remove the service configuration entries within the /usr/local/etc/cloudi/cloudi.conf file (assuming the install prefix was the default /usr/local).  If you needed to disable the integration tests during the installation process, you can use the configure script command line argument --without-integration-tests .

Fedora 21 - 32GB

  It seems to compile and link fine, but terminates soon after I try to run it (sudo cloudi start).

If CloudI terminates when it is trying to startup, it means that a service failed to initialize.  If you look at the information in the /usr/local/var/log/cloudi/cloudi.log file you will find ERROR entries related to the initialize problem.  For the service to fail to initialize, it needs to fail the max_r (max restarts) times within the max_t (time period), so based on the service configuration values which are normally set to (and default to) 5 times within 300 seconds.

  I have been clicking around on the documentation for cloudi and there doesn't seem to be a 'quick guide to problems'.

Yes, that is probably a good section to add.  The termination information above is probably a good first entry.  The termination when a service fails to initialize, when the service configuration is in the CloudI configuration file is by-design to provide fail-fast operation.  The best time to catch errors is during system configuration, since the (execution) lifetime of a service is normally undefined.  If at least the starting state can be verified by making sure all the services initialize successfully, then all the later processing should be as expected.  When you use the CloudI Service API to start services dynamically (with services_add, http://cloudi.org/api.html#2_services_add), it does not terminate CloudI, since it is not dealing with a starting state there (instead, you may get an error return value, if there was a problem with a service starting).

  I wonder if it is the systemd starting method on Fedora rather than the /etc/init.d/cloudi method on Ubuntu

CloudI doesn't have any special systemd integration right now, since CloudI is focused on cross-platform development, so both BSD and SYSV UNIX systems.  I have looked at adding some systemd integration, but currently there doesn't exist a standard API (like POSIX) to interact with systemd and much of the usage would require manual filesystem manipulation.  You can run CloudI either as the root user or as a non-privileged user without problems (if you choose to use it as a non-privileged user, just change the install prefix (i.e., the --prefix provided to the configure script) to a local path the non-privileged user has ownership of).  So, the test execution is straight-forward and the failure you described will have information in the /usr/local/var/log/cloudi/cloudi.log file.  If you find a problem with the default install, just send the cloudi.log file and the config.log file (from the configure script run) (it would also help if you had output from the build, but it only is really necessary if it was a build problem, which should be handled in the autoconf/automake system).

----

Even just a few clues would be welcome.

If you have further problems, make sure to speak-up.  Will add the troubleshooting section to the FAQ which will help to make this simpler.

Bob G

--
You received this message because you are subscribed to the Google Groups "CloudI Questions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloudi-questio...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.