我有一台运行Ubuntu 11.10的configurationEC2服务器，在Apache2 / WSGI上运行一个Django应用程序。 这台服务器工作完美，停止和重新启动没有任何问题。
当我克隆这个实例时，它的一切都完全一样。 我没有改变任何有意义的东西。 但是…它不会完全重新启动或停止。 该应用程序运行良好，服务器似乎并没有崩溃…直到我试图重新启动/停止它。
每次尝试停止时，用[OK]消息停止至less需要30到45秒。 我可以马上试着阻止它，它会做同样的事情。 如果我尝试重启，那么它最终会失败，并显示“地址已在使用中”错误。 然后我手动杀死停滞的旧/usr/sbin/apache2 -k start进程以重新启动。 然后，我仍然有4或5个<defunct>过程，在引导的剩余时间内耗尽资源。
我能做些什么来弄清楚为什么会发生这种情况。 这个过程每次都被挂起。 几天来，我一直在抨击这个问题，并不知所措。
============编辑===========
我试图将AMI复制到2个以上的实例，一个MICRO和一个SMALL。 这是非常奇怪的：小实例完美的作品。 MICRO实例具有相同的重新启动问题。 为了validation这一点，我又做了同样的事情（克隆到另一个SMALL和另一个MICRO）。 一样….
Amazon EC2上各种可用实例types之间的显着区别在于， 实例types是否具有Amazon EC2实例存储 （也称为短暂存储 ），以及是否默认情况下已连接，格式化和装入。 具体而言，后者仅适用于m1.small和c1.medium实例，t1.micro实例完全缺less这种types的存储 – 有关实例存储卷的数量和大小，请参见“ 实例存储在实例types中可用” 可用于每个实例types和实例存储设备名称以获取有关映射的更多详细信息：
实例存储卷必须在设备上安装才能使用。 在Linux实例中，取决于实例types，默认情况下，某些实例存储将由Amazon构build映像进行格式化和装载。 Windows实例使用内置工具EC2Config服务来格式化并挂接连接到该实例的所有实例存储。
因此，根据您的设置，可能会有操作系统/服务configuration工件，假设存储在/mnt下可用，实际上不存在缺less该存储的此实例的克隆，例如：
PID ）存在，如果没有它，显然会失败。 也许尝试与PidFile指令午餐服务器
如果它与非标准的pid文件一起工作，则查看所创build的默认日志文件的权限。