Linux下安装LaTeX环境

November 24th, 2014 by JasonLe's Tech 1,263 views

由于我使用的是Fedora 20 ，可以直接使用yum机制安装。Ubuntu/Debian 用户可以使用apt-get安装。

Linux主要存在的问题是众多fonts文件的缺失，所以当我们编译中文pdf时，经常会出现fonts cannot found的现象。本文主要解决这个问题：

1.从别处拷贝需要的字体，从Windows的C:/Windows/Fonts下拷贝最常使用的几种字体：msyh.ttf（微软雅黑）  simfang.ttf（仿宋）  simhei.ttf（黑体）  simkai.ttf（楷体）  simsun.ttc（宋体）。
拷贝到Linux的/usr/share/fonts/winfonts/目录下
#chmod a+x  /usr/share/fonts/winfonts/

# cd /usr/share/fonts/winfonts/
# mkfontscale
# mkfontdir
# fc-cache

拷贝完成之后一定要注意使用chmod给字体权限,为X字体创建可裁剪的索引，在一个目录中创建X字体文件的索引，建立字体信息缓存文件。

使用fc-list 命令查看：

➜  TIR_CN git:(master) ✗ fc-list :lang=zh-cn
/usr/share/fonts/winfonts/simsun.ttc: 新宋体,NSimSun:style=Regular
/usr/share/fonts/wqy-zenhei/wqy-zenhei.ttc: 文泉驿点阵正黑,文泉驛點陣正黑,WenQuanYi Zen Hei Sharp:style=Regular
/usr/share/fonts/adobe-source-han-sans-cn/SourceHanSansCN-Regular.otf: 思源黑体 CN,Source Han Sans CN,Source Han Sans CN Regular,思源黑体 CN Regular:style=Regular
/usr/share/fonts/google-droid/DroidSansFallback.ttf: Droid Sans:style=Regular
/usr/share/fonts/winfonts/simkai.ttf: 楷体,KaiTi:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
/usr/share/fonts/winfonts/simfang.ttf: 仿宋,FangSong:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
/usr/share/fonts/adobe-source-han-sans-cn/SourceHanSansCN-ExtraLight.otf: 思源黑体 CN,Source Han Sans CN,Source Han Sans CN ExtraLight,思源黑体 CN ExtraLight:style=ExtraLight,Regular
/usr/share/fonts/adobe-source-han-sans-cn/SourceHanSansCN-Normal.otf: 思源黑体 CN,Source Han Sans CN,Source Han Sans CN Normal,思源黑体 CN Normal:style=Normal,Regular
/usr/share/fonts/cjkuni-uming/uming.ttc: AR PL UMing TW MBE:style=Light
/usr/share/fonts/winfonts/simsun.ttc: 宋体,SimSun:style=Regular
/usr/share/fonts/winfonts/simhei.ttf: 黑体,SimHei:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
/usr/share/fonts/adobe-source-han-sans-cn/SourceHanSansCN-Medium.otf: 思源黑体 CN,Source Han Sans CN,Source Han Sans CN Medium,思源黑体 CN Medium:style=Medium,Regular
/usr/share/fonts/gnu-free/simhei.ttf: 黑体,SimHei:style=Regular
........

/usr/share/fonts/winfonts/simsun.ttc: 宋体,SimSun:style=Regular
我们可以看到中文后面的那个SimSum就是在linux中的字体符号.

我们打开/usr/share/texlive/texmf-dist/tex/latex/ctex/fontset/ctex-xecjk-winfonts.def
修改我们缺少的字体。

% ctex-xecjk-winfonts.def: Windows 的 xeCJK 字体设置，默认为六种中易字体
% vim:ft=tex

\setCJKmainfont[BoldFont={SimHei},ItalicFont={KaiTi}]
  {SimSun}
\setCJKsansfont{SimHei}
\setCJKmonofont{FangSong}

\setCJKfamilyfont{zhsong}{SimSun}
\setCJKfamilyfont{zhhei}{SimHei}
\setCJKfamilyfont{zhkai}{KaiTi}
\setCJKfamilyfont{zhfs}{FangSong}
% \setCJKfamilyfont{zhli}{LiSu}
% \setCJKfamilyfont{zhyou}{YouYuan}

\newcommand*{\songti}{\CJKfamily{zhsong}} % 宋体
\newcommand*{\heiti}{\CJKfamily{zhhei}}   % 黑体
\newcommand*{\kaishu}{\CJKfamily{zhkai}}  % 楷书
\newcommand*{\fangsong}{\CJKfamily{zhfs}} % 仿宋
% \newcommand*{\lishu}{\CJKfamily{zhli}}    % 隶书
% \newcommand*{\youyuan}{\CJKfamily{zhyou}} % 幼圆

\endinput

然后大功告成，可以使用xelatex生成pdf文件了。

参考文档

Posted in Code杂谈

Configure Manager Rules

November 18th, 2014 by JasonLe's Tech 3,715 views

CM的职责就是对与git 进行管理，将不合格的commit拒绝在仓库以外。

详细开发流程

但是每周CM的职责除了合并开发成员的branch外，还要进行commit的汇报，比如commit多少，merge多少，reject多少等等。

比如我们将个git log >/tmp/git.log文件中，然后进行分析。

比如我们统计git log 中的commit 信息 可以使用 grep commit git.log | wc -l 方式计算commit行数。

$grep commit git.log | wc -l
$grep Merge git.log | wc -l

因为git log 的数据非常整齐，可以使用vim的块操作

输入v进入visual模式，然后可以移动光标选取一段文本。

d———->剪贴

y———->复制

p———->粘贴

对于经常登陆的机子我们可以生成dsa

use ”ssh-keygen -t dsa” to generate a key
then use ”ssh-copy-id /home/lzz/.ssh/id_dsa.pub user@server IP”
Ok, now you can ssh and git pull/push without password

对于一些system如果ssh-copy-id 无法使用，我们可以手动将/home/lzz/.ssh/id_dsa.pub 手动拷贝到目标机器的目标用户目录下，
比如/home/user/.ssh/id_dsa_pub.A. 然后将这个id_dsa_pub.A >> authority 后面。

这些是CM的日常工作，除了这些，对于master branch与 local branch的backup也非常重要。
比如我有两台机子都要备份，我们可以把资料相互备份然后传输到对方的机子上。我们知道两台主机数据同时损坏的概率非常下。

对于每台主机，CM应该记录到以下几点：

security incidents
power-fail
server off-line
filesystem overruns (filesystem full)
dmesg warnings/errors
abnormal operational behavior

backup_policy

cm_rules

对于一些备份的例行任务，我们可以使用crontab -e 命令创建定时任务，关于这个网上的使用比较多，我们可以参考
http://www.cnblogs.com/peida/archive/2013/01/08/2850483.html

Posted in Code杂谈, Git

RHEL系(Fedora,CentOS) rpm打包

November 6th, 2014 by JasonLe's Tech 1,411 views

现在Linux下越来越倾向于打包二进制安装文件，rpm，deb都是这种类型。

但是作为内核开发人员我们要对程序进行调试，就要有debug-info package，但是默认内核人是不提供debug-info的包，所以需要我们自动生成。

一般我们要用root用户进行编译，但是编译rpm包，至少需要20GB的临时文件空间！

一键操作：make rpm ———–>自动身成rpmtree,kernel.spec文件，自动编译。

——————————

详细定制：

下面开始创建：

1.用所在的用户输入rpmdev-setuptree，然后会在该用户的目录下生成${HOME}/rpmbuild/SOURCES ，${HOME}/rpmbuild/SPECS 和 ${HOME}/rpmbuild/BUILD 。

2.在多数源玛目录下会自动带有kernel.spec的文件，将这个文件放到${HOME}/rpmbuild/SPECS中，将kernel-3.14.8.tar.gz 放入${HOME}/rpmbuild/SOURCES中，然后在SOURCE中放入.config,

默认生成的spec带着”%debug_package %{nil}” 这就意味着不会生成带debug_info的包。如果需要，我们就要注释掉。

cp .config ~/rpmbuild/SOURCES/config-`uname -m`-generic

3.切换到SPECS目录下。

建立所有内核配置：
rpmbuild -bb –target=`uname -m` kernel.spec

关闭指定的内核配置（为了更快的建立）：
rpmbuild -bb –without <option> –target=`uname -m` kernel.spec

其中“ option ”的有效值包括xen、smp、up、pae、kdump、debug 和 debuginfo。指定 –without debug 会剔除内核中的调试代码，指定 –without debuginfo 会禁止建立 kernel-debuginfo 包。

只建立一个特定的内核：
rpmbuild -bb –with <option> –target=`uname -m` kernel.spec
“ option ”的有效值包括 xenonly、 smponly 和 baseonly 。

例如，只建立 kernel 和 kernel-devel 包的命令是：

rpmbuild -bb –with baseonly –without debuginfo –target=`uname -m` kernel.spec
建立时包含固件，用如下命令：

rpmbuild -bb –with baseonly –with firmware –without debuginfo  –target=`uname -m` kernel.spec
建立的过程需要很长时间。会在屏幕上打印大量的信息。这些信息可以被忽略，除非建立过程因为一个 error 而停止。如果成功完成建立过程，一个新的内核包会出现在 ~/rpmbuild/RPMS 目录。

 

参考：

https://fedoraproject.org/wiki/Building_a_custom_kernel
https://fedoraproject.org/wiki/How_to_create_an_RPM_package/zh-cn
http://blog.csdn.net/justlinux2010/article/details/9905425
http://www.linuxfly.org/post/130/

Posted in Code杂谈, Linux

kdump 在Debian/Fedora/CentOS下的配置

November 1st, 2014 by JasonLe's Tech 3,384 views

Update 2014/11/6

0.why we use kdump?

Kdump is a kernel crash dumping mechanism and is very reliable because the crash dump is captured from the context of a freshly booted kernel and not from the context of the crashed kernel. Kdump uses kexec to boot into a second kernel whenever system crashes. This second kernel, often called the crash kernel, boots with very little memory and captures the dump image.

The first kernel reserves a section of memory that the second kernel uses to boot. Kexec enables booting the capture kernel without going through the BIOS, so contents of the first kernel’s memory are preserved, which is essentially the kernel crash dump.
使用mce-inject注入fatal错误的时候，system会直接panic。不像UCNA，SRAO等可以通过mcelog，rasDamon查看。
system在进去machine check 后，内核调用，用户态下的mcelog，rasDamon都已经无法使用，导致dmesg信息MCE解码信息都无法查看。

kdump原理就是在dump kernel panic后，重新启动后利用kexec载入debug kernel 然后利用这个内核去dump出现panic错误的内核信息。

然后system使用正常kernel启动后，可以分析该dump文件，包括查看demsg/memory/PCIe等各种kernel信息等。
用来诊断kernel出现了哪些致命错误。
在本项目中主要利用该工具用来分析注入mce 错误产生的dumpcore信息。
————————————————————————–

首先我们分清要使用的系统：

1.Fedora Configure

由于Fedora的软件比较新，如果你用的是是Fedora 20

我们直接可以 yum install –enablerepo=fedora-debuginfo –enablerepo=updates-debuginfo kexec-tools crash kernel-debuginfo
下载安装好kdump crash kexec工具

2.然后我们在/etc/default/grub里面的

GRUB_CMDLINE_LINUX=”rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkerne l-param || 🙂 rd.luks=0 vconsole.keymap=us rd.lvm.lv=fedora/root rhgb quiet crashkernel=240M”
最后加入crashkernel=240M

这个预先留出的内存大小，在下次使用就被占用。
一般 1G——80M 2G——-160M 3G——–240M

最后更新grub ：$grub2-mkconfig -o /boot/grub2/grub.cfg 即可

3.重新启动，选择该内核进入system

[root@localhost mce-inject-encode]# service kdump start
Redirecting to /bin/systemctl start kdump.service
[root@localhost mce-inject-encode]# systemctl status kdump
kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled)
Active: active (exited) since 一 2014-10-27 09:15:31 CST; 2 days ago
Process: 652 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
Main PID: 652 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/kdump.service

10月 27 09:15:22 localhost.localdomain systemd[1]: Starting Crash recovery kernel arming...
10月 27 09:15:31 localhost.localdomain kdumpctl[652]: kexec: loaded kdump kernel
10月 27 09:15:31 localhost.localdomain kdumpctl[652]: Starting kdump: [OK]
10月 27 09:15:31 localhost.localdomain systemd[1]: Started Crash recovery kernel arming.
10月 29 09:29:36 localhost.localdomain systemd[1]: Started Crash recovery kernel arming.

4.开始等待panic错误，如果发现panic错误，system会立刻切换到crashkernel收集信息，收集完毕重新启动。

5.进入到system。键入到/var/crash文件夹下有通过kdump产生的文件：

[root@localhost 127.0.0.1-2014.10.29-09:59:07]# ls
vmcore vmcore-dmesg.txt
[root@localhost 127.0.0.1-2014.10.29-09:59:07]# vim vmcore-dmesg.txt

[175451.136453] Triggering MCE exception on CPU 0
[175451.136463] [Hardware Error]: MC0 Error:
[175451.136467] [Hardware Error]: Corrupted MC0 MCE info?
[175451.136469] [Hardware Error]: Error Status: System Fatal error.
[175451.136472] [Hardware Error]: CPU:0 (f:6b:2) MC0_STATUS[-|UE|-|PCC|-]: 0xb200000000000000
[175451.136475] [Hardware Error]: cache level: RESV, tx: INSN
[175451.136480] mce: [Hardware Error]: CPU 0: Machine Check Exception: 0 Bank 0: b200000000000000
[175451.136662] mce: [Hardware Error]: TSC 15f2d1714af92
[175451.136765] mce: [Hardware Error]: PROCESSOR 2:60fb2 TIME 1414547938 SOCKET 0 APIC 0 microcode 0
[175451.136933] [Hardware Error]: MC0 Error:
[175451.137020] [Hardware Error]: Corrupted MC0 MCE info?
[175451.137132] [Hardware Error]: Error Status: System Fatal error.
[175451.137249] [Hardware Error]: CPU:0 (f:6b:2) MC0_STATUS[-|UE|-|PCC|-]: 0xb200000000000000
[175451.137412] [Hardware Error]: cache level: RESV, tx: INSN
[175451.137431] mce: [Hardware Error]: Machine check: Invalid
[175451.137431] Kernel panic - not syncing: Fatal machine check on current CPU

通过vmcore-dmesg.txt 可以查看panic时的dmesg 。如果需要对panic core 进行debug的时候，需要
使用[root@localhost 127.0.0.1-2014.10.29-09:59:07]# crash vmcore /usr/lib/debug/lib/xxxxxx/vmlinux

PS:注意这个vmcore与你的debugcore 版本要一致否则无法进行crash！

创建kernel-debuginfo-devel
https://fedoraproject.org/wiki/Building_a_custom_kernel
https://fedoraproject.org/wiki/How_to_create_an_RPM_package/zh-cn
http://blog.csdn.net/justlinux2010/article/details/9905425
http://www.linuxfly.org/post/130/

具体操作看http://www.lizhaozhong.info/archives/1143

——————————————————————————————————

CentOS 7 Configure

CentOS 7 与 Fedora很类似，这个发行版在程序安装的时候就提供了kdump配置，为了我们手动安装，我们先手动关闭。

CentOS 7 与 Fedora操作类似，都是使用yum机制安装程序。在本项目中，我制作了kernel-3.14.8.rpm包，方便后期注入使用。

CentOS 7 使用了systemctl管理系统service ，当我们安装完成3.14.8 内核，与kdump-tools等工具链。
配置文件放在/etc/sysconfig/kdump中

当然我们要在/etc/default/grub中定义crashkernel的大小，重启以后，使用systemctl enable kdump.service 设置为开机启动。
systemctl start kdump.service 启动kdump.service 服务。
systemctl status kdump.service 可以查看该服务状态：

[root@localhost sysconfig]# systemctl status kdump.service -l
kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled)
Active: active (exited) since 一 2014-12-22 09:10:30 EST; 1 day 11h ago
Process: 809 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
Main PID: 809 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/kdump.service

12月 22 09:10:27 localhost.localdomain kdumpctl[809]: cat: /sys/kernel/security/securelevel: No such file or directory
12月 22 09:10:30 localhost.localdomain kdumpctl[809]: kexec: loaded kdump kernel
12月 22 09:10:30 localhost.localdomain kdumpctl[809]: Starting kdump: [OK]
12月 22 09:10:30 localhost.localdomain systemd[1]: Started Crash recovery kernel arming.

当遇到panic事件后，kdump会转储故障内核,重新启动后，我们以可以在/var/crash下找到vmcore

具体加载vmcore方式是使用
[root@localhost 127.0.0.1-2014.12.22-09:09:51]# crash vmcore /boot/vmlinux-3.14.8.bz2

/boot/vmlinux-3.14.8.bz2 是我们自己打包的rpm包，带有debug symbol 的 镜像，可以用于debug vmcore

————————————
Debian Configure

因为在本项目中我们使用kernel 3.14.8,所以我们要使用crash 7.0.8.在Deibian 7.6中，默认的crash 6.0.6版本中
无法分析kernel 3.6以及以后内核的SLAB内存，crash载入dump文件，会出现以下错误信息：

please wait... (gathering kmem slab cache data)
crash: invalid structure member offset: kmem_cache_s_next
FILE: memory.c LINE: 7903 FUNCTION: kmem_cache_init()
[/usr/bin/crash] error trace: 466a99 =&gt; 47b44b =&gt; 491f5c =&gt; 547d43
547d43: OFFSET_verify+164
491f5c: (undetermined)
47b44b: vm_init+10841
466a99: main_loop+239

一个方法是我们可以在/etc/apt/source.list 中将wheezy改为jessie，可以顺利将crash升级到7.0.8

Debian Configure 有一个问题是需要手动配置crashkernel 内核地址

1. aptitude install kdump-tools crash kexec-tools makedumpfile

2.在 /etc/default/grub中修改为GRUB_CMDLINE_LINUX_DEFAULT=”crashkernel=128M quiet”

3.# update-grub2
4.里面的DEBUG_KERNEL也要对应产生的vmcore版本,进行crash时vmcore与这个debug_kernel must版本一致!

主要是在编译内核的目录下使用make deb-pkg 这时会产生专门针对3.14.8内核的dbg vmlinux，以及header

root@debian:/usr/src/kernels# ls
linux-3.14.8 linux-headers-3.14.8_3.14.8-2_amd64.deb linux-libc-dev_3.14.8-2_amd64.deb
linux-3.14.8.tar linux-image-3.14.8_3.14.8-2_amd64.deb
linux-firmware-image-3.14.8_3.14.8-2_amd64.deb linux-image-3.14.8-dbg_3.14.8-2_amd64.deb

然后安装这些生成的deb.
5.在/etc/default/kdump-tools中配置为

USE_KDUMP=1
KDUMP_SYSCTL="kernel.panic_on_oops=1"
KDUMP_KERNEL=/boot/vmlinuz-3.14.8
KDUMP_INITRD=/boot/initrd.img-3.14.8
KDUMP_COREDIR="/var/crash"
KDUMP_FAIL_CMD="reboot -f"
DEBUG_KERNEL=/usr/lib/debug/boot/vmlinux-3.14.8
MAKEDUMP_ARGS="-c -d 31"

//在/etc/default/kexec中配置为：
root@debian:/usr/src/kernels# cat /etc/default/kexec
# Defaults for kexec initscript
# sourced by /etc/init.d/kexec and /etc/init.d/kexec-load

# Load a kexec kernel (true/false)
LOAD_KEXEC=true

# Kernel and initrd image
KERNEL_IMAGE="/boot/vmlinuz-3.14.8"
INITRD="/boot/initrd.img-3.14.8"

# If empty, use current /proc/cmdline
APPEND=""

# Load the default kernel from grub config (true/false)
USE_GRUB_CONFIG=false

6.重新启动：

root@debian:/usr/src/kernels# service kdump-tools restart
[ ok ] unloaded kdump kernel.
[ ok ] loaded kdump kernel.

7.kdump就开始捕捉错误。

8.关于分析dump的操作crash

This GDB was configured as "x86_64-unknown-linux-gnu"...

      KERNEL: kernel_link
    DUMPFILE: dump.201410311601  [PARTIAL DUMP]
        CPUS: 2
        DATE: Fri Oct 31 16:01:04 2014
      UPTIME: 00:09:57
LOAD AVERAGE: 0.21, 0.11, 0.07
       TASKS: 209
    NODENAME: debian
     RELEASE: 3.14.8
     VERSION: #2 SMP Fri Oct 31 14:38:20 CST 2014
     MACHINE: x86_64  (2199 Mhz)
      MEMORY: 1.7 GB
       PANIC: "Kernel panic - not syncing: Fatal machine check on current CPU"
         PID: 0
     COMMAND: "swapper/1"
        TASK: ffff88006d7ea8e0  (1 of 2)  [THREAD_INFO: ffff88006d7ee000]
         CPU: 1
       STATE: TASK_RUNNING (PANIC)

crash> help

*              files          mach           repeat         timer
alias          foreach        mod            runq           tree
ascii          fuser          mount          search         union
bt             gdb            net            set            vm
btop           help           p              sig            vtop
dev            ipcs           ps             struct         waitq
dis            irq            pte            swap           whatis
eval           kmem           ptob           sym            wr
exit           list           ptov           sys            q
extend         log            rd             task           

crash version: 7.0.8    gdb version: 7.6
For help on any command above, enter "help <command>".
For help on input options, enter "help input".
For help on output options, enter "help output".

crash>

参考：

http://wiki.incloudus.com/display/DOC/Debian+-+Kdump
http://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
http://debian-handbook.info/browse/stable/sect.kernel-compilation.html

Posted in Linux

C/S模型下Server 中fork()的健壮性

October 30th, 2014 by JasonLe's Tech 1,176 views

C/S模型下Server 下编程非常依赖fork（）子进程去处理具体的业务逻辑。 每当accept()接收到一个TCP连接时，主服务器进程就fork一个子服务器进程。子服务器进程调用相应的函数，通过client_fd（连接套接字）对客户端发来的网络请求进程处理；由于客户端的请求已被子服务进程处理，那么主服务器进程就什么也不做，通过sockfd（监听套接字）继续循环等待新的网络请求。

..........
while (1) {
	sin_size = sizeof(struct sockaddr_in);
	if ((client_fd = accept(sockfd, (struct sockaddr *)&remote_addr, &sin_size)) == -1) {
		my_error("accept", errno, __LINE__);
		continue;
	}

	if ((pid = fork()) == 0) {
		close(sockfd);
		process_client_request(client_fd);
		close(client_fd);
		exit(0);
	} else if (pid > 0)
		close(client_fd);
	else
		my_error("fork", errno, __LINE__);
}

每个文件都有一个引用计数，该引用计数表示当前系统内的所有进程打开该文件描述符的个数。套接字是一种特殊的文件，当然也有引用计数。 当fork执行后，由于子进程复制了父进程的资源，所以子进程也拥有这两个套接字描述符，则此时sockfd和client_fd的引用计数都为2。只有当子进程处理完客户请求时，client_fd的引用计数才由于close函数而变为0。 但是这里存在一个严重的问题：如果客户端意外退出，就会导致server子进程成为僵尸进程。我们设想如果server非常繁忙，就会导致system出现大量的zombie进程！system会应该耗尽系统资源而宕机！ 这是因为

当一个子进程先于父进程结束运行时，它与其父进程之间的关联还会保持到父进程也正常地结束运行，或者父进程调用了wait才告终止。

子进程退出时，内核将子进程置为僵尸状态，它只保留最小的一些内核数据结构，以便父进程查询子进程的退出状态。

进程表中代表子进程的数据项是不会立刻释放的，虽然不再活跃了，可子进程还停留在系统里，因为它的退出码还需要保存起来以备父进程中后续的wait调用使用。

所以我们要处理zombie进程！ 两种方式：

  • 调用wait或者waitpid函数查询子进程退出状态，此方法父进程会被挂起。
  • 如果不想让父进程挂起，可以在父进程中加入一条语句：signal(SIGCHLD,SIG_IGN);表示父进程忽略SIGCHLD信号，该信号是子进程退出的时候向父进程发送的。

当子进程终止时会给父进程发送SIGCHLD信号，因此我们可以利用信号处理函数捕获这个信号并对僵死进程进行处理。我们知道在父进程中调用wait函数可以防止先于父进程终止的子进程编程僵死进程

void sig_zchild(int signo)
{
	pid_t pid;
	int stat;

	pid = wait(&stat);
        printf("child %d terminated\n", pid);
	return;
}

修改服务器程序，在accept函数调用之前调用signal函数：

	if(listen(sockfd, BACKLOG) == -1) {

		printf("listen error!\n");
		exit(1);
	}

	if (signal(SIGCHLD, sig_zchild) == SIG_ERR) {
		printf("signal error!\n");
		exit(1);
	}

	while (1) {

		sin_size = sizeof(struct sockaddr_in);
		if ((client_fd = accept(sockfd, (struct sockaddr *)&remote_addr,
&sin_size)) == -1) {

			printf("accept error!\n");
			continue;
		}
		…… ……
	}//while

但是这个程序仍存在一个问题：当多个子进程同时退出时，会导致父进程无法同时处理SIGCHILD信号，导致有部分子进程zombie。

void sig_zchild(int signo)
{
 pid_t pid;
 int stat;

 while ((pid = waitpid(-1, &stat, WNOHANG)) > 0)
 printf("child %d terminated\n", pid);

 return;
}

使用while可以等待SIGCHILD信号，直到处理完成！ 信号在内核中也是存放在队列中！

 

 

参考：http://www.cnblogs.com/mickole/p/3187770.html

Posted in C/C++, Linux下C编程