LUPA 是开源高校推进联盟( Leadership Of Open Source University Promotion Alliance )的 英文缩写,于 2005 年 6 月 12 日 在杭州成立。
什么是云计算
最近,大公司如MS、Google、IBM等都在炒作一个概念就是云计算,如IBM跟欧盟 合作开展云计算,欧盟拨款1.7亿万欧元;Google与IBM 联合力推云计算模式;Yahoo! 也把宝押在了云计算上;我国也在无锡 跟IBM公司联合建立了一个云计算中心;有人说微软收购Yahoo!一个重要的考虑就是在Yahoo在云计算方面的领先地位,多少有点儿道理。那么,什么是云计算哪?我看到有一位推广自由开源的老先生把云计算(Cloud Computing)翻译成“云雾计算”着实是可笑,好多网友也在问什么是云计算,什么是雾计算,说明好多人对于云计算是一头雾水。云计算可不是“云雨”,可不是云山雾罩。
“云计算”(Cloud Computing)是分布式处理(Distributed Computing)、并行处理(Parallel Computing)和网格计算(Grid Computing)的发展,或者说是这些计算机科学概念的商业实现。许多跨国信息技术行业的公司如IBM、Yahoo和Google等正在使用云计算的概念兜售自己的产品和服务。云计算这个名词可能是借用了量子物理中的“电子云”(Electron Cloud),强调说明计算的弥漫性、无所不在的分布性和社会性特征。量子物理上有“电子云(electron cloud)”,在原子核周围运动的电子不是一个经验世界的轨道例如像天体一样的运行轨道,而是弥漫空间的、云状的存在,描述电子的运动不是牛顿经典力学而是一个概率分布的密度函数,用薛定谔波动方程来描述,特定的时间内粒子位于某个位置的概率有多大,这跟经典力学的提法完全不同。电子云有以下特性,概然性、弥漫性、同时性等等,云计算可能的确是来自电子云的概念,前今年就有所谓“无所不在的计算”,IBM有一个无所不在的计算叫“Ubiquitous “,MS(Bill)不久也跟着提出一个无所不在的计算“Pervade“,现在人们对无所不在的计算又有了新的认识,现在说是”Omnipresent “。但是,云计算的确不是纯粹的商业炒作,的确会改变信息产业的格局,现在许多人已经用上了Google Doc和Google Apps,用上了许多远程软件应用如Office字处理而不是用自己本地机器上安装这些应用软件,以后谁还会花钱买Office软件哪?还有许多企业应用如电子商务应用,例如要写一个交易程序,Google的企业方案就包含了现成的模板,一个销售人员根本没学习过Netbeanr也能做出来。这种计算和产业动向是符合开源精神的,符合SaaS(Software as a Service)趋势。现在有这样的说法,当今世界只有五台计算机,一台是Google的,一台是IBM的,一台是Yahoo的,一台是Amazon的,一台是微软的,因为这五个公司率先在分布式处理的商业应用上捷足先登引领潮流。Sun公司很早就提出说“网络就是计算机”是有先见之明的。
有以下五个主要原因使得分布式计算必然会越来越普遍,逐渐发展成主流的计算模式而取代集中式的大型计算机:
- 现在分布式系统的第一个原因就是因为他具有比集中式系统更好的性能价格比。你不要花几十万美元就能获得高效能计算。
- 多数应用本身就是分布式的。如工业企业应用,管理部门和现场不在同一个地方。
- 高可靠性。冗余不仅是生物进化的必要条件,而且也是信息技术。现代分布式系统具有高度容错机制,控制核反应堆主要采用分布式来实现高可靠性。
- 可扩展性。买一台性能更高的大型机,或者再买一台性能相同的大型机的费用都比添加几台PC的费用高得多。
- 高度灵活性。能够兼容不同硬件厂商的产品,兼容低配置机器和外设而获得高性能计算。
粗略地计算,目前的个人计算机每个CPU芯片的处理能力是200MIPS,就是每秒种执行
按照计算机操作系统的宗师Andrew S. Tanenbaum(AST)给分布式系统的的定义:“分布式系统是这样的系统,它运行在不具有共享内存的多台机器上,但在用户的眼里却像是一台计算机”。(引自《现代操作系统》,机械工业出版社,1999年中文版)。它的目标是让每个用户感觉联网的计算机是一个分时系统——就像使用个人计算机一样 ——而不是一个由许多计算机联合起来的集体,即使由五个节点组成的分布式系统也应该让用户感觉自己是在使用一台价值20万美元的大型计算机,唯一不寻常的感觉是处理速度提高了许多,别的没有什么不同。例如,这里有一个简单的例子,在机器A的用户要使用安装在机器B上用户的目录里的文件,A用户要使用远程登录命令rlogin B登录到机器B的目录上,那么这就不是一个真正的分布式系统,因为用户A意识到了另外一台机器的存在,分布式系统必须要做到,用户A登录到一个目录上的时候不知道自己是在本地机器上还是在远程机器上的目录上,对于用户A来说机器B是透明的,这就是分布式系统设计时考虑的“透明性”要求。其他有关的问题包括:分布式文件系统的问题,目录和文件访问机制以及一致性问题,分布式系统进程的通信问题等等。目前的云计算严格说还没有到达真正的分布式计算的语义学水平。
LCC编译器的源程序分析(64)符号表的结构注释
经典评论:垃圾收集机制(Garbage Collection)
垃圾收集机制(Garbage Collection)批判
在Java版发表这篇文章,似乎有点把矛头指向Java了。其实不是,GC是所有新一代语言共有的特征,
Python, Eiffel,C#,Roby等无一例外地都使用了GC机制。但既然Java中的GC最为著名,所以天塌
下来自然应该抗着。
这篇短文源于comp.lang.java.programmer跟comp.lang.C++上发生的一场大辩论,支持C++和Java
的两派不同势力展开了新世纪第一场冲突,跟贴发言超过350,两派都有名角压阵。C++阵营的擂主是
Pete Becker,ACM会员,Dinkumware Ltd. 的技术副总监。此君精通C++和Java,开发过两种语言的
核心类库,但是却对C++狂热之极,而对于Java颇不以为然。平时谈到Java的时候还好,一旦有人胆
敢用Java来批判C++,立刻忍不住火爆脾气跳将出来,以坚韧不拔的毅力和大无畏精神与对手周旋,
舌战群儒,哪怕只剩下一个人也要血战到底。这等奇人当真少见!我真奇怪他整天泡在usenet上,
不用工作么?他的老板P.J. Plauger如此宽宏大量?Java阵营主角是一个网名Razzi的兄弟,另外有
Sun公司大名鼎鼎的Peter van der Linden助阵,妙语连珠,寸土必争,加上人多势众,一度占据优势。
C++阵营里大拿虽然很多,但是大多数没有Pete那么多闲工夫,例如Greg Comeau,Comeau公司老板,
每次来个只言片语,实在帮不了Pete多大忙。但是自从C++阵营中冒出一个无名小子,网名Courage(勇气),
发动对Java GC机制的批判,形势为之一变。C++阵营眼下处于全攻之势,Java阵营疲于防守,只能
招架说:"你们没有证据,没有统计资料",形势很被动。
垃圾收集(GC)不是一直被Java fans用来炫耀,引以为傲的优点么?怎么成了弱点了?我大惑不解,定睛
一看,才觉得此中颇有道理。
首先,Java Swing库存在大量资源泄漏问题,这一点SUN非常清楚,称之为bugs,正在极力修正。但是看来
这里的问题恐怕不仅是库编写者的疏忽,可能根源在于深层的机制,未必能够轻易解决,搞不好要伤筋动骨。
不过这个问题不是那么根本,C++阵营觉得如果抓住对方的弱点攻击,就算是占了上风也没什么说服力。谁
没有缺点呢?于是反其道而行之,猛烈攻击Java阵营觉得最得意的东西,Java的GC机制本身。
首先来想一想,memory leak到底意味着什么。在C++中,new出来的对象没有delete,这就导致了memory
leak。但是C++早就有了克服这一问题的办法–smart pointer。通过使用标准库里设计精致的auto_ptr
以及各种STL容器,还有例如boost库(差不多是个准标准库了)中的四个smart pointers,C++程序员只要
花上一个星期的时间学习最新的资料,就可以拍着胸脯说:"我写的程序没有memory leak!"。
相比之下,Java似乎更优秀,因为从一开始你就不用考虑什么特殊的机制,大胆地往前new,自有GC替你
收拾残局。Java的GC实际上是JVM中的一个独立线程,采用不同的算法策略来收集heap中那些不再有
reference指向的垃圾对象所占用的内存。但是,通常情况下,GC线程的优先级比较低,只有在当前程序
空闲的时候才会被调度,收集垃圾。当然,如果JVM感到内存紧张了,JVM会主动调用GC来收集垃圾,获取
更多的内存。请注意,Java的GC工作的时机是:1. 当前程序不忙,有空闲时间。2. 空闲内存不足。
现在我们考虑一种常见的情况,程序在紧张运行之中,没哟空闲时间给GC来运行,同时机器内存很大,
JVM也没有感到内存不足,结果是什么?对了,GC形同虚设,得不到调用。于是,内存被不断吞噬,而那些
早已经用不着的垃圾对象仍在在宝贵的内存里睡大觉。例如:
class BadGc {
public void job1() {
String garbage = "I am a garbage, and just sleeping in your precious memory, " +
"how do you think you can deal with me? Daydreaming! HAHA!!!";
….
}
public void job2() {…}
…
…
public void job1000() {…}
public static void main(String[] args) {
bgc = new BadGc();
bgc.job1();
bgc.job2();
…
bgc.job1000();
}
}
运行中,虽然garbage对象在离开job1()之后,就再也没有用了。但是因为程序忙,内存还够用,所以GC得
不到调度,garbage始终不会被回收,直到程序运行到bgc.job1000()时还躺在内存里嘲笑你。没辙吧!
好了,我承认这段程序很傻。但是你不要以为这只是理论上的假设,恰恰相反,大多数实用中的Java程序都有
类似的效应。这就是为什么Java程序狂耗内存,而且好像给它多少内存吃都不够。你花上大笔的银子把内存
从128升到256,再升到512,结果是,一旦执行复杂任务,内存还是被轻易填满,而且多出来的这些内存只是
用来装垃圾,GC还是不给面子地千呼万唤不出来。等到你的内存终于心力交瘁,GC才姗姗来迟,收拾残局。而
且GC工作的方式也很不好评价,一种方法是一旦有机会回收内存,就把所有的垃圾都回收。你可以想象,这要
花很长时间(几百M的垃圾啊!),如果你这时侯正在压下开炮的按钮,GC却叫了暂定,好了,你等死吧!另一
种方法,得到机会之后,回收一些内存,让JVM感到内存不那么紧张时就收手。结果呢,内存里始终有大批垃
圾,程序始终在半死不活的荡着。最后,GC可以每隔一段时间就运行一次,每次只回收一部分垃圾,这是现在
大部分JVM的方式,结果是内存也浪费了,还动不动暂停几百毫秒。难啊!
反过来看看C++利用smart pointer达成的效果,一旦某对象不再被引用,系统刻不容缓,立刻回收内存。这
通常发生在关键任务完成后的清理(cleanup)时期,不会影响关键任务的实时性,同时,内存里所有的对象
都是有用的,绝对没有垃圾空占内存。怎么样?传统、朴素的C++是不是更胜一筹?
据统计,目前的Java程序运行期间占用的内存通常为对应C++程序的4-20倍。除了其它的原因,上面所说的是一个
非常主要的因素。我们对memory leak如此愤恨,不就是因为它导致大量的内存垃圾得不到清除吗?如果有了
GC之后,垃圾比以前还来势汹汹,那么GC又有什么好处呢?
当然,C++的smart pointer现在会使用的人不多,所以现在的C++程序普遍存在更严重的memory leak问题。
但是,如果我奶奶跟舒马赫比赛车输掉了,你能够埋怨那辆车子么?
关于 VirtualBox
VirtualBox是德国一家软件公司InnoTek所开发的虚拟系统软件,它不仅具有丰富的特色,而且性能也很优异。更是开源的,成为了一个发布在GPL许可之下的自由软件。VirtualBox 可以在 Linux 和 Windows 主机中运行,并支持在其中安装 Windows (NT4.0、2000、XP、Server 2003、vista)、DOS/Windows 3.x、Linux (2.4 和 2.6)、OpenBSD 等系列的客户操作系统。
sed 命令使用笔记
好久没有用过sed命令了,网上有很多实例,但是想用熟练也没那么容易,这不今天有一个小小的需求想把sed拿出来用用,就遇到了麻烦:
问题:替换掉行首的一个单词,即该单词挨着的一个tab字符
解决方法:
1. 用awk来完成的:
命令:awk -F"\t" ‘{sub($1"\t",""); print $0}’ src.txt
心得:我开始以为$1和"\t" 中间需要加号连接的,所以就没有达到目的,改用了sed
2. 用sed来完成:
命令: sed s’/^\S\{1,\}\t//’ src.txt
心得: 其中的\{1,\}如果用+表示,也需要斜线转义,但是我没有转义,所以试了n遍都是错的,即可以这样:
命令: sed s’/^\S\+\t//’ src.txt
心得: 这里主要注意一个转义的问题
如何剖析可执行的二进制文件
文本文件一般谁都看得懂,但是遇到二进制文件很多人会无从下手,下面我介绍几个解密二进制文件的方法:
1. strings 这个命令看起来很简单,实际很有用,如果某些敏感的字符串(如:密码)直接写到了二进制文件中,使用strings 再配以grep 就很容易找到那些敏感的字符串了。注意:知道很容易,但是养成这种习惯、能够灵活运用却需要时间
2. ldd 查看动态的二进制文件用到的动态库,在Linux写实比较关心这个的,有时候文件不能执行就是因为需要的动态库不存在
3. nm 查看二进制文件的符号表,该命令可以了解二进制文件用到了哪些函数
4. strace 该命令可以跟踪二进制文件的执行过程,实际上还可以跟踪一个已经启动了的进程,灵活运用是你受益无穷
让程序产生一个段错误
有时候为了调试程序,需要自己写脚本主动产生一个段错误来查看程序的表现,下面是一个很简单的产生段错误的例子:
|
本来有strcpy(NULL,"aaa"); 就够了,但是我却发现如果命令行里执行,看不见产生段错误上面的输出,如果是作为cgi在apache中访问,可以看到段错误上面的输出,不明白
Linux && Unix 调试三把利剑:strace truss ltrace
strace 命令是一种强大的工具,它能够显示所有由用户空间程序发出的系统调用。
strace 显示这些调用的参数并返回符号形式的值。strace 从内核接收信息,而且不需要以任何特殊的方式来构建内核。
下面记录几个常用 option .
1 -f -F选项告诉strace同时跟踪fork和vfork出来的进程
2 -o xxx.txt 输出到某个文件。
3 -e execve 只记录 execve 这类系统调用
—————————————————
进程无法启动,软件运行速度突然变慢,程序的"SegmentFault"等等都是让每个Unix系统用户头痛的问题,
本文通过三个实际案例演示如何使用truss、strace和ltrace这三个常用的调试工具来快速诊断软件的"疑难杂症"。
truss和strace用来跟踪一个进程的系统调用或信号产生的情况,而 ltrace用来跟踪进程调用库函数的情况。truss是早期为System V R4开发的调试程序,包括Aix、FreeBSD在内的大部分Unix系统都自带了这个工具;
而strace最初是为SunOS系统编写的,ltrace最早出现在GNU/DebianLinux中。
这两个工具现在也已被移植到了大部分Unix系统中,大多数Linux发行版都自带了strace和ltrace,而FreeBSD也可通过Ports安装它们。
你不仅可以从命令行调试一个新开始的程序,也可以把truss、strace或ltrace绑定到一个已有的PID上来调试一个正在运行的程序。三个调试工具的基本使用方法大体相同,下面仅介绍三者共有,而且是最常用的三个命令行参数:
-f :除了跟踪当前进程外,还跟踪其子进程。
-o file :将输出信息写到文件file中,而不是显示到标准错误输出(stderr)。
-p pid :绑定到一个由pid对应的正在运行的进程。此参数常用来调试后台进程。
使用上述三个参数基本上就可以完成大多数调试任务了,下面举几个命令行例子:
truss -o ls.truss ls -al: 跟踪ls -al的运行,将输出信息写到文件/tmp/ls.truss中。
strace -f -o vim.strace vim: 跟踪vim及其子进程的运行,将输出信息写到文件vim.strace。
ltrace -p 234: 跟踪一个pid为234的已经在运行的进程。
三个调试工具的输出结果格式也很相似,以strace为例:
brk(0) = 0×8062aa8
brk(0×8063000) = 0×8063000
mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0×92f) = 0×40016000
每一行都是一条系统调用,等号左边是系统调用的函数名及其参数,右边是该调用的返回值。 truss、strace和ltrace的工作原理大同小异,都是使用ptrace系统调用跟踪调试运行中的进程,详细原理不在本文讨论范围内,有兴趣可以参考它们的源代码。
举两个实例演示如何利用这三个调试工具诊断软件的"疑难杂症":
案例一:运行clint出现Segment Fault错误
操作系统:FreeBSD-5.2.1-release
clint是一个C++静态源代码分析工具,通过Ports安装好之后,运行:
# clint foo.cpp
Segmentation fault (core dumped)
在Unix系统中遇见"Segmentation Fault"就像在MS Windows中弹出"非法操作"对话框一样令人讨厌。OK,我们用truss给clint"把把脉":
# truss -f -o clint.truss clint
Segmentation fault (core dumped)
# tail clint.truss
739: read(0×6,0×806f000,0×1000) = 4096 (0×1000)
739: fstat(6,0xbfbfe4d0) = 0 (0×0)
739: fcntl(0×6,0×3,0×0) = 4 (0×4)
739: fcntl(0×6,0×4,0×0) = 0 (0×0)
739: close(6) = 0 (0×0)
739: stat("/root/.clint/plugins",0xbfbfe680) ERR#2 ‘No such file or directory’
SIGNAL 11
SIGNAL 11
Process stopped because of: 16
process exit, rval = 139
我们用truss跟踪clint的系统调用执行情况,并把结果输出到文件clint.truss,然后用tail查看最后几行。
注意看clint执行的最后一条系统调用(倒数第五行):stat("/root/.clint/plugins",0xbfbfe680) ERR#2 ‘No such file or directory’,问题就出在这里:clint找不到目录"/root/.clint/plugins",从而引发了段错误。怎样解决?很简单: mkdir -p /root/.clint/plugins,不过这次运行clint还是会"Segmentation Fault"9。继续用truss跟踪,发现clint还需要这个目录"/root/.clint/plugins/python",建好这个目录后 clint终于能够正常运行了。
案例二:vim启动速度明显变慢
操作系统:FreeBSD-5.2.1-release
vim版本为6.2.154,从命令行运行vim后,要等待近半分钟才能进入编辑界面,而且没有任何错误输出。仔细检查了.vimrc和所有的vim脚 本都没有错误配置,在网上也找不到类似问题的解决办法,难不成要hacking source code?没有必要,用truss就能找到问题所在:
# truss -f -D -o vim.truss vim
这里-D参数的作用是:在每行输出前加上相对时间戳,即每执行一条系统调用所耗费的时间。我们只要关注哪些系统调用耗费的时间比较长就可以了,用less仔细查看输出文件vim.truss,很快就找到了疑点:
735: 0.000021511 socket(0×2,0×1,0×0) = 4 (0×4)
735: 0.000014248 setsockopt(0×4,0×6,0×1,0xbfbfe3c8,0×4) = 0 (0×0)
735: 0.000013688 setsockopt(0×4,0xffff,0×8,0xbfbfe2ec,0×4) = 0 (0×0)
735: 0.000203657 connect(0×4,{ AF_INET 10.57.18.27:6000 },16) ERR#61 ‘Connection refused’
735: 0.000017042 close(4) = 0 (0×0)
735: 1.009366553 nanosleep(0xbfbfe468,0xbfbfe460) = 0 (0×0)
735: 0.000019556 socket(0×2,0×1,0×0) = 4 (0×4)
735: 0.000013409 setsockopt(0×4,0×6,0×1,0xbfbfe3c8,0×4) = 0 (0×0)
735: 0.000013130 setsockopt(0×4,0xffff,0×8,0xbfbfe2ec,0×4) = 0 (0×0)
735: 0.000272102 connect(0×4,{ AF_INET 10.57.18.27:6000 },16) ERR#61 ‘Connection refused’
735: 0.000015924 close(4) = 0 (0×0)
735: 1.009338338 nanosleep(0xbfbfe468,0xbfbfe460) = 0 (0×0)
vim试图连接10.57.18.27这台主机的6000端口(第四行的connect()),连接失败后,睡眠一秒钟继续重试(第6行的 nanosleep())。以上片断循环出现了十几次,每次都要耗费一秒多钟的时间,这就是vim明显变慢的原因。可是,你肯定会纳闷:"vim怎么会无 缘无故连接其它计算机的6000端口呢?"。问得好,那么请你回想一下6000是什么服务的端口?没错,就是X Server。看来vim是要把输出定向到一个远程X Server,那么Shell中肯定定义了DISPLAY变量,查看.cshrc,果然有这么一行:setenv DISPLAY ${REMOTEHOST}:0,把它注释掉,再重新登录,问题就解决了。
案例三:用调试工具掌握软件的工作原理
操作系统:Red Hat Linux 9.0
用调试工具实时跟踪软件的运行情况不仅是诊断软件"疑难杂症"的有效的手段,也可帮助我们理清软件的"脉络",即快速掌握软件的运行流程和工作原理,不 失为一种学习源代码的辅助方法。下面这个案例展现了如何使用strace通过跟踪别的软件来"触发灵感",从而解决软件开发中的难题的。
大家都知道,在进程内打开一个文件,都有唯一一个文件描述符(fd:file descriptor)与这个文件对应。而本人在开发一个软件过程中遇到这样一个问题:
已知一个fd,如何获取这个fd所对应文件的完整路径?不管是Linux、FreeBSD或是其它Unix系统都没有提供这样的API,怎么办呢?我们 换个角度思考:Unix下有没有什么软件可以获取进程打开了哪些文件?如果你经验足够丰富,很容易想到lsof,使用它既可以知道进程打开了哪些文件,也 可以了解一个文件被哪个进程打开。好,我们用一个小程序来试验一下lsof,看它是如何获取进程打开了哪些文件。lsof: 显示进程打开的文件。
/* testlsof.c */
#include #include #include #include #include
int main(void)
{
open("/tmp/foo", O_CREAT|O_RDONLY); /* 打开文件/tmp/foo */
sleep(1200); /* 睡眠1200秒,以便进行后续操作 */
return 0;
}
将testlsof放入后台运行,其pid为3125。命令lsof -p 3125查看进程3125打开了哪些文件,我们用strace跟踪lsof的运行,输出结果保存在lsof.strace中:
# gcc testlsof.c -o testlsof
# ./testlsof &
[1] 3125
# strace -o lsof.strace lsof -p 3125
我们以"/tmp/foo"为关键字搜索输出文件lsof.strace,结果只有一条:
# grep ‘/tmp/foo’ lsof.strace
readlink("/proc/3125/fd/3", "/tmp/foo", 4096) = 8
原来lsof巧妙的利用了/proc/nnnn/fd/目录(nnnn为pid):Linux内核会为每一个进程在/proc/建立一个以其pid为名 的目录用来保存进程的相关信息,而其子目录fd保存的是该进程打开的所有文件的fd。目标离我们很近了。好,我们到/proc/3125/fd/看个究 竟:
# cd /proc/3125/fd/
# ls -l
total 0
lrwx—— 1 root root 64 Nov 5 09:50 0 -> /dev/pts/0
lrwx—— 1 root root 64 Nov 5 09:50 1 -> /dev/pts/0
lrwx—— 1 root root 64 Nov 5 09:50 2 -> /dev/pts/0
lr-x—— 1 root root 64 Nov 5 09:50 3 -> /tmp/foo
# readlink /proc/3125/fd/3
/tmp/foo
答案已经很明显了:/proc/nnnn/fd/目录下的每一个fd文件都是符号链接,而此链接就指向被该进程打开的一个文件。我们只要用readlink()系统调用就可以获取某个fd对应的文件了,代码如下:
#include #include #include #include #include #include
int get_pathname_from_fd(int fd, char pathname[], int n)
{
char buf[1024];
pid_t pid;
bzero(buf, 1024);
pid = getpid();
snprintf(buf, 1024, "/proc/%i/fd/%i", pid, fd);
return readlink(buf, pathname, n);
}
int main(void)
{
int fd;
char pathname[4096];
bzero(pathname, 4096);
fd = open("/tmp/foo", O_CREAT|O_RDONLY);
get_pathname_from_fd(fd, pathname, 4096);
printf("fd=%d; pathname=%sn", fd, pathname);
return 0;
}
出于安全方面的考虑,在FreeBSD 5 之后系统默认已经不再自动装载proc文件系统,因此,要想使用truss或strace跟踪程序,你必须手工装载proc文件系统:mount -t procfs proc /proc;或者在/etc/fstab中加上一行:
proc /proc procfs rw 0 0
—————————————————————-补充——————————————————————
strace 同时跟踪多个进程的用法:strace -o a.strace -f -F -p 4579 -p 4580 -p 4581
虽然我的httpd子进程才10个,但是我发一个请求,还不清楚由哪个进程来处理呢,所以跟踪很难以进行,突发奇想,strace能跟踪子进程,那么能同时跟踪 多个 进程吗?给-p 多写几个参数,不行,换一个写法,如:
strace -o a.strace -f -F -p 4579 -p 4580 -p 4581
果然可以同时跟踪多个进程了,太爽了
这样做的好处是: 我可以同时跟踪apache的父进程和所有子进程(调试的时候限制子进程的个数),这样就知道apache是怎么处理每个请求的了,顺序都很明了
Cron 里是如何发邮件的
曾经只知道Cron 里的任务出错时会发邮件的,但是至于如何发的却怎么也弄不明白,虽然早知道了strace命令,但是还是用的不够灵活,今天突然想到strace一下crond进程,兴许可以看到些感兴趣的东西,但是仅仅strace -o a.txt -p pid 却看不到什么有意思的东西,大抵有意思的东西都在cron fork出来的进程里了吧,记得strace是可以跟踪子进程的,但是没有用过,man了一下,原来是 -f 选项,于是:
strace -o a.txt -f -p pid
tail -f a.txt 果然看到cron是通过sendmail来发邮件的,原语句为:
execve("/usr/sbin/sendmail", ["/usr/sbin/sendmail", "-FCronDaemon", "-i", "-odi", "-oem", "-oi", "-t"], [/* 6 vars */]) = 0