Linux下可以替换运行中的程序么?
今天被朋友问及“Linux下可以替换运行中的程序么？”，以前依稀记得Linux下是可以的（而Windows就不让），于是随口答道“OK”。结果朋友发来一个执行结果：（test正在运行中）
# cp test2 test
cp: cannot create regular file `test': Text file busy
看起来是程序被占用，无法覆盖。于是自己又再做了几个实验：
（1）先rm删除正在运行的test，然后cp test2 test就没有错误了。
（2）先mv改名正在运行的test，然后cp test2 test也没有问题。
查了查资料并动手分析了一下，找到了比较满意的解释。cp并不改变目标文件的inode，事实上它的实现是这样的：
# strace cp test2 test 2>&1 | grep open.*test
open("test2", O_RDONLY|O_LARGEFILE) = 3
open("test", O_WRONLY|O_TRUNC|O_LARGEFILE) = 4
我原以为cp的实现是“rm + open(O_CREAT)”，不过现在想想上面的实现方式才是最可靠的（保证了时序安全和目标文件的属性）。这也可以解释为什么cp的目标文件会继承被覆盖文件的属性而非源文件。
Linux由于Demand Paging机制的关系，必须确保正在运行中的程序镜像（注意，并非文件本身）不被意外修改，因此内核在启动程序后会锁定这个程序镜像的inode。这就 是为什么cp在用“O_WRONLY|O_TRUNC”模式open目标文件时会失败。而先rm再cp的话，新文件的inode其实已经改变了，原 inode并没有被真正删除，直到内核释放对它的引用。同理，mv只是改变了文件名，其inode不变，新文件使用了新的inode。
问题到这里已经水落石出，不过刨根究底的个性驱使我再做了以下一组实验，没想到结果完全出乎我意料之外！
写了一个简单的测试程序：
#include <stdio.h>
int main(int argc, char * argv[])
{
foo(); // An export function by libtest.so.
sleep(1000);
return 0;
}
foo()是另一个测试动态库libtest.so的导出接口，只打印一行提示就返回。接下来我把上面对执行文件的测试用例对动态库又做了一遍：
（1）cp libtest2.so libtest.so可以直接覆盖已加载的动态库。
（2）先rm删除已加载的libtest.so，然后cp libtest2.so libtest.so成功。
（3）先mv改名已加载的libtest.so，然后cp libtest2.so libtest.so成功。
除了第一个用例外，结果相同。这样看来，动态库被加载时难道ld并没有锁定inode？不过想想也可以宽恕，毕竟ld也是用户态�
相关文档：
什么是等待队列？
在软件开发中任务经常由于某种条件没有得到满足而不得不进入睡眠状态，然后等待条件得
到满足的时候再继续运行，进入运行状态。这种需求需要等待队列机制的支持。
Linux
中提供了等待队列的机制，该机制在
内核中应用很广泛。
&n ......
上一次用linux是2002年用kdevelop及qt库开发多媒体软件。
时隔8年再一次在linux下搞开发，依然菜鸟，还是生疏。
感觉自己的大脑的存储空间，随着年龄的增加在变小，很多弄过的，又只能从头学起。
不过有句话“活到老，学到老”哈！
惭愧，惭愧。
1、编写动态库的c++文件
cvpnlib.cpp cv ......
【实验环境】
Fedora，内核2.6.21.6
【实验步骤】
1. cd /usr/src/linux
2. vi kernel/sys.c
在最后添加如下代码：
asmlinkage long sys_processinfo(void)
{
int num=0;
unsigned long state;
struct task_struct *p;
for_each_process(p)
{
printk("pid=%-5d,name=%-20s",p->tgid,p->co ......
有了系统调用的经验，添加模块还是很顺利的。
【实验环境】
Fedora，内核2.6.21.6
【实验步骤】
1. cd /root/homework/module
2. vi process.c
3. 加入如下代码：
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/module.h>
static int process_init(void)
{
int num= ......
这几天Linux服务器很慢,很着急找不到解决办法!后百度相关字眼,查找到是MySQL的问题,
如下为解决方案
:
连接MySQL速度慢的解决方法.
PHP远程连接MYSQL速度慢,有时远程连接到MYSQL用时4-20秒不等,本地连接MYSQL正常,出现这种问题的主要原因是,默认安装的
MYSQL开启了DNS的反向解析,在MY.CNF(UNIX或LINUX系统下)或MY.INI ......
