Page Contents

OMERO

Downloads
Feature List
Licensing

Previous topic

Exception handling

Next topic

Using the new 5.1 graph requests

This Page

Note

This documentation is for OMERO 5.2. This version is now in maintenance mode and will only be updated in the event of critical bugs or security concerns. OMERO 5.3 is expected before the end of 2016.

Omero logging

All OMERO components written in Java use the SLF4J logging facade, typically backed by Logback; all components written in python use the built-in logging module.

Warning

Refrain from calling logging.basicConfig() anywhere in your module except in if __name__ == "__main__" blocks.

Java clients

Java clients log to $HOME/omero/log. The number of files and their size are limited.

logback-cli.xml controls the output for the command line importer: all logging goes to standard err, while useful output (pixel ids, or used files) goes to standard out. It is contained within the blitz.jar itself. Therefore, to modify the settings use -Dlogback.configurationFile=/path/to/logback.xml or similar.

OMERO.insight logging is configured via logback.xml which is available in the config/ directory of any OMERO.insight install.

Java servers

Java server components are configured by passing -Dlogback.configurationFile=etc/logback.xml to each Java process. Entry.java guarantees that the logback.xml file is read periodically so that changes to your logging configuration do not require a restart.

By default, the output from logback is sent to: var/log/<servername>.log. Once files reach a size of 500MB, they are rolled over to <servername>.log.1, <servername>.log.2, etc. Once the files have rolled over, you can safely delete or compress (bzip2, gzip, zip) them. Alternatively, once you are comfortable with the stability of your server, you can either reduce logging or the number and size of the files kept. Note: if something goes wrong with your server installation, the log files can be very useful in tracking down issues.

In addition, each import process logs to a file under the managed repository which matches the timestamped fileset directory’s name. For example, if an imported fileset is uploaded to /OMERO/ManagedRepository/userA_1/2013-06/17/12-00-00.000, then the log file can be found under /OMERO/ManagedRepository/userA_1/2013-06/17/12-00-00.000.log.

Python servers

Python servers are configured by a call to omero.util.configure_server_logging(props). The property values are taken from the configuration file passed to the server via icegridnode. For example, the config file for Processor-0 can be found in var/master/servers/Processor-0/config/config. These values come from etc/grid/templates.xml.

All the “omero.logging.*” properties can be overwritten in your etc/grid/default.xml file (or on Windows, etc/grid/windefault.xml). See the “Profile” properties block for how to configure for your site.

Similar to logback, logging is configured to be written to var/log/<servername>.log and to maintain 9 backups of at most 500MB.

stdout and stderr

Though all components try to avoid it, some output will still go to stdout/stderr. On non-Windows systems, all of this output will be sent to the var/log/master.out and var/log/master.err files.

Windows stdout and stderr

On Windows, the state of stdout and stderr is somewhat different. No information will be written to master.out, master.err, or similar files. Instead, what logging is produced will go to the Windows Event Viewer, but finding error situations can be considerably more challenging (See #1449 for more information).