结论：需要关注是否有bash -c，开发的脚本是否有#!/bin/bash
在测试环境准备中，docker容器初始化的时候，比如通过jenkins或python脚本(paramiko)部署的时候，部署脚本经常需要使用docker exec来执行语句，启停容器内的服务。
由于开发的start.sh脚本使用了相对路径，必须进入路径再执行./start.sh，所以我使用分号隔开先后两条语句执行。例如
docker exec nebula_service0 bash -c "cd /usr/local/sandai/scheduler/sbin; ./start.sh restart; "
这里首先有一个要点，就是 bash后面要带-c ，否则不支持多条命令。所有的命令需要以字符串形式传入，故使用双引号，如果内部的命令需要引号，则需要转义。
第二个要点，在paramiko里，如果不带restart; 最后的分号，就可能看不到最后一个命令执行成功时的输出(有点奇葩)。
结果执行了以后，有的服务能成功。但有的服务会出现没报错，就是服务没重启，执行了命令好像没效果一样。这就尴尬了，真的很影响问题定位~
诡异的是，直接用
docker exec -it nebula_service0 /bin/bash
cd /usr/local/sandai/scheduler/sbin; ./start.sh restart
进到容器里面，然后再执行命令，就表现好好的，没有任何问题
后来经过一番折腾发现，研发的start.sh不是所有的都规范
能够成功的脚本，第一行有
#!/bin/bash
[commands ..]
而不能成功执行的脚本，第一行没有解释器路径，而是直接开始写命令
[commands ..]
所以办法就有两个：
第一个办法，让开发规范脚本，脚本前面都加上#!/bin/bash
第二个办法，使用sh start.sh或bash start.sh代替./start.sh，经测试无需解释器路径
docker exec nebula_service0 bash -c "cd /usr/local/sandai/scheduler/sbin; sh start.sh restart; "
