分类: Linux

Linux, RHEL, CentOS, etc.

  • Why do services like sendmail/httpd still query outdated DNS servers after resolv.conf is changed?

    Question

    One of my colleague raised a question: After changing resolv.conf, sendmail still query the old resolver, why?

    Steps:

    1. Set 192.168.122.65 as nameserver in resolv.conf, start sendmail service, send a mail to root@hat.com, and take a tcpdump. We can see there’s a query asking 192.168.122.65 for MX record of hat.com .

    2. Change nameserver from 192.168.122.65 to 192.168.122.72 in resolv.conf, send a mail to root@hat.com and take a tcpdump again. This time we expect a query to 192.168.122.72 (new), but the actual query is to 192.168.122.65 (old).

    3. Restart sendmail service, send a mail to root@hat.com, this time we can see a query to 192.168.122.72 (new) as expected.

    When we were thinking about what’s going wrong with sendmail, another colleague joined in discussion, and she mentioned that httpd and some other long-running services also have this behavior.

    Since sendmail is not the only case, I think we should have a check on glibc.

    (更多…)

  • How to use mwm as Window Manager in RHEL7?

    A dirty trick.

    Install packages

    # yum groupinstall "Server with GUI"
    # yum install motif xterm
    # cat /etc/sysconfig/desktop 
    PREFERRED=/usr/bin/mwm
    

    Start X from multi-users.target

    # systemctl isolate multi-user.target
    # startx
    
  • Pacemaker管理工具中 pcs/pcsd 的关系


    在 debug pacemaker/pcs/pcsd 的时候,我们通常需要知道,敲下 `pcs xxxx xxxx` 命令后,发生了什么动作。

    在应用 pcs 进行管理的 pacemaker 集群中,每个节点都会启动一个 pcsd 守护进程,监听 2224/tcp 端口。随后,我们可以从任一节点中,通过 pcs 命令管理整个集群。

    误解

    按照套路,通常这是一种 client/server 架构, pcs 命令行工具向相应节点的 pcsd 发送请求, pcsd 在相应节点完成动作。

    然而实际与此有所出入。

    实际套路

    实际上,真正对 pacemaker 执行操作的,是 pcs 这个命令行工具。pcsd 负责接收来自其他节点的请求,随之调用本地的 pcs 工具,最后由本地的 pcs 执行操作。

    本地命令示例

    以 `pcs cluster start` 命令为例。在 Node A 中执行 `pcs cluster start`, Node A 本地的 cluster 相关服务将被启动。

    在此操作中,不需要经过 pcsd. 即, pcs —> execute. 具体过程如下。
    (更多…)

  • 如何验证 ulimit 中的资源限制?如何查看当前使用量?

    ulimit 可以限制进程的资源使用量。在设置 ulimit 之后,如何验证各个资源限制是有效的?如何查看每个进程当前使用了多少资源?本文将尝试对多个设定值进行演示。

    ulimit 的设定,是 per-user 的还是 per-process 的?

    我们从 ulimit 中看到的设定值,都是 per-process 的。也就是说,每个进程有自己的 limits 值。
    [cc]
    $ ulimit -a
    core file size (blocks, -c) 0
    data seg size (kbytes, -d) unlimited
    scheduling priority (-e) 0
    file size (blocks, -f) unlimited
    pending signals (-i) 46898
    max locked memory (kbytes, -l) 64
    max memory size (kbytes, -m) unlimited
    open files (-n) 65536
    pipe size (512 bytes, -p) 8
    POSIX message queues (bytes, -q) 819200
    real-time priority (-r) 0
    stack size (kbytes, -s) 8192
    cpu time (seconds, -t) unlimited
    max user processes (-u) 46898
    virtual memory (kbytes, -v) unlimited
    file locks (-x) unlimited
    [/cc]

    ulimit, limits.conf 和 pam_limits 的关系?

    首先,limit的设定值是 per-process 的。在 Linux 中,每个普通进程可以调用 getrlimit() 来查看自己的 limits,也可以调用 setrlimit() 来改变自身的 soft limits。 而要改变 hard limit, 则需要进程有 CAP_SYS_RESOURCE 权限。另外,进程 fork() 出来的子进程,会继承父进程的 limits 设定。具体可参考 getrlimit/setrlimit/prlimit 的手册。

    `ulimit` 是 shell 的内置命令。在执行`ulimit`命令时,其实是 shell 自身调用 getrlimit()/setrlimit() 来获取/改变自身的 limits. 当我们在 shell 中执行应用程序时,相应的进程就会继承当前 shell 的 limits 设定。

    那么一个 shell 的初始 limits 是谁设定的? 通常是 pam_limits 设定的。顾名思义,pam_limits 是一个 PAM 模块,用户登录后,pam_limits 会给用户的 shell 设定在 limits.conf 定义的值。我们可以开启 pam_limits 的 debug 来查看大致过程:
    [cc]
    [root@rhel674 ~]# cat /etc/security/limits.conf | grep -v ^# | grep -v ^$
    test hard memlock 102410

    [root@rhel674 ~]# grep pam_limits /etc/pam.d/password-auth-ac
    session required pam_limits.so debug

    [root@rhel674 ~]# tail /var/log/secure
    Sep 4 00:12:49 rhel674 sshd[3151]: Accepted publickey for test from 192.168.122.1 port 41556 ssh2
    Sep 4 00:12:49 rhel674 sshd[3151]: pam_limits(sshd:session): reading settings from ‘/etc/security/limits.conf’
    Sep 4 00:12:49 rhel674 sshd[3151]: pam_limits(sshd:session): process_limit: processing hard memlock 102410 for USER
    Sep 4 00:12:49 rhel674 sshd[3151]: pam_limits(sshd:session): reading settings from ‘/etc/security/limits.d/90-nproc.conf’
    Sep 4 00:12:49 rhel674 sshd[3151]: pam_limits(sshd:session): process_limit: processing soft nproc 1024 for DEFAULT
    Sep 4 00:12:49 rhel674 sshd[3151]: pam_unix(sshd:session): session opened for user test by (uid=0)
    [/cc]
    在 limits.conf 中,对 test 用户设定 memlock 的 hard limit 为 102410. 当用户通过 SSH 登录后,可以看到 pam_limits 为该会话设定了 memlock=102410.
    (更多…)

  • /proc/interrupts 的数值是如何获得的?

    之前为了确认 /proc/interrupts 文件第一列的缩进方式,看了一下相关源码,在这里做一些记录。

    系统一共有多少个中断?

    系统可用的中断数量主要由架构决定,x86 的具体数量可以参考以下定义。

    /* kernel/irq/irqdesc.c */
    
     96 int nr_irqs = NR_IRQS;
     97 EXPORT_SYMBOL_GPL(nr_irqs);
    
    /* arch/x86/include/asm/irq_vectors.h */
    
    152 #define NR_IRQS_LEGACY            16
    153    
    154 #define IO_APIC_VECTOR_LIMIT        ( 32 * MAX_IO_APICS )
    155    
    156 #ifdef CONFIG_X86_IO_APIC
    157 # define CPU_VECTOR_LIMIT       (64 * NR_CPUS)
    158 # define NR_IRQS                    \
    159     (CPU_VECTOR_LIMIT > IO_APIC_VECTOR_LIMIT ?  \
    160         (NR_VECTORS + CPU_VECTOR_LIMIT)  :  \
    161         (NR_VECTORS + IO_APIC_VECTOR_LIMIT))
    162 #else /* !CONFIG_X86_IO_APIC: */
    163 # define NR_IRQS            NR_IRQS_LEGACY
    164 #endif
    

    (更多…)

  • 使用 Pacemaker 搭建集群服务

    背景

    对于一些重要应用,我们希望实现高可用(High-Availability). 在 RHEL7 中,可以使用 Pacemaker 达到这样的效果。

    Pacemaker 是一个集群资源管理器,它负责管理集群环境中资源(服务)的整个生命周期。除了传统意义上的 Active/Passive 高可用,Pacemaker 可以灵活管理各节点上的不同资源,实现如 Active/Active,或者多活多备等架构。

    下图是一个经典的 Active/Passive 高可用例子, Host1/Host2 只有一台服务器在提供服务,另一台服务器作为备机时刻准备着接管服务。

    Pacemaker Active Passive
    Pacemaker Active Passive

    为了节省服务器资源,有时候可以采取 Shared Failover 的策略,两台服务器同时提供不同的服务,留有一台备用服务器接管失效的服务。

    Pacemaker Shared Failover
    Pacemaker Shared Failover

    通过共享文件系统如 GFS2,也可以实现 Active/Active 的多活形式。

    Pacemaker Active Active
    Pacemaker Active Active

    (更多…)

  • Where will log goes during logrotate.

    During logroate, if there comes a log entry, where will this log entry goes? To the rotated file, lost, or to the newly created file?

    It depends.

    The logrotate process

    In RHEL 6 (centos 6), logrotate works like below:

    1. Rename the original file. For example, /var/log/messages –> /var/log/messages.1

    2. Create a new file. In this example, create an empty /var/log/messages

    3. Run post-rotate script. For rsyslog, it would send a HUP signal to rsyslogd.

    (更多…)

  • Socket listen() backlog 是什么?

    listen() backlog 是什么?

    1. Linux 服务器上的一些程序会监听特定端口.

    2. 当有 client 连接到服务器的相应端口,进行完 tcp 三次握手之后,相应的连接会放到服务器相应 socket 的队列,等待服务器的应用程序调用 accept() 来读取这个连接;

    3. 这个队列的长度,就是 listen() backlog.

    以 apache httpd 为例。

    1. httpd 会监听 80 端口;

    2. 当有用户端连接到服务器的 80 端口,首先会进行 tcp 的三次握手。进行完三次握手后,这个连接会被放到 80 端口这个 socket 的队列里,等待 httpd 去获取这个连接;

    3. httpd 随后会调用 accept() 来获取这个连接。这个连接被获取之后,会从这个队列里移除;

    4. 这个监听 80 端口的 socket 对应的队列长度,就是 listen() backlog.
    (更多…)

  • 如何使用 Linux 中的 TCP keepalive?

    tcp-keepalive 是什么

    1. tcp-keepalive,顾名思义,它可以尽量让 TCP 连接“活着”,或者让一些对方无响应的 TCP 连接“宣告死亡”。

    2. 一些特定环境,防火墙会自动断开长期无活动的 TCP 连接,tcp-keepalive 可以在连接无活动一段时间后,发送一个空 ack,使 TCP 连接不会被防火墙关闭。

    3. 一些时候,对方的服务器可能出现宕机或者网络中断等问题, tcp-keepalive 可以帮助断开这些无响应的连接。

    4. tcp-keepalive 需要在应用程序层面针对其所用到的 Socket 进行开启。操作系统层面无法强制所有 socket 启用 tcp-keepalive. (本文在 CentOS/RHEL 6/7 环境进行测试)

    (更多…)

  • umask 怎样影响新建文件的权限?

    1. umask 设置的不是默认权限,而是针对新建文件的一种权限限制。

    2. 应用程序在创建文件时,会指定文件的权限 (mode)。而最终这个新建的文件的权限会是 (mode & ~umask).

    # man 2 open
    
    O_CREAT
        If  the  file does not exist it will be created.  The owner (user ID) of the file is set to the effective user ID of the process.  The group
        ownership (group ID) is set either to the effective group ID of the process or to the group ID of the parent directory  (depending  on  file
        system  type and mount options, and the mode of the parent directory, see the mount options bsdgroups and sysvgroups described in mount(8)).
    
        mode specifies the permissions to use in case a new file is created.  This argument must be supplied when O_CREAT is specified in flags;  if
        O_CREAT is not specified, then mode is ignored.  The effective permissions are modified by the process’s umask in the usual way: The permis-
        sions of the created file are (mode & ~umask).  Note that this mode only applies to future accesses of the newly created  file;  the  open()
        call that creates a read-only file may well return a read/write file descriptor.
    

    (更多…)