GENESIS: Documentation

Related Documentation:

Automated Tester

The neurospaces_cron Script

This script is part of the DeveloperPackage, its function is to perform sanity checks for communicating with a repository, system installation, and runs tests to check that software packages are properly working. Here we introduce how to use the script, set up a cron job, and how to avoid some common pitfalls.

Running neurospaces_cron

The neurospaces_cron script can be run by entering “neurospaces_cron” from the command line after installing the DeveloperPackage. There are command line arguments available to customize aspects of a cron job, e.g.

However, it is preferable to create a YAML configuration file to set cron job parameters.

The neurospaces_cron Configuration File

The neurospaces_cron configuration file is a YAML formatted file containing values that can be set for the following optional parameters:

Example configuration file:
OUTPUTDIR: /var/www/tests  
DOXYGENOUTPUT: /var/www/doxygen  
REGTESTOUTPUT: /var/www/regtests  
NOCHECK: False  
PKGDEB: /var/www/debian  

The Cron Job

Setting up a cron job typically requires administrator rights. There are several ways to run a cron job. We now give some of the easiest ways to do this on a Linux based machine.

To automate the running of a cron job create the directory /etc/cron.d. A cron job formatted text file placed in this directory will be picked up by the cron daemon. A typical invocation for neurospaces_cron would be with a line like this:

   01 00 * * * g3tester neurospaces_cron

This job is set to run at exactly one minute after midnight. To run the job more frequently you could do this:

   01 */8 * * * g3tester neurospaces_cron

which would make the cron job run every eight hours.

Note: The g3tester is a user set up for permissions to perform a sudo make install, and sudo make uninstall. To set up a regular user to use sudo, add them to the /etc/sudoers file (see next section).

Testing the cron daemon

Bad syntax in your crontab file can prevent any of the jobs from executing. If you want to test if your cronjobs are going off you can use the wall command. The wall command sends a message to the terminal of all users logged in. Check your system for the proper way to call it via:

man wall

Some systems have it invoked as:

wall "my message"

While some call it with a file containing your broadcast message as an argument:

man mymessage.txt

Simply enter a line in your crontab like this:

* * * * * root wall /etc/mymessage.txt

This will send the broadcast message every minute, so if you don’t see any output on your screen you know something is wrong.

Alternatively you can also have a command that just outputs the date to a file every minute:

* * * * * root date >> /tmp/cronout.txt

Then you can just check the output file for a date message for every minute. This is probably better to use if the machine has many users that you don’t wish to disturb with a terminal message.

The Sudoers File

The sudoers file grants a particular user the privileges to run a command or set of commands in superuser mode. The file is located at /etc/sudoers. There are variables in the file which must be set to allow a regular user to perform the neurospaces_cron tests as they require GENESIS components to be installed and uninstalled to the system.

To allow the g3tester user to perform any command anywhere on the system in superuser mode the following line can be placed into the sudoer’s file:

   g3tester ALL=(ALL) ALL

This configuration line still results in the system asking for a password, which will stop the cron job. To prevent this, the “NOPASSWD” option can be inserted:

   g3tester ALL=(ALL) NOPASSWD: ALL

Since it is desirable to restrict a regular user to commands they absolutely need to run, their privileges can be limited to a particular list of command, e.g.

   g3tester ALL=(ALL) NOPASSWD: /usr/bin/make /usr/local/bin/neurospaces_cron

This limits the user g3tester to executing only the commands neurospaces_cron and make, without requiring a password. More commands can be added as needed simply by appending them to the list with a space delimiter.


By default, the cron daemon will usually not log anything. To turn on logging you need to add a line to the system log configuration. In debian the file you need to edit is /etc/rsyslog.conf. Before proceeding, it’s a good idea to make a backup copy of your system log configuration. Open the file with your favorite text editor and add this line:

cron.* -/var/log/cron.log

You can change /var/log/cron.log to the file of your choice. Once your change is in place restart the system log daemon.

/etc/init.d/rsyslog restart

Not that on a Red Hat system the file you need to edit is /etc/syslog.conf and you restart the daemon via the command:

/etc/rc.d/init.d/syslog restart