Author:NinGoo posted on NinGoo.net

在Linux中，如果要让进程在后台运行，一般情况下，我们在命令后面加上&即可，实际上，这样是将命令放入到一个作业队列中了：

$ ./test.sh &
[1] 17208

$ jobs -l
[1]+ 17208 Running                 ./test.sh &

对于已经在前台执行的命令，也可以重新放到后台执行，首先按ctrl+z暂停已经运行的进程，然后使用bg命令将停止的作业放到后台运行：

$ ./test.sh
[1]+  Stopped                 ./test.sh

$ bg %1
[1]+ ./test.sh &

$ jobs -l
[1]+ 22794 Running                 ./test.sh &

但是如上方到后台执行的进程，其父进程还是当前终端shell的进程，而一旦父进程退出，则会发送hangup信号给所有子进程，子进程收到hangup以后也会退出。如果我们要在退出shell的时候继续运行进程，则需要使用nohup忽略hangup信号，或者setsid将将父进程设为init进程(进程号为1)

$ echo $$
21734

$ nohup ./test.sh &
[1] 29016

$ ps -ef | grep test
515      29710 21734  0 11:47 pts/12   00:00:00 /bin/sh ./test.sh
515      29713 21734  0 11:47 pts/12   00:00:00 grep test

$ setsid ./test.sh &
[1] 409

$ ps -ef | grep test
515        410     1  0 11:49 ?        00:00:00 /bin/sh ./test.sh
515        413 21734  0 11:49 pts/12   00:00:00 grep test

上面的试验演示了使用nohup/setsid加上&使进程在后台运行，同时不受当前shell退出的影响。那么对于已经在后台运行的进程，该怎么办呢？可以使用disown命令：

$ ./test.sh &
[1] 2539

$ jobs -l
[1]+  2539 Running                 ./test.sh &

$ disown -h %1

$ ps -ef | grep test
515        410     1  0 11:49 ?        00:00:00 /bin/sh ./test.sh
515       2542 21734  0 11:52 pts/12   00:00:00 grep test

另外还有一种方法，即使将进程在一个subshell中执行，其实这和setsid异曲同工。方法很简单，将命令用括号() 括起来即可：

$ (./test.sh &)

$ ps -ef | grep test
515        410     1  0 11:49 ?        00:00:00 /bin/sh ./test.sh
515      12483 21734  0 11:59 pts/12   00:00:00 grep test

注：本文试验环境为Red Hat Enterprise Linux AS release 4 (Nahant Update 5),shell为/bin/bash，不同的OS和shell可能命令有些不一样。例如AIX的ksh，没有disown，但是可以使用nohup -p PID来获得disown同样的效果。

还有一种更加强大的方式是使用screen，首先创建一个断开模式的虚拟终端，然后用-r选项重新连接这个虚拟终端，在其中执行的任何命令，都能达到nohup的效果，这在有多个命令需要在后台连续执行的时候比较方便：

$ screen -dmS screen_test

$ screen -list
There is a screen on:
        27963.screen_test       (Detached)
1 Socket in /tmp/uscreens/S-jiangfeng.

$ screen -r screen_test

• AIX平台升级到Oracle10.2.0.4的几个问题
• Linux中如何将文件dump成16进制值
• Redhat Linux如何设置用户默认属性
• Oracle10.2.0.4 Linux64版本监听存在多个子进程
• AIX虚拟内存管理机制
• Redhat Linux上Oracle如何启用AIO

PermLink: http://www.ningoo.net/html/2008/how_to_run_processes_on_background_in_linux.html

Add Comments(0) | Follow NinGoo@Twitter | Google Reader

作者:d.c.b.a, 订阅AnySQL, Oracle数据库恢复及服务, Sybase恢复, 磁盘及RAID恢复

    一提到系统监控就会联想到Cacti这个优秀的开源软件, 或用Nagios. 不管什么样的监控软件平台, 监控可做的事大约有四个方面.

    一定的报警机制. 对于特定的事件, 需要用特定的方式(手机, 邮件, 淘宝旺旺等)通知相关人员, 通知的事件大小由监制的机制来决定, 如果是7x24的, 那一般只有交易量下降多少比例时才会报警, 如果不是7x24的, 那么有任何错误发生时都需要报警.

    一定的图表显示. 图表是最好的表现数据趋势的方式, 对于交易量或主机负荷之类的少数重要数据, 用图的方式显示. 缺点是一个屏幕内能提供的信息量比较少, 对于详细诊断问题所在起不了多少帮助.

    很多的详细信息. 用网页方式显示某些方面详细的数据, 如将所有的消息滞留的情况记录下来, 用来查找发生的问题. 更多的如应用中关键的API调用次数, 显示一个当前值和历史平均值, 也可以确定某个点是不是有问题. 非常适合于详细问题的快速确定.

    一定的自动响应机制. 管理出身的会很关注这一点, 是很好的设想, 但不容易实现, 最简单地说表空问不足这个问题吧, 让程序自动加文件? 还是做一个空间预测, 提前加好空间, 个人偏向于后者.

    现在监时做的一些监控就是建立在自已开发的WebChart基础上的, 表格和图形并存的方式. 更适合于白天工作时段的监控, 好好保存一定历史信息, 还可用于事后问题查找.

相关文章 | Related Artiles

我要留言(当前0)

Facebook 其实对待技术的态度其实挺开放的。今天阅读了这篇 Scale Out, 工程师 Jason Sobel 介绍了在对付跨地域 MySQL 复制网络延迟的问题。

Cache 一致性问题解决思路

大量的 MySQL + Memcached 服务器，布署简示：

California (主 Write/Read)............. Virginia (Read Only)

主数据中心在 California ，远程中心在 Virginia 。这两个中心网络延迟就有 70ms，MySQL 数据复制延迟有的时候会达到 20ms. 如果要让只读的信息从 Virginia 端发起，Memcached 的 Cache 数据一致性就是个问题。

1 用户发起更新操作，更名 "Jason" 到 "Monkey" ；
2 主数据库写入 "Monkey"，删除主、从两端 Memcached 中的名字值；
3 在 Virginia 有人查看该用户 Profile ；
4 在 Memcached 中没发现用户名字，从 Virginia  Slave 数据库读取，因为网络延迟，结果读到了 "Jason"；
5 更新 Virginia Memcached 中的该用户名字为 "Jason"；
6 复制追上了，更新名字为 ""Monkey"；
7 又有人读取 Profile 了；
8 在 Memcached 中找到了键值，返回 "Jason" （实际上造成业务冲突了)

解决办法挺有意思，在 SQL 解析层嵌入了针对 Memcached 的操作。

1 用户发起更新操作，更名 "Jason" 到 "Monkey" ；
2 主数据库写入 "Monkey"，删除主端 Memcached 中的名字值，但Virginia 端 Memcached 不删；(这地方在 SQL 解析上作了一点手脚，把更新的操作"示意"给远程)；
3 在 Virginia 有人查看该用户 Profile ；
4 在 Memcached 中找到键值，返回值 "Jason"；
5 复制追上更新 Slave 数据库用户名字为 "Monkey"，删除 Virginia Memcached 中的键值；
6 在 Virginia 有人查看该用户 Profile ；
7 Memcache 中没找到键值，所以从 Slave 中读取，然后得到正确的 "Monkey" 。

这里面的一个简单的原则是: 更新后的数据，用户第一次读取要从数据库读，顺便扔一份到 Cache 里，而不是在写入的时候直接更新 Memcached 。避免写事务过大。

而写操作的原则是：一次写入，到处分发。

第二个问题是关于"Page Routing"的 ，也很有参考价值。感兴趣的自己读一下吧。

--EOF--

另推荐一下: 分布式系统中的一致性和可用性，该文是上次在支付宝 QClub 活动的总结之二。

由于IO的请求不是每次等待完成指令后再发送下一个请求，而是存在于队列中，且遵循FIFO。因此如果遇到存储掉电的情况，就可能会出现数据的不一致。虽然这种情况出现的可能性不大，因为存储中有电池，能保证cache中的信息写到存储中。但是在这里还是提一下数据丢失的风险。

由于我们的异步IO的队列中是针对使用裸设备的IO请求，即redo log、datafile和controlfile，这边分2种情况讨论存储掉电时候，数据的丢失情况（注：以下情况考虑的是cache中的IO请求丢失，但是文件未损坏的情况）：

（1）当记录A insert到表中，已经commit，记录B insert到表中，未commit，此时checkpoint未发生时。此时的IO队列中有insert A的redo请求，insert B的redo请求，但未有buffer向dbfile写的请求。此时掉电，oracle端的情况是oracle认为redo的IO请求已经写到redo log，os端的情况redo的IO请求还没写到redo log中。重启数据库时候之前的oracle端认为redo和dbfiles的scn不一致，需要介质恢复，但是在启动的时候，读取redo log，由于在os级上尚未写入，redo log和dbfiles的scn一致，因此正常启动，但是丢失AB记录。

（2）当记录A insert到表中，已经commit，记录B insert到表中，未commit，此时发生了checkpoint。此时的IO队列中有insert A的redo请求，insert B的redo请求，A记录从db buffer向dbfile写的请求，还有控制文件被更新的请求。当都未写到裸设备时掉电，oracle端的情况是oracle认为redo的IO请求已经写到redo log中，db buffer的请求已经写入了数据文件，控制文件已经被更新，os端的情况是redo的IO请求和写dbfiles的IO请求均未完成，控制文件未更新。重启数据库时，由于scn还是一致的，因此能正常打开，但丢失cache中的A、B记录。

（3）当记录A insert到表中，已经commit，记录B insert到表中，未commit，此时发生了checkpoint。此时的IO队列中有insert A的redo请求，insert B的redo请求，A记录从db buffer向dbfile写的请求，还有控制文件被更新的请求。当redo的请求已经被写入redo log，但是A记录从db buffer向dbfiles写的请求和更新控制文件的请求还没写的时候掉电。Oracle端的情况是oracle认为redo的IO请求已经写到redo log中，db buffer的请求已经写入了数据文件，控制文件已经被更新，os端的情况是redo完成写入redo log，但是dbfiles未写，控制文件未更新。重启数据库，oracle读取了redolog、控制文件、dbfile，发现redo log、dbfile不一样，需要介质恢复。AB数据不丢失。