Question: Need help with changing galaxy.ini to fix freezing Pilon in Cloning stage
gravatar for msprindzhuk
21 months ago by
msprindzhuk50 wrote:

Need help with changing galaxy.ini to fix freezing Pilon in Cloning stage. How to contact Pilon, FreeBayes, VTTools, wrapper developers to ask them help? I could not find their emails anywhere. Thank you

Here are the settings:

   # -- Database
   database_connection =    postgres://postgres:postgres@localhost:5432/galaxy
   # By default, Galaxy uses a SQLite database at 'database/universe.sqlite'.  You    # may use a SQLAlchemy connection string to specify an external database    # instead.  This string takes many options which are explained in detail in the    # config file documentation.    #database_connection = sqlite:///./database/universe.sqlite?isolation_level=IMMEDIATE
   # If the server logs errors about not having enough database pool connections,    # you will want to increase these values, or consider running more Galaxy    # processes.    #database_engine_option_pool_size = 5    #database_engine_option_max_overflow = 10
   # If using MySQL and the server logs the error "MySQL server has gone away",    # you will want to set this to some positive value (7200 should work).    #database_engine_option_pool_recycle = -1
   # If large database query results are causing memory or response time issues in    # the Galaxy process, leave the result on the server instead.  This option is    # only available for PostgreSQL and is highly recommended.    #database_engine_option_server_side_cursors = False
   # Log all database transactions, can be useful for debugging and performance    # profiling.  Logging is done via Python's 'logging' module under the qualname    # 'galaxy.model.orm.logging_connection_proxy'    #database_query_profiling_proxy = False
   # By default, Galaxy will use the same database to track user data and    # tool shed install data.  There are many situations in which it is    # valuable to separate these - for instance bootstrapping fresh Galaxy    # instances with pretested installs.  The following option can be used to    # separate the tool shed install database (all other options listed above    # but prefixed with install_ are also available).    #install_database_connection = sqlite:///./database/universe.sqlite?isolation_level=IMMEDIATE
   # Setting the following option to true will cause Galaxy to automatically    # migrate the database forward after updates. This is not recommended for production    # use.    #database_auto_migrate = False
   # -- Files and directories
   # Dataset files are stored in this directory. file_path = database/files
   # Temporary files are stored in this directory. new_file_path = database/tmp
   # Tool config files, defines what tools are available in Galaxy.    # Tools can be locally developed or installed from Galaxy tool sheds.    # (config/tool_conf.xml.sample will be used if left unset and    # config/tool_conf.xml does not exist). tool_config_file = config/tool_conf.xml,config/shed_tool_conf.xml
   # Enable / disable checking if any tools defined in the above non-shed    # tool_config_files (i.e., tool_conf.xml) have been migrated from the Galaxy    # code distribution to the Tool Shed.  This setting should generally be set to    # False only for development Galaxy environments that are often rebuilt from    # scratch where migrated tools do not need to be available in the Galaxy tool    # panel.  If the following setting remains commented, the default setting will    # be True.    #check_migrate_tools = True
   # Tool config maintained by tool migration scripts.  If you use the migration    # scripts to install tools that have been migrated to the tool shed upon a new    # release, they will be added to this tool config file.    #migrated_tools_config = config/migrated_tools_conf.xml
   # File that contains the XML section and tool tags from all tool panel config    # files integrated into a single file that defines the tool panel layout.  This    # file can be changed by the Galaxy administrator to alter the layout of the    # tool panel.  If not present, Galaxy will create it.    #integrated_tool_panel_config = integrated_tool_panel.xml
   # Default path to the directory containing the tools defined in tool_conf.xml.    # Other tool config files must include the tool_path as an attribute in the    # <toolbox> tag. tool_path = tools
   # -- Tool dependencies
   # Path to the directory in which tool dependencies are placed.  This is used by    # the Tool Shed to install dependencies and can also be used by administrators    # to manually install or link to dependencies.  For details, see:    #    # Set the string to None to explicitly disable tool dependency handling.    # If this option is set to none or an invalid path, installing tools with dependencies    # from the Tool Shed will fail. tool_dependency_dir = database/dependencies
   # The dependency resolvers config file specifies an ordering and options for how    # Galaxy resolves tool dependencies (requirement tags in Tool XML). The default    # ordering is to the use the Tool Shed for tools installed that way, use local    # Galaxy packages, and then use Conda if available.    # See    # for more information on these options.
   dependency_resolvers_config_file =    config/dependency_resolvers_conf.xml
   # The following Conda dependency resolution options will change the defaults for    # all Conda resolvers, but multiple resolvers can be configured independently    # in dependency_resolvers_config_file and these options overridden.    # Location on the filesystem where Conda packages are installed
   # conda_prefix is the location on the filesystem where Conda packages and environments are installed    # IMPORTANT: Due to a current limitation in conda, the total length of the    # conda_prefix and the job_working_directory path should be less than 50 characters!
   conda_prefix = /home/galaxy/galaxy/database/dependencies/_conda
   # Override the Conda executable to use, it will default to the one on the    # PATH (if available) and then to <conda_prefix>/bin/conda    #conda_exec =
   # Pass debug flag to conda commands.
   #conda_debug = False
   # conda channels to enable by default (
   conda_ensure_channels = conda-forge,r,bioconda,iuc
   # Set to True to instruct Galaxy to look for and install missing tool    # dependencies before each job runs.
   conda_auto_install = True
   # Set to True to instruct Galaxy to install Conda from the web automatically    # if it cannot find a local copy and conda_exec is not configured.
   conda_auto_init = True
   # You must set this to True if conda_prefix and job_working_directory are not on the same    # volume, or some conda dependencies will fail to execute at job runtime.    # Conda will copy packages content instead of creating hardlinks or symlinks.    # This will prevent problems with some specific packages (perl, R), at the cost    # of extra disk space usage and extra time spent copying packages.
   conda_copy_dependencies = True
   # Certain dependency resolvers (namely Conda) take a considerable amount of    # time to build an isolated job environment in the job_working_directory if the    # job working directory is on a network share.  Set the following option to True    # to cache the dependencies in a folder. This option is beta and should only be    # used if you experience long waiting times before a job is actually submitted    # to your cluster.
   #use_cached_dependency_manager = False
   # By default the tool_dependency_cache_dir is the _cache directory    # of the tool dependency directory    #tool_dependency_cache_dir = <tool_dependency_dir>/_cache
   # File containing the Galaxy Tool Sheds that should be made available to    # install from in the admin interface (.sample used if default does not exist).
   #tool_sheds_config_file = config/tool_sheds_conf.xml
   # Set to True to enable monitoring of tools and tool directories    # listed in any tool config file specified in tool_config_file option.    # If changes are found, tools are automatically reloaded.  Watchdog (    # ) must be installed and    # available to Galaxy to use this option. Other options include 'auto'    # which will attempt to watch tools if the watchdog library is available    # but won't fail to load Galaxy if it is not and 'polling' which will use    # a less efficient monitoring scheme that may work in wider range of scenarios    # than the watchdog default.
   #watch_tools = False
   # Enable Galaxy to fetch Docker containers registered with generated    # from tool requirements resolved through conda. These containers (when    # available) have been generated using mulled -    # These containers are highly beta and availablity will vary by tool.    # This option will additionally only be used for job destinations with    # Docker enabled.    #enable_beta_mulled_containers = False
   # Container resolvers configuration (beta). Setup a file describing container    # resolvers to use when discovering containers for Galaxy. If this is set to    # None, the default containers loaded is determined by    # enable_beta_mulled_containers.
   #containers_resolvers_config_file = None
   # involucro is a tool used to build Docker containers for tools from Conda    # dependencies referenced in tools as `requirement`s. The following path is    # the location of involucro on the Galaxy host. This is ignored if the relevant    # container resolver isn't enabled, and will install on demand unless    # involucro_auto_init is set to False.
   involucro_path = database/dependencies/involucro
   # Install involucro as needed to build Docker containers for tools. Ignored if    # relevant container resolver is not used.
   involucro_auto_init = True
   # Enable automatic polling of relative tool sheds to see if any updates    # are available for installed repositories.  Ideally only one Galaxy    # server process should be able to check for repository updates.  The    # setting for hours_between_check should be an integer between 1 and 24.
   enable_tool_shed_check = False hours_between_check = 12
   # Enable use of an in-memory registry with bi-directional relationships between    # repositories (i.e., in addition to lists of dependencies for a repository,    # keep an in-memory registry of dependent items for each repository.
   manage_dependency_relationships = True
   # XML config file that contains data table entries for the    # ToolDataTableManager.  This file is manually # maintained by the Galaxy    # administrator (.sample used if default does not exist).
   tool_data_table_config_path = config/tool_data_table_conf.xml
   # XML config file that contains additional data table entries for the    # ToolDataTableManager.  This file is automatically generated based on the    # current installed tool shed repositories that contain valid    # tool_data_table_conf.xml.sample files.  At the time of installation, these    # entries are automatically added to the following file, which is parsed and    # applied to the ToolDataTableManager at server start up.
   #shed_tool_data_table_config = config/shed_tool_data_table_conf.xml
   # Directory where data used by tools is located, see the samples in that    # directory and the wiki for help:    #
   tool_data_path = tool-data
   # Directory where Tool Data Table related files will be placed    # when installed from a ToolShed. Defaults to tool_data_path.
   shed_tool_data_path = tool-data
   # File containing old-style genome builds    #builds_file_path = tool-data/shared/ucsc/builds.txt
   # Directory where chrom len files are kept, currently mainly used by trackster    #len_file_path = tool-data/shared/ucsc/chrom
   # Datatypes config file(s), defines what data (file) types are available in    # Galaxy (.sample is used if default does not exist).  If a datatype appears in    # multiple files, the last definition is used (though the first sniffer is used    # so limit sniffer definitions to one file).    #datatypes_config_file = config/datatypes_conf.xml
installation pilon • 735 views
ADD COMMENTlink modified 21 months ago by Martin Čech ♦♦ 4.9k • written 21 months ago by msprindzhuk50
gravatar for Martin Čech
21 months ago by
Martin Čech ♦♦ 4.9k
United States
Martin Čech ♦♦ 4.9k wrote:

Pilon wrapper is being developed here: (this url is listed on the repository's page in the Tool Shed)

That said this does not seem like the tool's problem because Pilon installs fine for me on Galaxy 17.01.

What is your Galaxy's version? I recommend trying installing it with the default Galaxy configuration - i.e. using only the sample config (that came with your version of Galaxy) with changes only to database configuration but not enabling other options.

Also please do not create duplicate questions - you already asked about pilon installation here:

ADD COMMENTlink written 21 months ago by Martin Čech ♦♦ 4.9k
Please log in to add an answer.


Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 16.09
Traffic: 177 users visited in the last hour