2

I've recently been moving our instances to EBS instances (CentOS) and still have a bit of confusion on what's happening when I "stop" and instance. I have some of my services with runlevels 345 on but when I start a stopped instance the services don't start. What's actually happening when I issue a stop command to the instance, and how do I get my services to start automatically when I start the instance up again?

ahanson
  • 1,704
  • 2
  • 16
  • 21
  • Rebooting the instance seemed to get everything to work. I'm going to chalk it up as a fluke or some other reason. – ahanson Jan 11 '10 at 20:01
  • Flukes happen. That's one reason I design in the direction of not depending on the previous state being well preserved, or preserved at all. And it scales better when next I need 2 or more of the same thing. I always prefer a fresh start. – Skaperen Sep 15 '12 at 04:09

3 Answers3

1

Stopping an EBS-backed AMI is the same as shutting it down, and is not some kind of frozen hibernation state.

  • Log in after starting a stopped instance, and run the uptime command. You'll see the server has only been up a short time.
  • Keep an existing ssh session active, then shut down the server from the EC2 Management Console, and you will see the same "The server is going down..." notice you would see if you executed the shutdown command.

Also:

  • STOP commands preserve the root EBS volume, and any attached volumes.
  • Root volumes that are associated with a stopped instance will still show as "in-use" in the Management Console
  • EBS-backed instances can be protected against accidental TERMINATION.
  • EBS volumes are destroyed by TERMINATION by default, but they don't have to be. This is a configurable option in most cases.

After startup, check all the system logs in /var/log to look for any errors from attempts to start services, and execute the dmesg command to see what happened on boot.

platforms
  • 1,118
  • 10
  • 23
0

Do you mean that you're putting the system files for your EC2 instances on persistent EBS volumes, rather than using the instance file system which goes away when you stop or restart the instance ?

If so, when you shut down an instance, the files on your EBS volume will be preserved but the files on the other file systems provided by the instance (these used to be / and /mnt, but I'm not sure what happens with an EBS instance) will disappear.

I'm guessing that your services don't start at boot time because they are dependent on files that aren't stored on the EBS volume. The service logs ought to help you debug the problem.

gareth_bowles
  • 9,127
  • 9
  • 34
  • 42
  • No, I'm using the new EBS backed AMI's (vs S3 backed). So the instances can be stopped (paused) without being terminated. It's my understanding they (EBS instances) work more like a physical server. – ahanson Jan 06 '10 at 16:49
  • Interesting - this made me go and look up how the EBS instances work. If you "stop" an instance it looks like it does shut down the instance, but preserves the EBS volume and the instance ID so that you can restart with the same ID (but not necessarily the same internal IP address, apparently). So I don't see why your services wouldn't be restarted when you restart the instance; is there nothing in the service logs or /var/log/messages to give you a clue ? – gareth_bowles Jan 06 '10 at 17:12
0

When you start an EBS-backed instance all of the installed services should start. I start/stop several instances (LAMP servers) every day and apache, mysql, and everything comes right up.

On a few occasions I did have to reboot the instance for a few services to come up. I attribute this to lag connecting to the EBS and therefore not able to reach the appropriate files in time.

daemonofchaos
  • 1,211
  • 1
  • 8
  • 10