xshell一直连接中断 守护进程

last指令

重新登录使用last指令查看登录情况

pts的理解

who:查看目前有谁在线

pts是所谓的伪终端或虚拟终端，具体表现就是你打开一个终端，这个终端就叫pts/0，如果你再打开一个终端，这个新的终端就叫pts /1。

守护进程

比如我们使用 ps -ef | grep nginx  里面有的会显示pts 如果是？就是没有在任何终端执行，在后台是守护进程

我们发现runserver 会有两个进程

是因为django设置自动加载配置文件的原因。在运行命令后面可以加--noreload这样就只会显示一个进程，但是修改文件后，django不会主动去加载配置文件。

如果settings.py中DEBUG=False时，django不会处理静态文件，这就可以使用--insecure参数强制django处理静态文件.

创建守护进程

守护进程创建方法，linux下使用命令：

setsid python hello.py

作用就是：关闭终端，程序也可以后台运行。

退出守护进程

使用 ps -aux 可以查看当前进程。kill -9 [进程号]可关掉程序。

程序死掉也会退出进程

 

查找当前运行进程

Linux系统中grep命令是一种强大的文本搜索工具  可查找指定进程个数

ps -ef | grep nginx

grep --color=auto nginx 这个是自身命令的进程 不需要kill

ps -ef 表示显示所有进程的消息

 

 

 

守护程序，后台运行

我们经常会碰到这样的问题，用 telnet/ssh 登录了远程的 Linux 服务器，运行了一些耗时较长的任务， 结果却由于网络的不稳定导致任务中途失败。如何让命令提交后不受本地关闭终端窗口/网络断开连接的干扰呢？下面举了一些例子， 您可以针对不同的场景选择不同的方式来处理这个问题。

nohup/setsid/&  两种方法都可以实现

在后台运行一般两个一起用 ：

nohup command &

setsid command

nohup 与 & 区别

在于，是否有标准输入

1. sh test.sh &

将sh test.sh任务放到后台 ，关闭xshell，对应的任务也跟着停止。

2. nohup sh test.sh

将sh test.sh任务放到后台，关闭标准输入，终端不再能够接收任何输入（标准输入），重定向标准输出和标准错误到当前目录下的nohup.out文件，即使关闭xshell退出当前session依然继续运行。

3. nohup sh test.sh &

将sh test.sh任务放到后台，但是依然可以使用标准输入，终端能够接收任何输入，重定向标准输出和标准错误到当前目录下的nohup.out文件，即使关闭xshell退出当前session依然继续运行。

原理

hangup 名称的来由：

在 Unix 的早期版本中，每个终端都会通过 modem 和系统通讯。当用户 logout 时，modem 就会挂断（hang up）电话。 同理，当 modem 断开连接时，就会给终端发送 hangup 信号来通知其关闭所有子进程。

解决方法：我们知道，当用户注销（logout）或者网络断开时，终端会收到 HUP（hangup）信号从而关闭其所有子进程。因此，我们的解决办法就有两种途径：要么让进程忽略 HUP 信号，要么让进程运行在新的会话里从而成为不属于此终端的子进程。

1. nohup （不挂断地运行命令）

nohup 无疑是我们首先想到的办法。顾名思义，nohup 的用途就是让提交的命令忽略 hangup 信号。

可见，nohup 的使用是十分方便的，只需在要处理的命令前加上 nohup 即可，标准输出和标准错误缺省会被重定向到 nohup.out 文件中（当前文件夹）。一般我们可在结尾加上"&"来将命令同时放入后台运行，也可用">filename 2>&1"来更改缺省的重定向文件名。

重定向文件名

1. nohup command > myout.file 2>&1 &在上面的例子中，0 – stdin (standard input)，1 – stdout (standard output)，2 – stderr (standard error) ；
2>&1是将标准错误（2）重定向到标准输出（&1），标准输出（&1）再被重定向输入到myout.file文件中。

 

2.nohup 示例
[root@pvcent107 ~]# nohup ping www.ibm.com &
[1] 3059
nohup: appending output to `nohup.out'
[root@pvcent107 ~]# ps -ef |grep 3059
root 3059 984 0 21:06 pts/3 00:00:00 ping www.ibm.com
root 3067 984 0 21:06 pts/3 00:00:00 grep 3059
[root@pvcent107 ~]#

2.& （后台运行相当于新开了一个终端）

这里还有一个关于 subshell 的小技巧。我们知道，将一个或多个命名包含在“()”中就能让这些命令在子 shell 中运行中，从而扩展出很多有趣的功能，我们现在要讨论的就是其中之一。当我们将"&"也放入“()”内之后，我们就会发现所提交的作业并不在作业列表中，也就是说，是无法通过jobs来查看的。让我们来看看为什么这样就能躲过 HUP 信号的影响吧。
subshell 示例 
[root@pvcent107 ~]# (ping www.ibm.com &)
[root@pvcent107 ~]# ps -ef |grep www.ibm.com
root 16270 1 0 14:13 pts/4 00:00:00 ping www.ibm.com
root 16278 15362 0 14:13 pts/4 00:00:00 grep www.ibm.com
[root@pvcent107 ~]#
从上例中可以看出，新提交的进程的父 ID（PPID）为1（init 进程的 PID），并不是当前终端的进程 ID。因此并不属于当前终端的子进程，从而也就不会受到当前终端的 HUP 信号的影响了。

3. setsid（新开子进程）

nohup 无疑能通过忽略 HUP 信号来使我们的进程避免中途被中断，但如果我们换个角度思考，如果我们的进程不属于接受 HUP 信号的终端的子进程，那么自然也就不会受到 HUP 信号的影响了。setsid 就能帮助我们做到这一点。

setsid 示例

[root@pvcent107 ~]# setsid ping www.ibm.com

[root@pvcent107 ~]# ps -ef |grep www.ibm.com

root 31094 1 0 07:28 ? 00:00:00 ping www.ibm.com

root 31102 29217 0 07:29 pts/4 00:00:00 grep www.ibm.com

[root@pvcent107 ~]#

值得注意的是，上例中我们的进程 ID(PID)为31094，而它的父 ID（PPID）为1（即为 init 进程 ID），并不是当前终端的进程 ID。请将此例与nohup例中的父 ID 做比较。