Re: [galaxy-dev] Stop/Start/Reboot/Terminate
Dannon Thanks for the update. I was able to power through getting the EC2 instance to start using the cloud man interface in the same zone as the volume. Will let it run until next week. Amazon was not cooperating and kept launching instances in the opposite zone that I had the yaml file pointing to the storage volume. Finally got lucky after a couple attempts. Let me know if you want me to do any testing. Scooter On 11/1/12 11:20 AM, "Dannon Baker" wrote: >Galaxy Cloudman does not support Stop/Start through the AWS interface, >this is known to cause problems and should be avoided. The persistence >design allows for complete termination and restart -- the issue with your >startup zone can be worked around currently by launching through the AWS >console (following the instructions at usegalaxy.org/cloud) instead of >cloudlaunch. That said, I'm currently updating cloudlaunch to support >zone detection and launch, to avoid any issues with that moving forward, >but this won't be available on main until monday, most likely. > >That out of the way, the issue you're experiencing right now is likely >caused by an error with cm_boot.py causing duplicated nginx >max_client_body_size directives. > >This problem has been fixed on the back end and won't happen with any new >clusters going forward, but for existing clusters experiencing the >problem you can probably fix it in in a few short steps: > >ssh in to the instance >edit /opt/galaxy/pkg/nginx/conf/nginx.conf, removing any redundant >max_client_body_size directives. There should be exactly one in the file. >download a copy of the newest >https://s3.amazonaws.com/cloudman/cm_boot.py (save it to your desktop or >something) >In the AWS console, go to S3 and find your cluster's bucket (it'll have a >file called .clusterName, for easy identification. >Now upload the new cm_boot.py you just saved, replacing the one currently >in the bucket. > >Once the modified file is in your bucket, simply restart the instance via >the AWS console and everything *should* come up fine. > >Sorry for any inconvenience! > >-Dannon > > > >On Nov 1, 2012, at 10:49 AM, Scooter Willis wrote: > >> >> Last night I used the Amazon console to stop my working instance. Today >>started up the instance using amazon console. Waited appropriate time, >>using new assigned public ip address and no response. Also did a reboot >>and no response. I can ssh to the instance but do not know what to check >>for errors. >> >> Should you be able to stop/start and instance in amazon console and >>have it work correctly? Trying to avoid the "power down" option using >>the galaxy web interface since I had the problem with new instances >>being started in a different availability zone where the EBS volume was >>located. >> >> Looks like I will be leaving the master instance running and >>contributing to amazon profit margins! >> >> >> ___ >> 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: >> >> http://lists.bx.psu.edu/ > ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Stop/Start/Reboot/Terminate
Galaxy Cloudman does not support Stop/Start through the AWS interface, this is known to cause problems and should be avoided. The persistence design allows for complete termination and restart -- the issue with your startup zone can be worked around currently by launching through the AWS console (following the instructions at usegalaxy.org/cloud) instead of cloudlaunch. That said, I'm currently updating cloudlaunch to support zone detection and launch, to avoid any issues with that moving forward, but this won't be available on main until monday, most likely. That out of the way, the issue you're experiencing right now is likely caused by an error with cm_boot.py causing duplicated nginx max_client_body_size directives. This problem has been fixed on the back end and won't happen with any new clusters going forward, but for existing clusters experiencing the problem you can probably fix it in in a few short steps: ssh in to the instance edit /opt/galaxy/pkg/nginx/conf/nginx.conf, removing any redundant max_client_body_size directives. There should be exactly one in the file. download a copy of the newest https://s3.amazonaws.com/cloudman/cm_boot.py (save it to your desktop or something) In the AWS console, go to S3 and find your cluster's bucket (it'll have a file called .clusterName, for easy identification. Now upload the new cm_boot.py you just saved, replacing the one currently in the bucket. Once the modified file is in your bucket, simply restart the instance via the AWS console and everything *should* come up fine. Sorry for any inconvenience! -Dannon On Nov 1, 2012, at 10:49 AM, Scooter Willis wrote: > > Last night I used the Amazon console to stop my working instance. Today > started up the instance using amazon console. Waited appropriate time, using > new assigned public ip address and no response. Also did a reboot and no > response. I can ssh to the instance but do not know what to check for errors. > > Should you be able to stop/start and instance in amazon console and have it > work correctly? Trying to avoid the "power down" option using the galaxy web > interface since I had the problem with new instances being started in a > different availability zone where the EBS volume was located. > > Looks like I will be leaving the master instance running and contributing to > amazon profit margins! > > > ___ > 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: > > http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/
[galaxy-dev] Stop/Start/Reboot/Terminate
Last night I used the Amazon console to stop my working instance. Today started up the instance using amazon console. Waited appropriate time, using new assigned public ip address and no response. Also did a reboot and no response. I can ssh to the instance but do not know what to check for errors. Should you be able to stop/start and instance in amazon console and have it work correctly? Trying to avoid the "power down" option using the galaxy web interface since I had the problem with new instances being started in a different availability zone where the EBS volume was located. Looks like I will be leaving the master instance running and contributing to amazon profit margins! ___ 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: http://lists.bx.psu.edu/
