GNU find （和其他？）有一个-true测试以及正常的-name,等等。从手册页：-mode-user
-true 始终正确。
每次我看到手册页时，我都会注意到这一点，并想知道它什么时候有用。所以，给我一些什么时候有用的例子:~)
我们每天轮换和压缩我们的 Apache 日志，但很明显这还不够频繁。一个未压缩的日志大约有 6G，快要填满我们的日志分区了（是的，我们以后会把它做得更大！），而且每天要花费大量的时间和 CPU 来压缩。我们必须为我们的统计处理每天生成一个压缩日志。显然我们可以将我们的日志移动到一个有更多空间的分区，但我也想把压缩开销分散到一整天。
使用 Apache 的rotatelogs，我们可以更频繁地旋转和压缩日志——比如每小时一次——但是我怎样才能将所有每小时压缩的日志连接到当天正在运行的压缩日志中，而无需解压缩以前的日志呢？我不想解压缩 24 小时的数据并重新压缩它，因为这具有我们当前解决方案的所有缺点。
Gzip 似乎没有提供任何附加或连接选项，但也许我错过了一些明显的东西。这个问题表明直接的外壳连接“有效”，因为可以解压缩存档，但这gzip -l不起作用似乎有点狡猾。
或者，也许这仍然是一种糟糕的做事方式。欢迎提出其他建议——我们唯一的限制是我们相对较小的日志分区以及需要提供每日压缩日志。
我们有许多 HP DL385 G2 在安装 RHEL 5.3 后出现内核崩溃。所有都是最新的固件 CD 8.50。最初的 RHEL 5.3 安装始终有效，并且在大多数情况下第一次启动没问题（内核 2.6.18-128.el5）；到目前为止，四分之一的人在这里感到恐慌。当“yum update”到内核 2.6.18-128.1.10.el5 时，我尝试过的大多数其他机器都无法启动。一两个还好。
恐慌总是在同一点上。控制台上记录的最后几行是：
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.11.5-ioctl (2007-12-12) initialised: [email protected]
usb 4-2: new full speed USB device using uhci_hcd and address 3
device-mapper: dm-raid45: initialized v0.2429
usb 4-2: configuration #1 chosen from 1 choice
hub 4-2:1.0: USB hub found
hub 4-2:1.0: 7 ports detected
然后暂停，然后：
kernel panic - not syncing - attempted to kill init
超过这一点，内核将不会启动（包括 Anaconda 安装的 2.6.18-128.el5），并且重新安装是唯一的选择。它似乎与HP 论坛上报告的这个问题非常相似。
那么，有什么想法吗？我们在 RHEL 5.2 上有 DL385 G2，因此 5.3 中的某些内容在相同的硬件上运行不佳。我们已经尝试过将 BIOS 恢复出厂设置等。我如何确定内核在做什么？（我已经从附加行中删除了“rhgb quiet”。）幸运的是，我们没有太多这些框，我有一点时间进行调查。
应该/etc/localtime（在 RHEL 5.3 下，我认为这并不重要）是：
- 一个符号链接
/usr/share/zoneinfo/whatever - 硬链接
/usr/share/zoneinfo/whatever - 一份
/usr/share/zoneinfo/whatever
我更喜欢 1) 因为它通过 Puppet 明确且易于管理，但它会破坏任何东西吗？RedHat 的默认外观为 3)。编辑：我知道在文件系统、tzdata 更新等之间进行符号链接的常见问题，但不知道历史上的 no-/usr-during-rc.sysinit 陷阱。谢谢大家！
我们经常让服务器中的 DIMM 出现故障，并在 syslog 中出现以下错误：
5 月 7 日 09:15:31 nolcgi303 内核：EDAC k8 MC0：一般总线错误：参与处理器（本地节点响应）、超时（无超时）内存事务类型（通用读取）、内存或 i/o（内存访问） , 缓存级别（通用） 5 月 7 日 09:15:31 nolcgi303 内核：MC0：CE 页 0xa0，偏移量 0x40，颗粒 8，综合症 0xb50d，第 2 行，通道 0，标签“”：k8_edac 5 月 7 日 09:15:31 nolcgi303 内核：MC0：CE - 无可用信息：k8_edac 错误溢出集 5 月 7 日 09:15:31 nolcgi303 内核：EDAC k8 MC0：扩展错误代码：ECC chipkill x4 错误
我们可以使用 HP SmartStart CD 来确定哪个 DIMM 有错误，但这需要停止生产服务器。有没有一种巧妙的方法可以在服务器启动时找出哪个 DIMM 坏了？我们所有的服务器都是运行 RHEL 5 的 HP 硬件。
您如何分析来自 UNIX/Linux 机器的日志文件？我们运行数百台服务器，它们都直接或通过 syslog 生成自己的日志文件。我正在寻找一个体面的解决方案来汇总这些并挑选出重要事件。这个问题分为 3 个部分：
1) 消息传输
经典的方法是使用 syslog 将消息记录到远程主机。这适用于登录到 syslog 的应用程序，但对写入本地文件的应用程序不太有用。对此的解决方案可能包括将应用程序记录到连接到程序的 FIFO 中，以使用 syslog 发送消息，或者通过编写一些东西来 grep 本地文件并将输出发送到中央 syslog 主机。但是，如果我们费心编写工具来将消息输入 syslog，我们是否会更好地用 Facebook 的Scribe之类的东西来代替整个工具，它比 syslog 提供更多的灵活性和可靠性？
2) 消息聚合
日志条目似乎属于以下两种类型之一：每个主机和每个服务。每主机消息是发生在一台机器上的消息；想想磁盘故障或可疑登录。每个服务消息出现在大多数或所有运行服务的主机上。例如，我们想知道 Apache 何时发现 SSI 错误，但我们不希望 100 台机器出现相同的错误。在所有情况下，我们只希望看到每种类型的消息中的一种：我们不希望有 10 条消息说同一个磁盘发生故障，并且我们不希望每次遇到损坏的 SSI 时都收到一条消息。
解决此问题的一种方法是在每个主机上将多个相同类型的消息聚合为一个，将消息发送到中央服务器，然后将相同类型的消息聚合为一个整体事件。SER可以做到这一点，但使用起来很尴尬。即使经过几天的摆弄，我也只有基本的聚合工作，并且不得不不断地查找 SER 用于关联事件的逻辑。它很强大但很棘手：我需要我的同事可以在最短的时间内拿起和使用的东西。SER 规则不满足该要求。
3) 生成警报
当有趣的事情发生时，我们如何告诉我们的管理员？邮寄群组收件箱？注入Nagios？
那么，你是如何解决这个问题的呢？我不指望一个盘子上的答案。我可以自己解决细节，但就什么肯定是常见问题进行一些高级讨论会很棒。目前，我们正在使用杂乱无章的 cron 作业、系统日志以及谁知道还有什么可以查找事件。这不是可扩展的、可维护的或灵活的，因此我们错过了很多我们不应该做的事情。
更新：我们已经在使用 Nagios 进行监控，这对于检测到的主机/测试服务/等非常有用，但对于抓取日志文件的用处不大。我知道 Nagios 有日志插件，但我对比每个主机警报更具可扩展性和层次性的东西感兴趣。