syslogd & klogd

syslogd & klogd

◆restorecond

　　这个程序的目的是要还原某些文件的SELinux权限，需要还原的清单列在/etc/selinux/ 目录中的restorecond.conf文件里。在2.6 kernel中，SELinux是一个新加入的机制，但它非常重要，因为SELinux所控管的是每一个文件的执行权限，与之前的PAM、 Kerberos、TCP Wrapper各机制相比各有所长，在相互配合管控之下，这几种机制将Linux的安全性大幅提高。

Fedora从Core 2版本开始引进SELinux的机制，这对有些用户来说将造成困扰，因为在SELinux激活的条件下，某些服务会存在执行上的问题，像SAMBA。因为 该服务分享出来的文件或目录，有可能是被SELinux默认值所限制住的，导致无法正常分享，因此，笔者在测试时期会将大部分SELinux都关闭。

　　◆syslog

　　这个服务程序太重要了，大部分的系统维护都会用到它，也就是网络或系统管理员经常用到的log 文件。daemon在执行时其实是执行两个程序：syslogd和klogd，介绍如下，其分别负责不同种类的log，但全部的信息在系统刚开完机之后， 会全部存放在/var/log/message。

　　? klogd

　　先介绍klogd是因为当一开始写入/var/log/message时，klogd所记录的信息会比syslogd 的顺序优先，原因是klogd所记录的是尚未进入操作系统的信息，但其实一开始的这些信息并不是由klogd所记录的，而是自加载kernel 时，就已经开始记录的。在系统尚未进入操作系统阶段，还在加载kernel及执行initrd时，会将信息先记录在/proc/kmsg文件中(因为在 initrd阶段没有实体硬盘可供记录)，等进入操作系统执行完klogd后，klogd再将/proc/kmsg的所有内容全数填入/var/log /message文件中，这也是为何在/var/log/message文件的一开始，依然可以看到刚开机在加载kernel以及initrd阶段的信息 (如图5-13中连CPU的启用都看得到，信息中也注明了是kernel的信息)。

常用到的dmesg指令其实也就是将klogd检测出来的kernel信息，它直接通过console呈现在用户面前。在进入操作系统之后，kernel 当然还在运行，而此时的kernel若检测到内部错误发生，klogd则会通过/boot/System.map文件找到kernel所在，如此一 来，kernel就可以直接通过klogd的管道将信息再度呈现在用户面前。

? syslogd

　　在klogd填入所有kernel加载及initrd阶段的信息之后，接着执行的就是这一节所提到的服务级程序，而这些程序所产生的信息，就由 syslogd负责整理，所以，这些信息会直接加在刚刚klogd的信息后面。在进入操作系统后就没有依照klogd或syslogd的顺序，只要产生信 息，就直接依/etc/syslog.conf文件的定义，写入/var/log/message信息文件。

　　图5-14 的方框就是在kernel信息结束后其中一个xinetd服务激活的信息，从图中的第一行可以看出kernel信息结束后，紧跟着就是服务软件的信息。

从/etc/syslog.conf文件可以找出所有目前系统通过syslogd所记录的信息，有时候在找某软件的信息时，也可以从这个文件中看出要以哪一个信息文件为主，当然前提是该软件必须支持syslogd的信息记录格式。

　　◆irqbalance

　　在硬件信息都已经齐全后，irqbalance程序的主要目的就是平均分散所有CPU或实体core 之间的interrupts，以往计算机只有一颗CPU，所以都是由某一特定的CPU来负责，但现在的CPU越来越多核心(core)，管理方式也越趋复 杂化，加入Linux提供的这一个daemon，就是希望可以在多核心的条件下，将IRQ的性能再加强，让每个设备能多省一些电源，以达到更经济实用的目 的。目前已有很多软件朝此方向努力，如第9章将介绍的XEN技术，或是Intel及AMD推广的省电技术，其实也是为此而诞生的。

　　往后CPU的走向将朝多核心的方式进行，核心越多，应该要越来越快才对，但在不同核心之间会衍生出许多性能的问题，irqbalance就可以 解决其中之一。另外值得一提的是NUMA的机制(kernel内置的一种机制)，和irqbalance某些部分有点相似，但NUMA是为了让各CPU之 间分配内存的性能可以再提升，和irqbalance有异曲同工之妙，两者存在的目的都是为了应付在不同CPU间的处理性能问题。

　　为何会有CPU之间分配内存的性能问题?这就要看一下Intel与AMD目前的架构，在图5-15中虚线以上是差异最大的部分，可以看到 Intel 仍是由单一北桥负责各CPU与内存的管理，但AMD已经将北桥崁进CPU里面，内存的管理也就全数交给CPU，造成两种完全不同的硬件架构。

　　从图5-15中可以看出，在用户通过CPU访问内存时是很有机会重叠到的(Intel 架构为共享，因此一定会重叠;而AMD 则是当CPU1 要访问到CPU2 的内存之类的情形)，若重叠情况发生而处理方式不当时，可想见其速度会降低。在两者架构完全不同的情况下，自然管理方式会造成使用的性能差异更大，而 NUMA机制就是为了解决CPU与内存之间的平衡问题，但目前一般PC的BIOS大部分却都没有支持NUMA的功能。

回到irqbalance，这个服务可以平衡多核心(或多个)CPU时的IRQ协调工作，在多个CPU时也会因为不只一个CPU，导致系统当发IRQ中断 信号时，怕偏重到某一个CPU，这样会让特定的CPU 性能降低，因此，虽然买到多核心的CPU，但相信在性能上，目前的硬件与系统的配合还没做到最佳时，还是无法形成最佳的管理方式，这还有待各厂商的改进。
◆crond

　　相信各位对crond都不陌生，它有点像是Windows的schedule软件，可以让用户定义年、月、日、时、分、秒，以解决周期性运行软 件的问题，设置方式简单明了，也有很多软件默认使用crond来执行。crond默认会执行的文件可以参考/etc/crontab文件中所列的清单(如 图5-16所示)，从图5-16中可以看到其实周期性执行的是在/etc目录下的cron.hourly、cron.daily、 cron.weekly，以及cron.monthly 目录中的所有文件，设置方式也很简单，只要依照分、时、日、月、周的顺序设置就可以排出用户想要的任务计划。

◆xfs

　　xfs其实只适用在进入runlevel 5，也就是图形接口的情况下。这是一个较少人会用到但又不可缺少的daemon，为何会这样说?因为在使用上很少会感觉到xfs的存在，默认也都是激活 的，如果在runlevel 3的阶段，停用是不会有任何影响的。但如果停用后要再进入XWindow，将会发现无法进入，原因是xfs所负责的就是X-Window 的所有字型管理。xfs的全名是X-Window Font Service，在未激活的状态下，X-Window会因为无字型可用而导致激活失败(如图5-17所示)，若用户曾看到过一个错误信息是有关 IPAddress:7100的问题，大多是因为xfs被关掉所导致的，解决办法其实只要把xfs激活就可以了。

但这个老问题其实在Fedora Core 7中已经不存在了，因为在Fedora Core 7的/etc/X11/xorg.conf文件已经不再使用xfs的设置，就算将xfs直接关掉再激活X Window，也不会停在上述的错误信息。

　　◆anacron

　　这个软件和crond其实有点相辅相成，crond负责任务计划，而anacron 则是负责以“间隔多久”为主要的诉求，刚好可以补足crond所做的周期性安排。其间隔的判断方式是以存放在/var/spool/anacron/目录 中的时间戳记(timestamp)为主要的依据，来决定是否要开始执行。

　　anacron与crond最大的差别在于，若以crond为主要的任务计划方式，会有一个小问题，如果我们先假设用户以crond设置每周 六、日凌晨12点到3点要进行更新软件的操作，但刚好却在假日或计划时间内停电，计算机在未开机的状态下度过排程时间，这些更新的操作就会持续延到下星 期，这对有些系统管理人员来说将是很大的困扰，尤其像是备份之类的工作，因此，若以anacron补足这方面的缺点，就会比较完整，而crond与 anacron是可以并行的。

　　anacron的主要设置文件在/etc/anacrontab，其设置方式和crontab的形式很像，主要是设置两个数字：周期天数和延迟 时间(以cron.daily为例，为1天和65 分钟)。当周期天数到了，anacron会判断该程序是否已执行过(1天)，若没有，则会等待一段时间再执行，这段时间就是设置好的延迟时间(65分 钟)。

◆local

　　这个最后执行的script文件稍早我们曾提到过，也就是在所有daemon执行完毕之后，让用户自定义要执行的程序或设置，在此便不再赘述。