首先，在安装pygtk使用easy_install是行不通的。因为不只是要编译C代码，更需要检测机器状况，因此必须以进行常规源代码编译的方式进行安装，如configure、make、make install等。

　　另外，安装pygtk需要依赖于PyGObject，其又依赖于GObject-Introspection，而要安装GObject-Introspection，又必须安装GLIB，安装GLIB可能会安装升级gettext，因为旧版的gettext不能识别GLIB中的一些新方法。另外，安装这些包时还会要求版本号不能低于某某。于是，错综复杂，安装、卸载，最终还是没有成功。

　　刚刚看了一下pygtk官网，似乎在windows下也能安装。这个周末找个时间再好好研究一下，争取能安装成功pygtk。

　　有在linux下成功安装pygtk的朋友，希望能不吝赐教。谢谢了!

安装时比较顺利，一切和安装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系统，然后无奈删除之。

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

　　信号拥有自己特定的名字，均以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

　　这几天发现在公用机的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文件是否被修改，说不好还真能解决问题。