无意间发现的：

我的Wordpress在CentOS5/php5.1的时候，内存使用绝对不至12.59M，印象中是30M至50M之间……迁移到CentOS6上之后，内存使用降低到12.59M了！

• PHP Version : 5.3.2 / 64Bit OS
• Memory limit : 128 MByte
• Memory usage : 12.59 MByte

udisks-daemon服务启动的情况下，当有U盘插入系统时，会自动挂载U盘等removeable设备。

有时udisk-daemon会出错，比如插上移动硬盘后，没有自动挂载，这时可以先dmesg一下，查到刚挂载的设备文件，比如/dev/sdb，ls /dev/sdb* 可以看到sdb1设备（我的移动硬盘只有一个分区），然后手动挂载：

$udisks –mount /dev/sdb1

假如要拨掉移动硬盘，可以先

$udisks –unmount /dev/sdb1

$udisks –detach /dev/sdb

然后就可以拨盘了。

经过分析发现：libcurl和 wget都使用了glibc提供的 getaddrinfo()来解析域名的IP地址。RHEL5(应该其它版本也如此)系统上glibc 实现的getaddrinfo函数，遵循了RFC3484第三章第九条规则对于解析地址排序的 规定，即解析出来的IP地址依照与发起请求的源地址的最长匹配前缀排序。简单的说，与发起请求的机器在同一个子网的IP会被优先选取。

要解决这个问题，可以通过/etc/gai.conf来改变getaddrinfo函数的行为。

man gai.conf查询详细信息。

这里有一程序，可以测试getaddrinfo()与gethostbyname()时解析的命中情况，可用于测试、观察这个现象。

http://daniel.haxx.se/roundrobin.c

puppet-2.6.6.tar.gz中的conf/redhat/目录下包含了一个puppet.spec文件，经过简单的修改，就可又直接用来制作rpm包了。

我的当前环境是RHEL-5.7，x86_64。

1. 准备自己的打包环境

确认系统上有rpmbuild命令可用，没有的话，安装rpm-build包。
建议使用个人账号打包，这样需要先初始化一个自己的打包环境：
在自己的home目录建一个rpmbuld目录，

$cd ~
$mkdir rpmbuild
$mkdir rpmbuild/{SOURCES,SPECS,SRPMS,RPMS,BUILD}

然后，在自己的home目录下建一个.rpmmacros 文件，内容如下：
%_topdir    %(echo $HOME)/rpmbuild

对于这次要打包的puppet，puppet.spec中依赖一个rhel宏，你可以写在.rpmmacros文件里，也可以rpmbuild -D ‘rhle 5′这样在打包时指定。

假如写在.rpmmacros文件里，内容如下：
%rhel  5

另外，还有一个建议，假如你想打出来的包的名字是puppet-2.7.6-1.el5.noarch.rpm，那么，在这个文件里写添加一个宏dist
%dist  .el5

2.下载puppet包，还有puppet-2.7.6.tar.gz.asc，这个打src包时，需要。

3.修改puppet.spec文件，官方提供的这个包里的puppet.spec有个错误，搜索http_server，只有一行，将http_server改为http。

4.将这个puppet.spec复制到~/rpmbuild/SPECS下。

5.将修改过的puppet-2.7.6目录重新打包，将包复制到~/rpmbuild/SOURCES目录下。

6. 最后一步，开始打包：

$cd ~/rpmbuild/SPECS
假如~/.rpmmacros里已经写了rhel宏，那么这里就可以直接打包了：
$rpmbuild -ba puppet.spec

假如~/.rpmmacros里没有定义rhel宏，那么命令需要这样写：

$rpmbuild -D ‘rhel 5′ -ba puppet.spec

假如不出意外，打好的包会放在~/rpmbuild/RPMS/noarch目录下。

假如出错，一般是依赖关系的问题，缺少什么，就安装什么包（一般是xxx-devel包），然后重新打包就可以了。

打facter的rpm包与puppet的差不多，将facter-1.6.2.tar.gz解压后，将conf/redhat/facter.spec复制到~/rpmbuild/SPECS下，将facter-1.6.2.tar.gz复制到~/rpmbuild/SOURCES下，然后开始打包：

$cd ~/rpmbuild/SPECS
$rpmbuild -ba facter.spec

参考：
http://www.php-oa.com/2010/05/11/linux-rpm-build.html
http://www.ibm.com/developerworks/cn/linux/management/package/rpm/part1/
http://www.ibm.com/developerworks/cn/linux/management/package/rpm/part2/
http://www.ibm.com/developerworks/cn/linux/management/package/rpm/part3/
http://ogres.iteye.com/blog/343674

网上大部分文章都说ntpd是“平滑”、“缓慢”（adjusts the clock in small steps）地调整本地时钟的，但实际上，并不总是如此，“平滑”地调整是有前提的（需要启动ntpd时使用-x参数，在/etc/sysconfig/ntpd里调整）。

关于NTP的1000s的问题：当本地时钟与远端的NTP服务器时钟相差大于1000s时，ntpd会停止工作。有这种说法，ntpd的手册里也有介绍，但是RHEL的/etc/init.d/ntpd启动脚本中，默认情况下通常启动ntpd时，都会参加一个-g参数，这个-g参数的作用正是忽略这个1000s的问题。

关于1000s的问题，正确的描述：
In case there is no TOY chip or for some reason its time is more than 1000s from the server time, ntpd assumes something must be terribly wrong and the only reliable action is for the operator to intervene and set the clock by hand.
This causes ntpd to exit with a panic message to the system log. The -g option overrides this check and the clock will be set to the server time regardless of the chip time. However, and to protect against broken hardware, such as when the CMOS battery fails or the clock counter becomes defective, once the clock has been set, an error greater than 1000s will cause ntpd to exit anyway.

RHEL5/6的ntpd手册里，关于-g的描述，似乎少了一句话：–panicgate，Allow the first adjustment to be Big. 这个描述是在ArchLinux上的ntpd的手册里看到的，ArchLinux上的ntp包的版本是4.2.6.p3-3，RHEL5/6上的分别是4.2.2p1/4.2.4p8，手册里，虽然没有这样的描述，但是经过测试-g参数确实有这样的功能。这是第二次发现RHEL手册版本“很保守”，跟不上程序。

RHEL 5u7里带的ntp修复了若干bug，应该对5u4上的ntp偶尔（很偶尔）会不工作有所改进。这又是“系统需要升级”的一个有利证据。

假如使用了-x选项，那么ntpd只做微调，不跳跃调整时间（ntpd并不是默认承诺不跳跃调整时间的），但是要注意，-x参数的负作用：当时钟差大的时候，同步时间将花费很长的时间。-x也有一个阈值，就是600s，当系统时钟与标准时间差距大于600s时，ntpd会使用较大“步进值”的方式来调整时间，会在2000s（大约时间）内将时钟“步进”调整到正确时间。

假如不使用-x选项，那么ntpd在时钟差距小于128ms时，使用微调方式调整时间，当时差大于128ms时，使用“跳跃”式调整。

使用了-g参数，那么会有两个特效:当ntpd启动时，会忽略本地与远程时钟的差距（忽略1000s的问题），但是只会忽略一次，也就是说，假如过了一段时间，系统时钟又与标准时间相差超过1000s（硬件估计坏了），ntpd就会panic退出;-g参数，会让nptd在与远程ntp服务器“协商”之后，对本地时钟进行“跳跃”式调整。

/etc/sysconfig/ntpd中的SYNC_HWCLOCK=no，默认改成yes也是没有用的。要使之有用，还需要其它的配合：要么是在OPTIONS里添加-x选项；要么在/etc/ntp/step-tickers里添加NTP服务器的地址（启动的nptd进程没有-g选项）。这样，会改变ntpd服务的默认启动方式。ntpd启动时，会立即先成ntp server进行同步，再启用ntpd。假如使用了-x选项，则总是微调时钟。

重点是：路径依赖

“美国铁路两条铁轨之间的标准距离是四点八五英尺。这是一个很奇怪的标准，究竟从何而来的？
原来这是英国的铁路标准，因为美国的铁路最早是由英国人设计建造的。
那么，为什么英国人用这个标准呢？
原来英国的铁路是由建电车轨道的人设计的，而这个四点八五英尺正是电车所用的标准。电车轨标准又是从哪里来的呢？
原来最先造电车的人以前是造马车的。而他们是用马车的轮宽做标准。好了，那么，马车为什么要用这个一定的轮距离标准呢？
因为如果那时候的马车用任何其它轮距的话，马车的轮子很快会在英国的老路上撞坏的。为什么？
因为这些路上的辙迹的宽度为四点八五英尺。这些辙迹又是从何而来呢？
答案是古罗马人定的，四点八五英尺正是罗马战车的宽度。如果任何人用不同的轮宽在这些路上行车的话，他的轮子的寿命都不会长。我们再问：罗马人为什么用四点八五英尺为战车的轮距宽度呢？
原因很简单，这是两匹拉战车的马的屁股的宽度。故事到此应该完结了，但事实上还没有完。
下次你在电视上看到美国航天飞机立在发射台上的雄姿时，你留意看，在它的燃料箱的两旁有两个火箭推进器，这些推进器是由设在犹他州的工厂所提供的。如果可能的话，这家工厂的工程师希望把这些推进器造得再胖一些，这样容量就会大一些，但是他们不可以，为什么？
因为这些推进器造好后要用火车从工厂运到发射点，路上要通过一些隧道，而这些隧道的宽度只比火车轨道的宽度宽了一点点
故事是颇有趣的。从一定意义上说，今天世界上最先进的运输系统的设计，或许是由两千年前两匹战马的屁股宽度来决定的。历史惯性的力量是多么的强大，要冲破由惯性形成的规则又是多么的艰难。
好习惯将不只影响您的一生，您的后代子子孙孙，皆会因而受益。”

RHEL 6即然选择了rsyslog，自然是有它的道理的。

假如自己没有研发能力，那么“跟随”上游，无疑是最明智的选择。

RedHat 5 SystemTap Language Reference
RedHat 6 SystemTap Beginners Guide
RedHat 6 SystemTap Tapset Reference

Linux Performance Tunning Guide
Red Hat Enterprise Linux Performance Tuning Guide
RHEL Kernel Performance Optimization, Characterization and Tuning
Performance Analysis and System Tuning

IBM红皮书：
Linux Performance and Tuning Guidelines
http://www.redbooks.ibm.com/redpapers/pdfs/redp4285.pdf

OSCON:
Linux Monitoring
http://www.ufsdump.org/papers/oscon2009-linux-monitoring.pdf

这个是”RedHat Enterpress Linux”的生命周期和更新策略：
https://access.redhat.com/support/policy/updates/errata/

RedHat提供的勘误公告，也就是“更新列表”：
https://access.redhat.com/security/updates/active/

RHEL6的更新列表：
https://rhn.redhat.com/errata/rhel-server-6-errata.html

RHEL5的更新列表：
https://rhn.redhat.com/errata/rhel-server-errata.html

RHEL4的更新列表：
https://rhn.redhat.com/errata/rhel4as-errata.html

RedHat Enterpress Linux安全手册：
下面的链接是RHEL6的，但是与5、4相比，内容变化不大
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/index.html

需要特别说明的是：
RedHat虽然不为“未注册用户”提供免费“升级”功能， 但是，却免费提供了过级过后的“源码包”，理论上自己重新打一下包，就可以使用了。只是不方便而已。
源码包地址在这里：
ftp://ftp.redhat.com/redhat/linux/enterprise/$releasever/en/os/SRPMS/
ftp://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/
ftp://ftp.redhat.com/redhat/linux/enterprise/5Server/en/os/SRPMS/

W: GPG error: http://http.us.debian.org stable Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY AED4B06F473041FA

W: You may want to run apt-get update to correct these problems

command="rsync --server  --sender -vlogDtprCz . /mnt/one/" ssh-dss AAAAB3...sYBat4= user@deckard.example.com

这样，客户端就可以使用下面的命令，通过key认证来同步目录了：

rsync -e 'ssh -i pris -l deckardsync' -Cavz /home/user/two/ pris:/mnt/three

2.svnserve

在服务端增加：

command=”/usr/bin/svnserve -t -r /var/svn-repos/ –tunnel-user=svnuser”,no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding

客户端：

svn import web svn+ssh://192.168.1.10/topcity -m “initial import”

参考：
http://lamp.linux.gov.cn/OpenSSH/sshd.html#end
http://ramblings.narrabilis.com/wp/using-rsync-with-ssh/

http://hi.baidu.com/farmerluo/blog/item/9006a4c2a679380b0ff4776e.html

2.假如客户端portmap没有启动，mount时，会非常慢，最终会失败。umount时，即使本地的portmap是关闭的，也能umount成功。

3.挂载完成后，服务端的portmap停止后，nfs仍然工作正常，但是umout时会提示： not found / mounted or server not reachable。重启服务器的portmap也无济于事。

4.假如服务端的portmap重启了，那么nfs也要跟着重启，否则nfs工作仍然是不正常的。

5.假如服务端nfs关闭(IP是通的)，这时客户端会无法umount，这时使用umount -f /nfs一般能成功，当服务端死机时，umount -f /nfs 有可能会失败，这时可以使用 umount -l /nfs .

最终建议：

1.使用NFS，就要使用portmap，NFS严重依赖于portmap，所以不要试图去停止它(portmap)。

2.当不能umount /nfs 分区时，试着使用umount -f /nfs,一般都能成功。

3.当umount -f /nfs不能umount时，可以试试umount -l /nfs. umount -l是最终级的umount。

man sadc(sysstat真正用来收集数据的程序)，看到 -d 参数是用来收集记录iostat信息的，默认情况下，因为会占用较多的磁盘空间，而没有开启。（RHEL6上默认已经开启）

开启的办法是修改/etc/cron.d/sysstat ，在sa1 后面加一个-d参数。

修改之后，过一会，sar -d仍然会提示没有数据，这大概是因为之前的信息文件已经存在，并且没预留iostat的数据空间，sadc无法将iostat数据记录在/var/log/sa/saNN文件中，要么，等到新的saNN文件生成，要么，将当天的数据删掉，之后，就可以查看到收集的数据了。

上午还在疑惑web访问日志中怎么有这样奇怪的日志（没有“方法”，没有URI），数量还不少，下午就亲自访问、触发出了这样的日志。

在一个ISP那里搭建了一个新的web环境，但是无论如何都不能正常访问，日志中全是类似的日志。经过N久的纠结之后，终于突然想起来“内容审核”、“域名备案”系统。据说ISP那里已经可以实现“白名单”机制，即备过案的域名，才可以被正常访问，否则就不能被正常访问。基于应用层的过滤。

至于为什么要升级，部分人认为，“稳定最重要，只要不出问题，就不要升级”，一部分人认为，保持更新，可以“无形之中清扫掉自己不知也没时间、没精力去知的系统问题，从而避免掉进陷阱”……这里不争论这个问题。

准备工具：

1)安装Dell的 community repository
wget -q -O – http://linux.dell.com/repo/community/bootstrap.cgi | bash

2)安装firmware-tools
yum -y install firmware-addon-dell

3)安装Dell的 firmware repository
wget -q -O – http://linux.dell.com/repo/firmware/bootstrap.cgi | bash

4)install BIOS payload
yum install $(bootstrap_firmware)

小抄：
# set up repos
wget -q -O – http://linux.dell.com/repo/community/bootstrap.cgi | bash
wget -q -O – http://linux.dell.com/repo/firmware/bootstrap.cgi | bash

# install firmware tools
yum -y install firmware-addon-dell

# install BIOS update
yum -y install $(bootstrap_firmware)
update_firmware

参考：
http://linux.dell.com/repo/hardware/
http://linux.dell.com/wiki/index.php/Repository/firmware

下面简单说一下Dell服务器的RAID卡的性能调整。个人在这方面的经验并不十分丰富，有可能理解有误。

问题的焦点，是因为RAID卡的缓存模块的（BBU）电池，具体的原理，这里并不深研，有兴趣的同学，可跟据下面提供的URL自行研究。这块电池是可充电池，我的理解是这样的：这块电池的作用，是用来“保护数据”的，即当服务器突然掉电时，RAID卡的电池储存的电能足以驱动RAID卡和磁盘，某些固化在RAID卡中的程序会将RAID卡“缓存”（注意这里提到的缓存）的数据，写到磁盘上，从而降低、减少数据丢失的风险。

可能是可充电池的特性，这块可充电电池，在不使用时，也会有微弱的放电现象，当它的电量放电到低到一定程度时，RAID卡程序，会对电池进行一次“放电”，将剩余的电量放掉，然后再进行一次“充电”。

这其实是一种对“电池”保护机制，以及对RAID设施可用性提供保障的机制。

问题就出在这个放电、充电的过程。

默认情况下，当RAID卡的电池的电量低于某阈值时，RAID卡固化程序认为此时的电池是不可用的，为了保证数据的安全，会禁用RAID的“缓存”，这种默认的机制本来是合情合理的，没有什么可“质疑”的。问题是，当RAID的缓存被禁用之后，RAID的I/O能力会有所下降（这简直是一定的）。对于高I/O的应用来说，这种下降，有可能是致命的，可能会导致系统I/O阻塞，构架不良的系统，有可能会被这个“故障点”（正在充放电的设备上的应用）拖死。

有两种方法解决这个问题：

1. 检查电池的状态，对电池的充放电进行撑握，也可有计划地安排手动充放电。

此时I/O性能依然是会下降的，可以安排在系统负载低的时候进行手动充放电，从而避免充放电在未知的时间里自动进行充放电，影响业务。

2. 为了保障性能，粗暴地改变RAID卡策略，使在充放电时，不禁用RAID卡缓存。

些时I/O的性能不会下降，但是，假如在此时服务器掉电，RAID卡缓存中的数据会来不及写进磁盘，从而造成数据的丢失。

使用1比较稳妥，但是比较耗时、耗力。使用2比较简单，对于不是非常重要的数据、某者还有别的冗余方案的应用，可以使用。

Dell的服务器，大多使用的都是LSI的MegaRAID卡，查看系统使用的什么RAID卡，可以使用lspci命令，这个假如包含在pciutils包中。

常见的MegaRAID卡：

• 02:0e.0 RAID bus controller [0104]: Dell PowerEdge Expandable RAID controller 4 [1028:0013] (rev 06)
• 04:03.0 RAID bus controller [0104]: Dell PowerEdge Expandable RAID controller 4/Di [1028:000f] (rev 02)
• 02:04.0 RAID bus controller [0104]: American Megatrends Inc. MegaRAID [101e:1960] (rev 02)
• 02:03.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID [1000:1960] (rev 01)

也可以通过lsmod | grep megaraid 来检查系统使用的是不是MegaRAID卡。

MegaRAID卡，可以通过官方提供的工具MegaCli来进行控制，对缓存的控制策略调整就用这个工具来进行操作。

MegaCli的当前版本可从这里下载。

假如你使用的是RHEL或者CentOS，可使用我的repo安装，步聚如下：

1) wget -P /etc/yum.repo.d http://www.bsdmap.com/bsdmap.repo

2) yum install megacli

默认安装在/opt/MegaRAID/MegaCli/目录下，32位系统为MegaCli，64位系统为MegaCli64，以64位系统为例：

1. 查看当前“策略”
/opt/MegaRAID/MegaCli/MegaCli64 -ldinfo -lall -a0

Adapter 0 — Virtual Drive Information:
Virtual Disk: 0 (Target Id: 0)
Name:Virtual Disk 0
RAID Level: Primary-0, Secondary-0, RAID Level Qualifier-0
Size:953344MB
State: Optimal
Stripe Size: 64kB
Number Of Drives:1
Span Depth:1
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Disk’s Default
Virtual Disk: 1 (Target Id: 1)
Name:
RAID Level: Primary-5, Secondary-0, RAID Level Qualifier-3
Size:3813376MB
State: Optimal
Stripe Size: 64kB
Number Of Drives:5
Span Depth:1
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Disk’s Default

Exit Code: 0×00

2. 调整

/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -lall -a0

再查看
/opt/MegaRAID/MegaCli/MegaCli64 -ldinfo -lall -a0

Adapter 0 — Virtual Drive Information:
Virtual Disk: 0 (Target Id: 0)
Name:Virtual Disk 0
RAID Level: Primary-0, Secondary-0, RAID Level Qualifier-0
Size:953344MB
State: Optimal
Stripe Size: 64kB
Number Of Drives:1
Span Depth:1
Default Cache Policy: WriteBack, ReadAheadNone, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, Write Cache OK if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Disk’s Default
Virtual Disk: 1 (Target Id: 1)
Name:
RAID Level: Primary-5, Secondary-0, RAID Level Qualifier-3
Size:3813376MB
State: Optimal
Stripe Size: 64kB
Number Of Drives:5
Span Depth:1
Default Cache Policy: WriteBack, ReadAheadNone, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, Write Cache OK if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Disk’s Default

Exit Code: 0×00

embedded_mr_sw_ug.pdf

http://linux.dell.com/repo/hardware/

http://tools.rapidsoft.de/perc/

http://linux.dell.com/

http://linux.dell.com/wiki/index.php/Repository/firmware

http://hwraid.le-vert.net/wiki/LSIMegaRAID

http://hwraid.le-vert.net/wiki/LSIMegaRAIDSAS

[安装主程序]
cpan install MogileFS::Server
MogileFS的节点有两种，Tracker 和 storage ，对应的程序分别是mogilefsd 和 mogstored。安装完MogileFS::Server，这两个程序就在磁盘上了。

/usr/bin/mogdbsetup
/usr/bin/mogautomount
/usr/bin/mogilefsd
/usr/bin/mogstored

[注意]
需要注意的是，MogileFS::Store::MySQL需要安装DBD::mysql,而DBD::mysql依赖于mysql-devel包，最好安装MogileFS::Server之前就先将mysql-devel安装好，否则需要事后安装：
yum -y install mysql-devel
cpan install DBD::mysql

[安装工具]
cpan install MogileFS::Utils
之后就有这些工具可用：
/usr/bin/moglistfids
/usr/bin/mogfileinfo
/usr/bin/mogtool
/usr/bin/mogstats
/usr/bin/mogfiledebug
/usr/bin/mogadm
/usr/bin/mogdelete
/usr/bin/mogfetch
/usr/bin/moglistkeys
/usr/bin/mogupload

[Tracker数据库部署]
mogdbsetup –dbhost=mogiledb.yourdomain.com –dbname=mogilefs –dbuser=mogile –dbpassword=sekrit

[Tracker配置]
#/etc/mogilefs/mogilefsd.conf
db_dsn DBI:mysql:mogilefs:192.168.1.186:3301
db_user mogile
db_pass sekrit
conf_port 6001
listener_jobs 150

[Tracker启动]
if [ -f /etc/mogilefs/mogstored.conf ] ; then
mogstored –daemon
fi

[storage配置]
#/etc/mogilefs/mogstored.conf
httplisten=0.0.0.0:7500
mgmtlisten=0.0.0.0:7501
docroot=/srv/mogdata

[storage启动]
#添加用户mogile
if [ -f /etc/mogilefs/mogilefsd.conf ] ; then
sudo -u mogile mogilefsd –daemon
fi

[FAQ]

1.如何查看MogileFS运行状态？
1)查看host运行情况
mogadm check

mogadm host list

mogadm device list

mogadm device summary

2. mogadm fsck 的功能怎么理解？

[其它]
1. 可telnet到tracker上，通过特定的命令管理MogileFS，输入!help可以到底一个命令列表。比如查看mogelifsd的版本：!version

引申阅读：

http://code.google.com/p/mogilefs/wiki/Start?tm=6

http://www.srcfree.com/bcfg2-systems-management-software/

http://trac.mcs.anl.gov/projects/bcfg2/

在Linux桌面上，发挥着重要作用。通常，当dbus服务停止后，桌面就会立即crash。

但是在服务器上，dbus发挥着什么作用呢？可以停止么？

Archlinux 的安装文档上，对dbus轻描淡写了一句：

注意: 许多应用程序都需要 dbus，如果确定不需要它，请跳过这个部分。

可以看出，dbus，并不是系统必需的服务。

RHEL6，以及Ubuntu（更多其它发行版也在使用）在使用的Upstart的（代替原来的 SystemV init ），支持dbus，但是没有dbus的环境，一样可以运行良好。init会在接到USER1信号时，连接dbus。也就是说，init 也可以在没有dbus的情况下，可以不连接dbus。

另一个证据，看dbus的配置文件/etc/dbus-1/system.d　下面：

avahi-dbus.conf hal.conf nm-avahi-autoipd.conf nm-dispatcher.conf oddjob.conf yum-updatesd.conf
bluez-hcid.conf NetworkManager.conf nm-dhcp-client.conf nm-system-settings.conf wpa_supplicant.conf

很显然，这些配置文件是为需要dbus“设施”的应用，而在服务器上，通常是用不到这些