10 应该看不见了吧？
但是，看下图：
这里的powershell状态为已终止，而且还占用了一部分cpu呢。
这些powershell生前是这样子的：
|
1 |
do {;}while(1) |
最后，尽管看到了已终止状态的cpu，也不过是昙花一现，很快（10s左右吧）也就没有了
11月 152018
phpor
11月 152018
从下图来看，windows的powershell的死循环程序并没有占用100%的cpu，为什么？
原因： 这里的 12.39*8 ~= 100 ； 因为这个电脑是4核心8线程的，满负荷是800%，将800%折合成100%的话，100%就折合成12.38%左右，所以说，这里的12.38%就是一个核心的意思；
当启动到9个powershell死循环的时候，就不能再保证每个进程占用12%的cpu了：
10月 302018
以前的软件开发非常注重方法，注重质量，软件开发周期长。
现在的软件开发更注重快速迭代。
一个很重要的原因是：
以前的软件多是开发完卖出去的；
现在的软件大多是自己提供线上服务的；
所以：
对于前者，你不可能让客户每天部署一个新版本；
对于后者，发现问题可以及时修正，成本很小。
以前开发软件，更关心能用，可用。至于可维护性并不重要，毕竟复杂的维护还能收更多的维护费用呢。
10月 232018
区块儿是干啥的
真的有些不太适应新版的编辑器
10月 122018
https://blog.csdn.net/xmcy001122/article/details/61623128
freeswitch也叫软电话交换机
freeswitch有docker版本，Windows版本，都非常方便安装
软电话有x-lite，
9月 252018
新装了个 openstack-dashboar 12.0.3 ，切换主题到material总是不成功，直接设置cookie：
theme=material
就可以了
openstack-dashboar 12.0.3似乎没有汉化包
9月 252018
9月 212018
企业的长治久安靠的是制度，企业的发展却要靠人
9月 192018
缘起：
docker stop 时往往会比较慢，起原因多半是docker 容器的init进程没有正确处理信号所致；docker stop的行为为： 先发送一个SIGTERM(15) 信号给init进程，如果一段时间（默认10s）后，依然没有退出，就直接发送 -9 信号，常常我们会登上10s，最终，进程的退出依然是仓促的；所以，实现一个好的init进程非常重要。
想用bash写一个docker 的init进程，当收到SIGTERM信号时，通知容器中的其他进程退出，其他进程退出后自己再退出，这样的话，其他进程可以有时间优雅退出，而且stop操作还可能很快完成。
版本1：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
#!/bin/bash trap stop 15 PATH=$PATH:/usr/sbin/:/usr/bin function stop() { while :; do local pid=$(pidof cmd) [[ "$pid" == "" ]] && break kill $pid 2>/dev/null sleep 1 done exit 0 } cmd |
实际并不凑效； 原因： bash 在执行外部命令的时候，是不处理信号的
改进：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
#!/bin/bash trap stop 15 PATH=$PATH:/usr/sbin/:/usr/bin function stop() { while :; do local pid=$(pidof cmd) [[ "$pid" == "" ]] && break kill $pid 2>/dev/null sleep 1 done } nohup cmd & while :; do sleep 10 done |
不足：当有信号到时，依然要等sleep 睡足才能处理信号，如果每次sleep 时间足够短，则总是启动sleep进程也非常不优雅，本身总是看到一个sleep进程已经够闹心的了
改进：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
#!/bin/bash trap stop 15 PATH=$PATH:/usr/sbin/:/usr/bin function stop() { while :; do local pid=$(pidof cmd) [[ "$pid" == "" ]] && break kill $pid 2>/dev/null sleep 1 done } nohup cmd & while :; do read line done |
优点：
- 看不到sleep函数了
- read line 并不消耗多少资源
- 虽然 read 函数是阻塞的，但是却不影响bash实时处理信号
缺点：
- 创建容器时需要 -it 选项，因为bash标准输入需要是正常的，才能是的read不会失败而正常阻塞，否则，read会一直失败，导致死循环占用100% CPU ; 安全一些的做法是，发现read失败直接退出
测试脚本：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
#!/bin/bash trap signal 15 function signal() { echo handle signal } while :; do read line echo $line sleep 10 done |
执行该脚本，然后发送信号15给bash进程，发现：
- 当执行到sleep 10 的时候，不能实时处理信号
- 当阻塞在read时，可以实时处理信号
9月 142018
Dell OpenManage Server Administrator (OMSA)是一款全面的一对一系统管理解决方案。
OMSA可分为两种：
- 集成式界面 – 基于Web浏览器的图形用户界面(GUI)
- 命令行界面(CLI) – 通过操作系统访问
https://blog.csdn.net/wh211212/article/details/70014141