设备温度过高，导致硬件性能降低的原理

      金属导电是电子导电，电子在电场的作用下做定向漂移运动，形成金属中的电流。电子在金属导体中定向运动时，受到的阻碍作用愈小，导体呈现的电阻就愈小。反之，电子运动受到的阻碍作用愈大，它运动得就愈不自由，导体所呈现的电阻就愈大。

      电子在定向漂移运动中，受到的阻碍作用是电子与金属中晶体点阵上的原子实碰撞产生的。在金属导体中，晶体点阵上的原子实，虽然基本上保持规则的排列，但并不是静止不动的。每个原子实都在自己的规则位置附近不停地做热振动，整个导体中原子实的热振动并没有统一步调。这样，就在一定程度上破坏了原子实排列的规则性，形成了对电子运动的阻碍作用。原子实的热振动离开自己规则位置愈远，与电子相碰的机会愈多，电子漂移受到的阻碍作用就愈大，导体呈现的电阻也就大起来了。 （温度越高，分子的热运动越剧烈）

      综上所述，问题的答案就不难得出来了，因为温度升高时，原子实的热振动加强，振动的幅度加大，于是，做定向漂移的电子与原子实相碰的机会增多，碰撞次数也增加，所以，金属导体的电阻就增加了。对于纯金属来说，电阻随温度的变化比较规则；在温度变化范围不大时，电阻与温度之间的关系为 ：

R ＝ R 0 ＋（ 1 ＋α） t

      式中 R 0 是 0 ℃时金属导体的电阻，α为该金属导体的电阻温度系数。不同金属材料的电阻温度系数α亦不相同。
(有些合金的电阻随温度变化很小 。)

关于samba (smb)服务使用的端口

      内网有一台服务器，里面跑着oracle，为了安全开了iptables过滤。偶尔会使用smb服务与windows之间互访文件。之前在使用的时候一般停掉防火墙，后来这样嫌麻烦。查阅samba服务使用的端口，在防火墙中修改规则即可。

[root@oracle ~]# netstat -anop | grep smb
tcp        0      0 0.0.0.0:139                 0.0.0.0:*                   LISTEN      4026/smbd           off (0.00/0/0)
tcp        0      0 0.0.0.0:445                 0.0.0.0:*                   LISTEN      4026/smbd           off (0.00/0/0)
unix  2      [ ]         DGRAM                    9910   4026/smbd
[root@oracle ~]# netstat -anop | grep nmbd
udp        0      0 192.168.1.10:137            0.0.0.0:*                               4030/nmbd           off (0.00/0/0)
udp        0      0 0.0.0.0:137                 0.0.0.0:*                               4030/nmbd           off (0.00/0/0)
udp        0      0 192.168.1.10:138            0.0.0.0:*                               4030/nmbd           off (0.00/0/0)
udp        0      0 0.0.0.0:138                 0.0.0.0:*                               4030/nmbd           off (0.00/0/0)

nmbd是属于smb服务的一个进程。

我们看到使用了tcp的139和445端口，udp的137和138端口。在防火墙中允许通行：

iptables -A INPUT -p tcp –dport 139 -j ACCEPT
iptables -A INPUT -p tcp –dport 445 -j ACCEPT
iptables -A INPUT -p udp –dport 137 -j ACCEPT
iptables -A INPUT -p udp –dport 138 -j ACCEPT

（我设定默认OUTPUT为ACCEPT，FORWARD为ACCEPT，INPUT为DROP）

在后来的测试中，仅允许tcp协议的139端口通过也能访问到共享。

cp命令强制覆盖，不提示确认信息

      使用cp -R -f 拷贝文件到目标时，如果有同名文件会提示是否覆盖目标文件，我们知道-f参数是强制覆盖，虽然使用了f 参数，但是还是不起效果，其实是因为alias的作用导致了这个问题。

[root@mail ~]# alias
alias cp=’cp -i’     //发现cp其实是 cp -i  -i的作用就是交互，提示用户选择。

man cp的帮助文档解释：

-i, –interactive
              prompt before overwrite (overrides a previous -n option)

那么我们修改alias去掉-i参数就不会提示，直接强制覆盖了。

[root@mail ~]# alias cp=cp
[root@mail ~]# alias
alias cp=’cp’        //这样再使用-f参数就不提示是否覆盖。

这样改只是临时，想永久性有效，需要修改：~/.bashrc

不过还是希望保持默认，这样可以防止我们误覆盖文件，导致意外损失。用完后再改回原先：alias cp=’cp -i’

emos1.5收取QQ发来的邮件正文乱码

     收取qq发送来的邮件正文为乱码，在 编码 手动选择GB2312没问题。截取部分邮件原结构发现qq的编码为gb18030，extmail会自动判别编码格式来显示。

$VAR1 = {
   ‘body’ => {
      ‘list’ => [
         {
         ‘pos_end’ => ‘1596’,
         ‘pos_start’ => 1490,
         ‘phead’ => {
             ‘Content-Type’ => ‘text/plain’,
             ‘charset’ => ‘gb18030’,
             ‘Content-Transfer-Encoding’ => ‘base64’
            },
         ‘idflag’ => ‘alternative-0’,
         ‘size’ => ‘106’
         },
         {
         ‘pos_end’ => ‘1757’,
         ‘pos_start’ => 1640,
         ‘phead’ => {
             ‘Content-Type’ => ‘text/html’,
             ‘charset’ => ‘gb18030’,
             ‘Content-Transfer-Encoding’ => ‘base64’

EMOS官网解释：

关于GB18030
       由thunderbird或某些客户端软件发出的中文邮件编码是GB18030，部分内容甚至全部乱码。经过仔细检查发现是Perl 目前版本（5.8.8或以下）缺少了GB18030码表，因此增加了Encode::HanExtra码表模块的支持，解决了此问题。

解决方法如下：

[root@emos ~]# wget -c http://search.cpan.org/CPAN/authors/id/A/AU/AUDREYT/Encode-HanExtra-0.23.tar.gz
[root@emos ~]# cd Encode-HanExtra-0.23
[root@emos Encode-HanExtra-0.23]# perl Makefile
[root@emos Encode-HanExtra-0.23]# make install

直至完成，刷新页面即可。

另一种方法就是在用QQ邮箱写信时，设置编码为Unicode

勾选始终使用Unicode编码发信。后面也给出了解释。

PS:

EMOS1.5中perl版本就是5.8.8，在新版本的emos1.6中版本为5.10.1。

Read-only file system

     客户打电话说邮件服务器web界面不能登陆，随登陆服务器查看httpd状态，进程已经死掉，但是pid还在。重启服务报错：
[root@emos ~]# service httpd restart
rm: cannot remove `/var/run/httpd.pid’: Read-only file system FAILED

rm: cannot remove `/var/lock/subsys/httpd’: Read-only file system
rm: cannot remove `/var/run/httpd.pid’: Read-only file system
Starting httpd: (30)Read-only file system: httpd: could not open error log file /etc/httpd/logs/error_log.
Unable to open logs

可以确定是系统分区出现问题，或许是文件系统原因，再就是硬盘有坏道了（服务器买了一年）。

[root@emos sdb1]# uptime
 09:29:31 up 206 days, 13:13,  0 users,  load average: 3.00, 3.99, 2.38
uptime了一下，连续运行二百多天，没有重启，应该不是意外断电的原因。
[root@emos ~]# dmesg | grep error

EXT3-fs error (device sda1): ext3_lookup: unlinked inode 93032473 in dir #93031458
EXT3-fs error (device sda1): ext3_journal_start_sb: Detected aborted journal
EXT3-fs error (device sda1): ext3_lookup: unlinked inode 93032473 in dir #93031470

[root@emos ~]# rm -rf 360bike0425.tar.gz
rm: cannot remove `360bike0425.tar.gz’: Read-only file system

修复过程：

[root@emos ~]# fsck.ext3 /dev/sda1
e2fsck 1.39 (29-May-2006)
/1: recovering journal

Clearing orphaned inode 113377696 (uid=1035, gid=1035, mode=040755, size=4096)
Clearing orphaned inode 113377703 (uid=1035, gid=1035, mode=040755, size=4096)
Clearing orphaned inode 76021804 (uid=0, gid=48, mode=0100700, size=652620)
Clearing orphaned inode 32703391 (uid=0, gid=0, mode=0100644, size=18189)
Clearing orphaned inode 76021797 (uid=48, gid=48, mode=040755, size=4096)
Clearing orphaned inode 76021792 (uid=0, gid=0, mode=0100600, size=0)
Clearing orphaned inode 112329966 (uid=102, gid=104, mode=0100644, size=1850941)
Clearing orphaned inode 112296705 (uid=0, gid=0, mode=0100644, size=40)
/1: clean, 102739/119537664 files, 13717038/119535640 blocks

[root@emos ~]#reboot

解决！猜测原因是我这服务器经常进行读写操作导致文件系统出现问题，系统为redhat5.3，官网也有类似错误，说是bug。

总结（来自网络）：
    文件系统损坏有几个原因，一个是非法关机，第二个是磁盘有环道，只能一个一个排除，先软后硬，如果格式化后，还是有问题，那原因多半就是硬件的问题了。同时提醒，多半的原因是由于非法关机引起的，比如冷启动，运气好的话，没有异常出现，希望大家少走一些弯路，操作一定要规范！