张文杰的博客

周末尝试在自己的Windows Server 2008 R2系统上用vmware player安装RHEL  5.5 X86_x64虚拟机，结果遇到了一些问题，现记录如下。

安装时比较顺利，一切和安装i386系统没有什么区别。问题出在安装完成重启时。开始时系统在“Starting udev”处过不去，过了有十分钟，然后显示启动udev服务超时，但仍卡在此处，此时系统起不来，重试几次仍无法启动。此种情况在安装i386版本的虚拟机上没有出现过。

后来在Google了一下，发现其他人也有类似问题，并发现主要有两种解决方法(只可惜在我的机器都没有成功)。

• 第一种解决方案。　将/etc/udev/rules.d/下的所有以.rules结尾的文件改名，让系统自己去识别硬件启动。
  

  udev下的*.rules文件

  按照此方法改名后，“Starting udev”是可以过去了，但系统启动其他服务非常之慢，几乎无法忍受，最后系统在”Starting auditd”服务处又卡住，无法启动。重试几次也不行。在我的这个环境下，此方法似乎行不通。

• 第二种解决方法。修改虚拟机CPU数量为1，并在虚拟机/etc/grub.conf配置文件kernel一行最后添加clocksource=acpi_pm参数，vware的KB文章有解释。

尝试使用此方法，在添加了此参数后，发现没有起作用，和没有添加此参数时系统启动没有两样，“Starting udev”仍过不去。而且我的虚拟机CPU设置数量是一个。

最终Google了很长时间，反复尝试各种方案，最终无法正常启动RHEL 5.5 x86_x64系统，然后无奈删除之。

如果的有哪位网友知道解决方法，望不吝赐教。谢谢。

Linux RHEL 5.5, RHEL 64, Starting udev, 虚拟机

　　在Linux系统中，需要对一事件的发生通知给正在运行的进程。信号就是这种通知的工具，它的显著特点是：不是用于将数据发送给某一进程，而是通知一个进程某一个特定事件的发生。

　　信号拥有自己特定的名字，均以SIG开始。它们在头文件中被定义为一个正整数，称为信号编号(signal number)。

• SIGHUP：当终端发现断线情况发送给与控制终端相连的控制进程的信号，或控制进程运行结束时发出的信号。它通常用来通知守护进程重新读取系统配置文件。
• SIGINT：进程中断信号，可以用来中断一个正在运行的进程。通常是从终端输入的中断指令，如CTRL+C或Delete。
• SIGQUIT：用于中断前台进程组中的所有进程的信号。由终端输入的退出指令Ctrl+\产生。这一信号在中断进程的同时，还将产生一个core文件。
• SIGILL：执行非法硬件指令时产生的错误。
• SIGTRAP：跟踪陷阱信号。
• SIGIOT：I/O错误信号。
• SIGBUS：系统总线错误时产生的信号。
• SIGFPE：浮点运算中发生溢出错误时产生的信号。
• SIGKILL：可用于终止任何一个进程的信号，只能由系统管理员发出，是不可捕捉种被忽略的信号之一。
• SIGUSR1：用于用户自定义的预留信号，可由用户在应用程序中自行定义。
• SIGSEGV：使用非法内存地址所产生的信号。
• SIGUSR2：同SIGUSR1。
• SIGPIPE：当对一个读进程已经运行结束的管道执行写操作时产生的信号。
• SIGALRM：由alarm函数设定的时间段终止时，会产生此信号。
• SIGTREM：调用kill(1)命令时缺省产生的信号。
• SIGCHLD：当一个子进程结束或中断时，用通知其父进程的信号。必要时，父进程可以通过这一信号来了解子进程状态变化及结束状态信息。但在大多数情况下，这一信号将被忽略。
• SIGCONT：是使已被中断的进程继续执行的信号。当此信号为某一特定进程产生后，如果此时该进程没有被中断，将不会有任何操作发生；但如果该进程是一中断了的进程，即使SIGCONT被阻塞或被忽略，此进程也将会继续进行。
• SIGSTOP：中断进程的信号。它是一个作业信号，同时也是不可被捕捉和不可被忽略的信号之一。
• SIGTSTP：交互式的中断信号。通常是在输入中断键Ctrl+Z时，由终端驱动器产生。
• SIGTTIN：当一个后台进程需要从终端读取数据时，终端驱动器产生的信号。当读取数据的进程忽略或阻塞这个信号，或读取数据的进程所在的进程组是孤立进程组时，信号不会产生，并且读操作将发生错误返回，将errno设置成EIO。
• SIGTTOU：当一个后台进程需要向终端写入数据时，终端驱动器产生的信号。当写入数据的进程忽略或阻塞这个信号，或写数据的进程所在的进程组是孤立进程组时，信号不会产生，并且写操作将发生错误返回，将errno设置成EIO。与SIGTTIN不同的是，进程可以选择对控制终端进行后台写。如果后台写不被允许则同SIGTTIN信号一样。
• SIGURG：套接字上出现紧急情况时产生的信号。
• SIGXCPU：超出CPU时间限制时产生的信号。
• SIGXFSZ：超出文件大小时产生的信号。
• SIGVTALRM：虚拟定时器报警信号。
• SIGPROF：Profiling定时器报警信号。
• SIGWINCH：终端窗口改变时产生的信号。
• SIGIO：表示某个特定文件描述符上可以进行I/O操作的信号。
• SIGPWR：电源失效的信号。
• SIGABRT：调用abort函数时产生的信号，将会使进程非正常结束。
• SIGEMT：实现性定义硬件错误发生时产生的错误。

　　其中，SIGCHLD、SIGCONT、SIGSTOP、SIGTSTP、SIGTTIN、SIGTTOU这六个信号被称为作业控制信号，它们的共同特点是：都是用于协调和组织各进程运行的，即用于实现所谓作业控制的。

　　原创文章如转载，请注明：转载自张文杰的博客 [ http://zhangwenjie.net ]

　　本文链接地址：http://zhangwenjie.net/archives/367.html

Linux Linux, 中断, 信号.进程通信

　　由于公司的电脑不能直接上网，要想查资料需要去专门上网的公用机上才行。

　　这几天发现在公用机的IE浏览器上输入Google的主页时，打开的页面却是baidu的页面，但在同一机器上的Google Chrome浏览器却没有出现同样的问题。这时大家都认为Google网站被”baidu”劫持了。

　　出现这种输入一个网址却出现另一个网址网页的现象的原因一般来说只有一个，那就是修改了C:\windows\system32\drivers\etc\hosts文件。修改成了类似如下的记录:

xxx.xxx.xxx.xxx  www.google.com

xxx.xxx.xxx.xxx  www.google.cn

　　这样IE浏览器在发送网址请求时，会先去检查这个hosts文件，如果发现了相应的网址被指定到一个具体IP地址，那么它不再去解析DNS来获取真正的地址，而是直接使用hosts中指定的IP地址，于是就会出现了”劫持”现象，即输入一个网址却出现另一个网址网页的现象。

　　那么为什么Google Chrome浏览器为什么不会出现”劫持”的现象呢？应该是Chrome浏览器根本不会去检查什么hosts文件，而是直接请求DNS解析，这样一定不会错的。

　　这样现象在Linux系统上的Firefox浏览器也会出现。Linux系统上的hosts文件位于/etc/hosts。不管在Windows上还是在Linux上遇到这样的现象，大家还是先去看一下hosts文件是否被修改，说不好还真能解决问题。

Linux, Web, Windows baidu, Chrome, Firefox, Google, IE, Linux, 百度, 谷歌