那你要是做个电子时钟出来总不能带台PC机吧
编好的程序编译过后会出现一个.HEX文件,这个就是烧录程序,也就是机器码
单片机只认识这个的.
把这个程序通过烧录器烧到单片机,单片机就可以按照你的程序运行了.
至于烧到89C51还是其他的,那要看你编的程序能不能烧的下,主要是资源够不够用.
kill 命令通常用于终止执行中的程序。 kill可将指定的信息送至程序。默认送的信息为SIGTERM (信息编号为15),代表关闭进程
kill -9 pid kill -15 pid (效果等同于 kill pid )
其中 9 和 15 指的是信息编号
什么是信息编号
使用kill -l 命令可以查看信息及编号
信息编号代指不同的信息,不同的信息有不同的含义
可以看到 9代表 SIGKILL,15 代表 SIGTERM 所以 ==kill -9 pid 代表 发送SIGKILL信息给这个pid的程序 kill -15 pid 代表 发送SIGTERM信息给这个pid的程序==
那么 SIGTERM(15)和 SIGKILL(9)有什么区别
SIGTERM :当进程接收到SIGTERM后,大多会先释放自己的资源,再停止进程,属于正常关闭进程,但是如果进程正在工作,处理io等,不会立马关闭,或者 进程卡死的情况,都会导致SIGTERM不起作用。
SIGKILL : SIGKILL信号要求进程 立即关闭,强制关闭进程。
工作中关闭进程时,==先kill pid(默认使用编号15),如果不起作用 再使用 kill -9 pid。==
查看nginx的pid: ps -ef | grep nginx
可以看到nginx的主进程编号 是 7901
正常关闭 nginx的主进程
kill -15 7901 或者 kill 7901 再次查看nginx的进程 发现已经关闭
启动nginx,查看进程号,再强制关闭 nginx
nginx
ps -ef | grep nginx
kill -9 9827
ps -ef | grep nginx
可以看到 kill -9 只是强制关闭了 nginx的主进程,由于不是正常关闭,worker进程并没有被关闭,这就是强制关闭的弊端,再次关闭worker进程 kill -9 9828
1、kill 命令默认使用的信息编号及信息是什么?
:15,代表正常关闭进程
2、kill -9 pid 中 信息编号9代表什么信息?
:强制关闭进程
3、如何查看kill的信息编号?
:kill -l
4、写出正常关闭 进程编号 为 233 的命令
:kill -15 pid or kill pid
5、写出强制关闭 进程编号 为 233 的命令
:kill -9 pid
1、信号:传递给 Liunx 的事件发生通知机制。
2、kill -l:显示所有信号。一共有62个信号(没有32、33)。
3、常用的信号有:
kill -2 PID —— 正常中断进程(Ctrl + C 一样)。程序在结束之前,能够保存相关数据,然后再退出。
kill -9 PID —— 强制杀死一个进程。
kill -15 PID —— 正常方式终止一个程序。中断进程时应首先用 -15,以便于其能够预先清理临时文件和释放资源。-9 作为最后手段,应对那些失控的进程。
--------------------------------------------------------------------------------
1)、kill -2 中断后台运行的进程。
红色下划线:sleep 10000 &—— 后台运行延时 10000 秒的命令,进程 ID 为1516。
ps -j —— 以作业格式列出进程信息,可以看到 1516 sleep 命令的进程。
(PID:进程 ID、PGID:线程组 ID、SID:会话 ID、TTY:进程运行的终端,标识那个终端控制。(pts远程终端、tty系统终端)、TIME:进程运行的时间 和 CMD:命令的名称和参数)。
jobs -l —— 列出后台运行的命令,可以看到 1516 sleep 命令正在后台运行。
黄色下划线:kill -2 1516 —— 中断1516 进程。执行成功后,按 Enter 回车系统会给出提示Interrupt 提示(中断进程)。
蓝色方框:ps -j 已查询不到 1516 sleep 的进程。jobs -l 也没有后台运行的命令。
2)、kill -2 配合 fg 查看中断挂起的进程。
红色下划线:前台执行 sleep 10000 (延时10000秒)后 ctrl + z 挂起。
黄色下划线:ps -j 查看进程,可以看到 1344 sleep 进程。jobs -l 查看后台进程 1344 的状态是stopped 暂停状态。
蓝色下划线:kill -2 1344 中断 1344 进程。
绿色下划线:ps -j 查看进程,仍有 1344 sleep 进程。jobs -l 查看后台进程 1344 的状态是stopped 暂停状态。
暂时这样看,好像 kill -2 并没有起到中断进程的作用。
然而,用 fg 把后台的命令调至前台运行时可以发现 1344 sleep 已经被中断。
红色下划线:fg 把已经执行了 kill -2, 状态为 stopped 的1344 sleep命令调至前台执行。系统也反馈已经调至前台执行。(此时,实际上已经执行了 kill -2 中断了进程)
黄色方框:ps -j 已经没有了 1344 sleep 的进程。
蓝色方框:jobs -l 后台也没有指令。
3)、kill -2 配合 bg 查看中断挂起的进程。
通过上面的思路,kill -2 配合 bg 实验看看效果。同样的首先挂起一个命令,状态为 stopped 暂停。然后用 bg 命令恢复执行。
前面的步骤都是一样,挂起一个命令。通过 ps 和 jobs 查看进程和后台确认有 1379 的进程,状态为 stopped 暂停。然后执行 kill-2 中断进程,再次通过ps 和 jobs 查看进程和后台命令。确认状态为 stopped 1379 的进程仍然存在。
此时,用 bg 恢复运行挂起的命令,系统提示 sleep 命令已恢复在后台运行。然而通过 ps -j 查看进程会发现 sleep 已经被中断。jobs -l 查看后台也没有了运行的 sleep 命令了。
从实验上看:
1、后台命令运行时(Running),执行 kill -2 可以中断进程。
2、挂起命令,处于暂停状态时(Stopped),执行 kill -2 后通过 ps 还可以查询到进程, jobs还可以查询到后台命令,状态仍然是 Stopped 暂停状态。实际上,用 fg 把暂停的后台进程调至前台运行时,系统反馈 sleep 命令调至前台运行。而再用 ps 查询不到进程,已经中断了进程。用 jobs 已经查询不到后台命令。
3、挂起命令,处于暂停状态时(Stopped),执行 kill -2 后通过 ps 还可以查询到进程, jobs还可以查询到后台命令,状态仍然是 Stopped 暂停状态。用 bg 把暂停的后台命令恢复运行时,系统反馈 sleep 命令在后台运行。再用 ps 查询进程已经中断,用 jobs 已经查询不到后台命令。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)