行云无鸣

2008-09-17

对SIGHUP信号的响应

Filed under: 未分类 — 标签:, , , , , — hellyguo @ 23:13

同事又犯了老错误,将脚本当作job在后台执行后,直接关闭了终端。

经我提醒后,记起来了。

他问我原因,解释如下:

1.若是经exit正常退出控制进程,则仅仅对所有在前台的进程发出SIGHUP信号

2.若是未经exit退出控制进程,直接关闭终端,则向控制进程和后台进程发出SIGHUP信号

再转段网上的文字:

异常退出与执行exit

——secureCRT异常退出和执行exit的区别?如果直接关闭secureCRT(此处假设是使用ssh登录终端的),那么对于被登录的系统来说,就是远端程序异常断连。和我们突然断网掉线是一样 的效果。这种情况下,用户并没有信号发送,而是sshd服务检测到对端响应超时,然后向之前建立起的连接以及该连接下(ssh登录后会分配一个bash给 用户)的进程发送结束信号。如果部分进程忽略sshd发送的信号,进程不退出,在分配给用户的bash退出后,该进程将被init进程接管。

另外还有一篇很好的文章,SIGHUP信号与控制终端

2008-04-19

良好的习惯

Filed under: 未分类 — 标签:, , , , — hellyguo @ 11:35

公司有台服务器,需要定时生成文件后向另一台服务器转发。故,写了一个Shell脚本来实现该功能。

执行命令:

#./freshfiel.sh &

命令就在后台自顾自跑了。

移交给同事后,同事说每次他维护机器重启后,执行该命令后,过段时间该进程就down下来了。我就奇怪,我自己启动。结果启动方法都一样,我的进程就好好地跑着。

次数多了,也烦了,想必须找出原因。

昨天正好机子维护。重启后,我就看着他操作,命令是一样的。唯一不同的是,我每次操作完,都是用exit正常签退后才关闭终端的。而我同事是操作完毕不签退直接关闭终端。

原因就在这里。一旦正常签退,后台执行的进程即会转移父进程为init进程:1。而未正常签退的状态下,进程是被kill下来了。

可见,良好的操作习惯之重要!

%d 博主赞过: