What about the file itself (i.e., /mnt/galaxy/galaxy-app/main.log) - who owns it? It could be that Galaxy was started manually during the build phase by a user other than galaxy and so it can't rewrite that file now? Either way, you can just delete that file and try it again.

As an image is built, the installation procedure itself leaves some artifacts that need to be cleaned up so the cleanup step is required just before bundling the AMI.

Cheers,
Enis

On Mon, Jun 22, 2015 at 6:43 PM, Alexander Vowinkel <vowinkel.alexander@gmail.com> wrote:
Hi,

I didn't do the cleanup, because I didn't change anything on the generated instance/image.

I now created a new clean instance and get this error:

2015-06-22 22:35:37,190 DEBUG         master:2482 Monitor done adding service Galaxy (setting config_changed)
2015-06-22 22:35:37,190 DEBUG     decorators:59   Cluster not yet ready (STARTING), skipping method cm.master->ConsoleMonitor.newFunction
[...]
2015-06-22 22:35:41,192 DEBUG         master:2478 Monitor adding service 'Galaxy'
2015-06-22 22:35:41,192 INFO        __init__:347  Galaxy service prerequisites OK; starting the service
2015-06-22 22:35:41,196 DEBUG         galaxy:84   Using Galaxy from '/mnt/galaxy/galaxy-app'
2015-06-22 22:35:41,212 DEBUG     decorators:83   Delay trigger not met (delta: 0; delay: 10. skipping method cm.services.apps.galaxy->GalaxyService.status
2015-06-22 22:35:41,217 DEBUG         galaxy:248  Galaxy UI does not seem to be accessible.
2015-06-22 22:35:41,217 DEBUG         galaxy:138  Starting Galaxy...
2015-06-22 22:35:41,246 DEBUG    galaxy_conf:32   Attemping to chown to galaxy for /mnt/galaxy/tmp
2015-06-22 22:35:41,281 DEBUG    galaxy_conf:190  Rewriting Galaxy's main config file: /mnt/galaxy/galaxy-app/config/galaxy.ini
2015-06-22 22:35:41,282 DEBUG    galaxy_conf:32   Attemping to chown to galaxy for /mnt/galaxy/galaxy-app/config/galaxy.ini
2015-06-22 22:35:41,917 ERROR           misc:848  ---> PROBLEM, running command '/bin/su - galaxy -c "export GALAXY_HOME='/mnt/galaxy/galaxy-app'; export TMPDIR='/mnt/galaxy/tmp'; export TEMP='/mnt/galaxy/tmp'; source $GALAXY_HOME/.venv/bin/activate; sh $GALAXY_HOME/run.sh --pid-file=main.pid --log-file=main.log --daemon"' returned code '2', the following stderr: '' and stdout: 'Activating virtualenv at /mnt/galaxy/galaxy-app/.venv
Error: Unable to write to log file: [Errno 13] Permission denied: 'main.log'
'
The directory /mnt/galaxy/galaxy-app is owned by galaxy.
Where is cloudman trying to write the logfile to?

Thanks,
Alexander

2015-06-19 10:16 GMT-05:00 Enis Afgan <enis.afgan@irb.hr>:
Hi Alexander, 
When you build the image, did you run the image cleanup step? RabbitMQ's database needs to be cleaned up before building the image otherwise the application won't start properly and the AMQP connection will never be established. 

You can also post the entire CloudMan's log somewhere and I can take a look there for other clues. 



On Tue, Jun 16, 2015 at 4:07 PM, Alexander Vowinkel <vowinkel.alexander@gmail.com> wrote:
Maybe connected. this error (happening multiple times):

----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 37201)
Traceback (most recent call last):
  File "/home/ubuntu/.virtualenvs/CM/local/lib/python2.7/site-packages/paste/httpserver.py", line 1068, in process_request_in_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python2.7/SocketServer.py", line 334, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python2.7/SocketServer.py", line 651, in __init__
    self.finish()
  File "/usr/lib/python2.7/SocketServer.py", line 710, in finish
    self.wfile.close()
  File "/usr/lib/python2.7/socket.py", line 279, in close
    self.flush()
  File "/usr/lib/python2.7/socket.py", line 303, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
error: [Errno 32] Broken pipe
----------------------------------------


2015-06-16 13:59 GMT-05:00 Alexander Vowinkel <vowinkel.alexander@gmail.com>:
Hi,

I have the following problem:
First, the job scheduling didn't work.

I tried to upload a file, but the job was waiting.
Then I checked "squeue", which timed out.
The slurm service was running.

Then I restarted the cluster.
Now I even have problems access the cloudman admin page.
Meaning, the page is loading endless.
The machine is not busy (CPU and mem @ htop)
In the paster.log it tries this every 4 seconds:

2015-06-16 18:35:56,547 DEBUG         master:2579 Trying to setup AMQP connection; conn = '<cm.util.comm.CMMasterComm object at 0x7f0aa26d72d0>'
2015-06-16 18:35:56,547 DEBUG           comm:30   Setting up a new AMQP connection
2015-06-16 18:35:56,548 DEBUG           comm:49   AMQP Connection Failure:  [Errno 111] Connection refused

Any idea what this might be?
Something seems to be really weird.

I am using the next version of CloudMan (dev).
I created an own instance with the Cloud Man playbook.

Best,
Alexander


___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/