linux服务之udevd

http://www.ibm.com/developerworks/cn/linux/l-cn-udev/
[root@localhost ~]# uname -r
2.6.32-431.el6.x86_64
udev-147-2.51.el6.x86_64
此版本的udev变动较大

什么是 udev?
udev 是 Linux2.6 内核里的一个功能，它替代了原来的 devfs，成为当前 Linux 默认的设备管理工具。udev 以守护进程的形式运行，通过侦听内核发出来的 uevent 来管理 /dev目录下的设备文件。不像之前的设备管理工具，udev 在用户空间 (user space) 运行，而不在内核空间 (kernel space) 运行。
使用 udev 的好处：
我们都知道，所有的设备在 Linux 里都是以设备文件的形式存在。在早期的 Linux 版本中，/dev目录包含了所有可能出现的设备的设备文件。很难想象 Linux 用户如何在这些大量的设备文件中找到匹配条件的设备文件。现在 udev 只为那些连接到 Linux 操作系统的设备产生设备文件。并且 udev 能通过定义一个 udev 规则 (rule) 来产生匹配设备属性的设备文件，这些设备属性可以是内核设备名称、总线路径、厂商名称、型号、序列号或者磁盘大小等等。
    动态管理：当设备添加 / 删除时，udev 的守护进程侦听来自内核的 uevent，以此添加或者删除 /dev下的设备文件，所以 udev 只为已经连接的设备产生设备文件，而不会在 /dev下产生大量虚无的设备文件。
    自定义命名规则：通过 Linux 默认的规则文件，udev 在 /dev/ 里为所有的设备定义了内核设备名称，比如 /dev/sda、/dev/hda、/dev/fd等等。由于 udev 是在用户空间 (user space) 运行，Linux 用户可以通过自定义的规则文件，灵活地产生标识性强的设备文件名，比如 /dev/boot_disk、/dev/root_disk、/dev/color_printer等等。

udev 工作流程图：

相关术语：
    设备文件：由于本文以较通俗的方式讲解 udev，所以设备文件是泛指在 /dev/下，可被应用程序用来和设备驱动交互的文件。而不会特别地区分设备文件、设备节点或者设备特殊文件。
    devfs：devfs是 Linux 早期的设备管理工具，已经被 udev 取代。
    sysfs：sysfs是 Linux 2.6 内核里的一个虚拟文件系统 (/sys)。它把设备和驱动的信息从内核的设备模块导出到用户空间 (userspace)。从该文件系统中，Linux 用户可以获取很多设备的属性。
    devpath：本文的 devpath是指一个设备在 sysfs文件系统 (/sys)下的相对路径，该路径包含了该设备的属性文件。udev 里的多数命令都是针对 devpath操作的。例如：sda的 devpath是 /block/sda，sda2 的 devpath是 /block/sda/sda2。
    内核设备名称：设备在 sysfs里的名称，是 udev 默认使用的设备文件名。

udev 的配置和使用：

syslog默认会记录 udev 的日志，Linux 用户只能修改日志的级别 (err、info、degub 等 )；设备的权限不能在 udev.conf 里设定，而是要在规则文件 (*.rules) 里设定。
udev 的规则和规则文件
规则文件是 udev 里最重要的部分，默认是存放在 /etc/udev/rules.d/下。所有的规则文件必须以“.rules”为后缀名。RHEL 有默认的规则文件，这些默认规则文件不仅为设备产生内核设备名称，还会产生标识性强的符号链接。
udev 按照规则文件名的字母顺序来查询全部规则文件，然后为匹配规则的设备管理其设备文件或文件链接。虽然 udev 不会因为一个设备匹配了一条规则而停止解析后面的规则文件，但是解析的顺序仍然很重要。通常情况下，建议让自己想要的规则文件最先被解析。比如，创建一个名为 /etc/udev/rules.d/10-myrule.rules的文件，并把你的规则写入该文件，这样 udev 就会在解析系统默认的规则文件之前解析到你的文件。
在规则文件里，除了以“#”开头的行（注释），所有的非空行都被视为一条规则，但是一条规则不能扩展到多行。规则都是由多个 键值对（key-value pairs）组成，并由逗号隔开，键值对可以分为 条件匹配键值对( 以下简称“匹配键 ”) 和 赋值键值对( 以下简称“赋值键 ”)，一条规则可以有多条匹配键和多条赋值键。匹配键是匹配一个设备属性的所有条件，当一个设备的属性匹配了该规则里所有的匹配键，就认为这条规则生效，然后按照赋值键的内容，执行该规则的赋值。
KERNEL=="sda", NAME="my_root_disk", MODE="0660"
KERNEL 是匹配键，NAME 和 MODE 是赋值键。这条规则的意思是：如果有一个设备的内核设备名称为 sda，则该条件生效，执行后面的赋值：在 /dev下产生一个名为 my_root_disk的设备文件，并把设备文件的权限设为 0660。
仅当操作符是“==”或者“!=”时，其为匹配键；若为其他操作符时，都是赋值键。

制定 udev 规则和查询设备信息的实例：
如何查找设备的信息 ( 属性 ) 来制定 udev 规则：
当我们为指定的设备设定规则时，首先需要知道该设备的属性，比如设备的序列号、磁盘大小、厂商 ID、设备路径等等。通常我们可以通过以下的方法获得：
    查询sysfs文件系统：
    前面介绍过，sysfs 里包含了很多设备和驱动的信息。
    例如：设备 sda 的 SYSFS{size} 可以通过 cat /sys/block/sda/size得到；SYSFS{model} 信息可以通过 cat /sys/block/sda/device/model得到
    udevinfo命令：
    udevinfo 可以查询 udev 数据库里的设备信息。例如：用 udevinfo 查询设备 sda 的 model 和 size 信息：
    其他外部命令：
清单 10. 产生网卡设备文件的规则
 SUBSYSTEM=="net", SYSFS{address}=="AA:BB:CC:DD:EE:FF", NAME="public_NIC"
该规则表示：如果存在设备的子系统为 net，并且地址 (MAC address) 为“AA:BB:CC:DD:EE:FF”，为该设备产生一个名为 public_NIC 的设备文件。
清单 11. 为指定大小的磁盘产生符号链接的规则
 SUBSYSTEM=="block", SYSFS{size}=="71096640", SYMLINK ="my_disk"
该规则表示：如果存在设备的子系统为 block，并且大小为 71096640(block)，则为该设备的设备文件名产生一个名为 my_disk 的符号链接。

其中syspath都是指/sys下的路径：如/block/sda
udevadm info --help
udevadm test /block/sda
udevadm info  --query=all --path=/block/sda
udevadm info  --query=all --name=/dev/sda   结果同上
udevadm info  --export-db  | less 查看udev database，输出所有节点信息
[root@109-com1 scripts]# ps -ef|grep udevd　　相关进程
root       431     1  0 Aug28 ?        00:00:00 /sbin/udevd -d
root      1199   431  0 Aug28 ?        00:00:00 /sbin/udevd -d
root     19382   431  0 Aug30 ?        00:00:00 /sbin/udevd -d
[root@localhost ~]# start_udev    使修改的配置文件生效，不用重启系统
正在启动 udev：                                            [确定]

udevd创建每一个节点的时候，都会fork出一个新的进程来单独完成这个节点的创建工作。
Uevent_seqnum 用来标识当前的uevent事件的序号（已产生了多少uevent事件），您能够通过如下操作来查看：
$ cat /sys/kernel/uevent_seqnum

12.eth0变为eth1的解决办法

udev 会在系统引导的过程中识别网卡，将mac地址和网卡名称对应起来记录在udev的规则脚本中, 所以在workstation改虚拟机的mac地址，会发生此种情况。udev会自动将其命名为eth1（累加的原则），所以在你的系统启动后，你使用 ifconfig看到的网卡名为eth1。
vi /etc/udev/rules.d/70-persistent-net.rules
改mac，改name，reboot

或者删除此规则文件，然后reboot，系统会重新绑定。

很多Linux distribution使用udev动态管理设备文件，并根据设备的信息对其进行持久化命名。例如在Debian
etch中，udev会在系统引导的过程中识别网卡，将mac地址和网卡名称对应起来记录在udev的规则脚本中。而VMware会自动生成虚拟机的
mac地址。这样，由于基本系统的虚拟机已经记录了该虚拟机的网卡mac地址对应于网卡eth0，在克隆出的虚拟机中由于mac地址发生改变，udev会

自动将该mac对应于网卡eth1。以此类推，udev会记录所有已经识别的mac与网卡名的关系，所以每次克隆网卡名称会自动加1，而其实kernel
仅仅只识别到一张网卡，跟网卡名相关的网络配置也未发生任何变化。

简单说就是esxi克隆一个虚拟机后，会产生一个新的mac地址，并生成一个新的eth1,但原ifcfg-eth0却未改变，三个地方，
vi /etc/udev/rules.d/70-persistent-net.rules　　删掉原来的eth0的行，将eth1的行名字改为eth0
vi ifcfg-eth0　　将新mac替换原来的mac，这时重启服务service network restart,网络已可以使用，用ifconfig查看时，仍是eth1,还没有改回eth0
ifconfig　　还是看不到eth0，这时需要重启机器，才生效