我有一个我正在准备的Vagrant框，以及一个shell脚本作为配置文件。我花了几天的时间才开始工作，现在看起来很稳定和完整。基础盒子是Ubuntu 12.04（32位），在VM上运行Postgres，Redis和Memcached。配置脚本设置Nginx配置，创建一个空白数据库，并进行一些基本的管理。Vagrant配置脚本在VM完全启动之前运行？
当我开始打包虚拟机，并尝试在家中的其他机器上重新运行虚拟机时，我在第一次运行时遇到了问题（vagrant up），因此没有任何服务正在运行 - 所以我的试图运行dropdb或createdb失败。
挖掘为什么发生这种情况（我是一个前Windows的家伙，所以这需要做一些）我发现自己在运行水平和/etc/rc[0-6,S].d文件的肠子。
我有三个服务我感兴趣的相关S（启动）文件：
[email protected]:~$ ls -l /etc/rc2.d
total 4
-rw-r--r-- 1 root root 677 Apr 14 2012 README
lrwxrwxrwx 1 root root 20 Dec 29 10:05 S19postgresql -> ../init.d/postgresql
lrwxrwxrwx 1 root root 19 Dec 29 10:05 S20memcached -> ../init.d/memcached
lrwxrwxrwx 1 root root 15 Dec 29 10:05 S20nginx -> ../init.d/nginx
lrwxrwxrwx 1 root root 22 Dec 29 10:05 S20redis-server -> ../init.d/redis-server
...
和K文件运行级别0（停机），所以一切似乎为了：
[email protected]:~$ ls -l /etc/rc0.d
total 4
lrwxrwxrwx 1 root root 19 Dec 29 10:05 K20memcached -> ../init.d/memcached
lrwxrwxrwx 1 root root 15 Dec 29 10:05 K20nginx -> ../init.d/nginx
lrwxrwxrwx 1 root root 22 Dec 29 10:05 K20redis-server -> ../init.d/redis-server
lrwxrwxrwx 1 root root 20 Dec 29 10:05 K21postgresql -> ../init.d/postgresql
....
这似乎表明底层VM运行级别不是2，因此为了调试此问题，我创建了一个新的供应脚本来输出。）供应时的运行级别，以及b。）预期进程是否正在运行（memcache，prostgres，redis）：
ps aux | grep memcache
ps aux | grep postgres
ps aux | grep redis
# expected output is 'N 2'
runlevel
我跑vagrant destroy，然后vagrant up这个，结果如下：
[default] Running provisioner: Vagrant::Provisioners::Shell...
root 791 0.0 0.2 4624 840 ? S 10:33 0:00 grep memcache
root 793 0.0 0.2 4624 836 ? S 10:33 0:00 grep postgres
root 795 0.0 0.2 4624 840 ? S 10:33 0:00 grep redis
unknown
即服务没有在配置脚本运行，更容易混淆的时间运行， runlevel命令甚至不被识别。
如果我在正在运行的VM上重复运行配置脚本，使用vagrant provision，我在运行它的前几次得到相同的结果，然后最终（2-3分钟后）看到我有什么预计第一次轮：
[default] Running provisioner: Vagrant::Provisioners::Shell...
memcache 1103 0.2 0.2 46336 1072 ? Sl 10:56 0:00 /usr/bin/memcached -m 64 -p 11211 -u memcache -l 127.0.0.1
root 1267 0.0 0.2 4624 840 ? S 10:56 0:00 grep memcache
postgres 1073 13.0 2.0 50440 7828 ? S 10:56 0:02 /usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgresql/9.1/main -c config_file=/etc/postgresql/9.1/main/postgresql.conf
postgres 1077 0.3 0.3 50440 1248 ? Ss 10:56 0:00 postgres: writer process
postgres 1078 0.3 0.3 50440 1244 ? Ss 10:56 0:00 postgres: wal writer process
postgres 1079 0.1 0.6 50860 2296 ? Ss 10:56 0:00 postgres: autovacuum launcher process
postgres 1080 0.0 0.3 20640 1284 ? Ss 10:56 0:00 postgres: stats collector process
root 1269 0.0 0.2 4624 836 ? S 10:56 0:00 grep postgres
redis 1123 0.6 0.2 3292 1036 ? Ss 10:56 0:00 /usr/bin/redis-server /etc/redis/redis.conf
root 1271 0.0 0.2 4624 840 ? S 10:56 0:00 grep redis
N 2
看起来它只是采取一切一点时间上来，这是有道理的，hwoever提出了我一个巨大的问题，该配置脚本将总是失败第一时间。
这是一个已知的情况，如果是这样，解决方案是什么？理想情况下，配置脚本会暂停，直到运行级别变为2，即该框已准备好接受shell命令。
[更新：HACK]
我设法通过黑客在一起下面的脚本来解决此问题：
while [ "`runlevel`" = "unknown" ]; do
echo "runlevel is 'unknown' - waiting for 10s"
sleep 10
done
echo "runlevel is now valid ('`runlevel`'), kicking off provisioning..."
我已经保存了该为“预规定。SH”和我的Vagrantfile现在看起来像：
# Enable provisioning with a shell script.
config.vm.provision :shell, :path => "pre-provision.sh"
config.vm.provision :shell, :path => "provision.sh", :args => "myapp"
其给出以下输出中：
[default] Running provisioner: Vagrant::Provisioners::Shell...
runlevel is 'unknown' - waiting for 10s
runlevel is 'unknown' - waiting for 10s
runlevel is 'unknown' - waiting for 10s
runlevel is 'unknown' - waiting for 10s
runlevel is 'unknown' - waiting for 10s
runlevel is 'unknown' - waiting for 10s
runlevel is 'unknown' - waiting for 10s
runlevel is 'unknown' - waiting for 10s
runlevel is 'unknown' - waiting for 10s
runlevel is 'unknown' - waiting for 10s
runlevel is 'unknown' - waiting for 10s
runlevel is now valid ('N 2'), kicking off provisioning...
[default] Running provisioner: Vagrant::Provisioners::Shell...
...
然后与原provision.sh运行，一切OK。
我没有这个标记为答案（虽然它是一个答案），因为我还是想知道我应该做的 - 这绝不是它的工作原理，肯定的方式吗？