首页
学习
活动
专区
圈层
工具
发布

【Linux】万字解读<进程控制>:创建&中止&等待&替换

本章主要内容面向接触过Linux的老铁 主要内容含: 一.进程创建 1.fork函数 【1】fork函数与其返回值 它从已存在进程中创建一个新进程。新进程为子进程,而原进程为父进程。...例如:父进程等待客户端请求,生成子进程来处理请求。 一个进程要执行一个不同的程序。...)对子进程进行 资源回收 的等待过程 2.进程等待的必要性 子进程退出,父进程如果不管不顾,就可能造成 ‘僵尸进程’的问题,进而造成内存泄漏——进程一旦变成僵尸状态,那就刀枪不入,“杀人不眨眼”的 kill...父进程通过 进程等待 的方式,回收子进程资源,获取子进程退出信息 有时候进程也会 等待硬件资源 ,利用wait进程等待把自己挂起 3.如何进行等待(wait&waitpid) 【1】wait函数参数与返回值介绍...1.进程替换概念 【1】进程替换概念 我们所创建的所有的子进程,执行的代码,都是父进程代码的一部分 如果我们想让子进程 执行新的程序呢???

56810

Tomcat进程意外退出,元凶居然是他...

作者 | 宏江 出品 | 并发编程网(ifeve.com) 节前某个部门的测试环境反馈tomcat会意外退出,我们到实际环境排查后发现不是jvm crash,日志里有进程销毁的记录,从pause到destory...那就只剩下Signal的情况了;经过一番排查后,发现每次tomcat意外退出的时间与ssh会话结束的时间正好吻合。...还是比较好理解的,举例来说,我们先某个前台进程运行时间太长,可以ctrl-z中止一下,然后通过bg %n把这个进程放入后台,同样也可以把一个cmd &方式启动的后台进程,通过fg %n放回前台,然后在ctrl-c...因为默认如果采用父进程的进程组ID,父进程会把收到的键盘事件比如ctrl-c之类的SIGINT传播给进程组中的每个成员,假设后台进程也是父进程组的成员,因为作业控制的需要不能忽略SIGINT,你在终端随意...因为java后台进程从父进程catalina.sh(又是从其父进程test.sh)继承的pgid,所以java进程仍属于test.sh进程组里的成员,收到SIGHUP后退出。

4.7K10
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Tomcat 进程意外突崩,元凶居然是它...

    点击上方“码农沉思录”,选择“设为星标” 优质文章,及时送达 节前某个部门的测试环境反馈tomcat会意外退出,我们到实际环境排查后发现不是jvm crash,日志里有进程销毁的记录,从pause到destory...那就只剩下Signal的情况了;经过一番排查后,发现每次tomcat意外退出的时间与ssh会话结束的时间正好吻合。...还是比较好理解的,举例来说,我们先某个前台进程运行时间太长,可以ctrl-z中止一下,然后通过bg %n把这个进程放入后台,同样也可以把一个cmd &方式启动的后台进程,通过fg %n放回前台,然后在ctrl-c...因为默认如果采用父进程的进程组ID,父进程会把收到的键盘事件比如ctrl-c之类的SIGINT传播给进程组中的每个成员,假设后台进程也是父进程组的成员,因为作业控制的需要不能忽略SIGINT,你在终端随意...因为java后台进程从父进程catalina.sh(又是从其父进程test.sh)继承的pgid,所以java进程仍属于test.sh进程组里的成员,收到SIGHUP后退出。

    1.5K10

    服务器意外断电MySQL无法启动

    再三询问之下,客户说出一个情况:服务器因信息中心人为原因,最近总是意外断电。更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』 what?服务器这么儿戏吗?这么不安全吗?...2.检查服务运行状态,发现 MySQL 容器一直处于尝试重启状态。3.检查 docker 日志,筛选 MySQL 容器报错部分。4.提示:数据库由于非正常情况关闭,正在尝试恢复,重新启动。...更多精彩文章请关注『全栈技术精选』6.在 MySQL 的配置文件中有一项配置项 【innodb_force_recovery】代表强制恢复,它的值从1-6效果不断加强。...更多精彩文章请关注公众号『Pythonnote』 3.解决 1.在配置文件/etc/mysql/my.cnf中添加如下语句 [mysqld] innodb_force_recovery = 4 innodb_force_recovery...1.重新启动 mysql 之后表都是只读状态,此时可以备份数据库2.将备份文件导入到新的数据库中更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』 4.后记 生产环境所有操作必须三思而后行

    9.6K20

    mysql 信号量与进程状态

    导读前段时间遇到某数据库进程状态为: T (disk sleeping) , 即在处于一个不可中断的IO等待中, 此时数据库无法连接(包括socket), 估计是cgroup达到限制了, 干掉同组的其它进程后...,资源释放, 状态变成了T (stopped),这个状态和ctrl+z类似, 于是发送"SIGCONT"信号量之后变成了Sleep.这就让人好奇mysql支持哪些信号量,进程状态又能在哪些状态之间变化?...能力有限, 简单分析分析信号量我们查询官网(https://dev.mysql.com/doc/refman/8.0/en/unix-signal-response.html)发现如下:SIGTERM...IO操作,我知道的主进程的IO操作就只有shutdown......就是FLUSH全部,SIGUSR1就是FLUSH日志.mysql进程通常处于Sleep/Running状态,如果出现了较长的D则表示IO等可能有问题.

    33520

    数据恢复:如何恢复Linux中意外删除的Oracle和MySQL数据库

    昨晚有朋友在微信群中求助讨论,误删除了一个MySQL的数据库,整个恢复过程和以下文章中提到的步骤完全相同,只要MySQL主进程还没有退出,从文件句柄中可以恢复文件最终挽回损失。...让我们完整的再复习一下这篇文章的步骤,一定要记住这种方法: 今天有客户的数据库意外被删除了整个目录中的数据文件,操作系统级别的删除,然而幸运的是这个数据库没有崩溃,仍然处于 open 状态的时候,客户就发现了问题...检查 dbwr 的进程 PID 4. dbwr 会打开所有数据文件的句柄。在 proc 目录中可以查到,目录名是进程 PID,fd 表示文件描述符。...恢复的原理是,在 Linux 操作系统中,如果文件从操作系统级别被rm掉,之前打开该文件的进程仍然持有相应的文件句柄,所指向的文件仍然可以读写,并且该文件的文件描述符可以从 /proc 目录中获得。

    5.5K60

    MySQL进程CPU飙升到900%,怎么处理?

    首先,说明一下问题:CPU飙升200% 以上是生产容易发生的场景 场景:1:MySQL进程飙升900% 大家在使用MySQL过程,想必都有遇到过CPU突然过高,或者达到200%以上的情况。...陈某提示:大家介绍场景的时候,就说自己主要涉及了两个场景, Java进程飙升900%、MySQL进程飙升900%两种场景,其实,这两个场景就足够讲半天了, 其他的,使用规避技巧规避一下就行。...场景一:MySQL进程CPU飙升到900%,怎么处理? 定位过程: 使用top 命令观察,确定是mysqld导致还是其他原因。...经过询问,发现很多查询都是走MySQL,没有用到缓存。 既然没有用到缓存,则是大量请求全部查询MySQL导致。...再则一定要使用缓存系统,降低对MySQL的查询频次。 对于内存调优,也是一种解决方案。 场景2展开:Java进程CPU飙升到900%,怎么处理?

    65810

    Centos运行Mysql因为内存不足进程被杀

    Kill   process (Mysqld)  我英语未过四级,但是这个简单英文还是能看懂的,大致意思时内存不够了,然后把mysql的进程给杀掉了,阿西吧!!! 尴尬了,怎么办? ...小伙伴们不能让我太尴尬啊,所以给我提了建议,说可以通过修改mysql的配置文件my.ini实现降低mysql的运行所占用内容。...半个多月 MySQL 使用是很具伸缩性的算法,因此你通常能用很少的内存运行或给MySQL更多的被存以得到更好的性能。 ...安装好mysql 后,配制文件应该在/usr/local/mysql/share/mysql 目录中,配 制文件有几个,有my-huge.cnf、my-medium.cnf、my-large.cnf、my-small.cnf...   port = 3306   socket = /tmp/mysql.sock   #socket = /var/lib/mysql/mysql.sock   # Here follows

    3.7K50

    mysql服务器重启, 却有2个mysqld进程 ?

    忘记这是案例几了...问题现象昨晚变更完后, 关闭mysql数据库, 然后重启OS(kylin可能有swap问题, 遇到2次了.得手动到后台强制重启OS)后, 检查发现mysqld进程有2个.说明: 本文所有截图均为测试环境截图...所以可以确定确实有2个mysqld在启动.因为是在/etc/rc.local中配置的开机自启, 所以999进程的mysqld_safe和3199进程的mysqld才是我们设计内的自启进程....那么PID:1085的进程是水启动的呢?...由于进程是mysql启动的, 所以我们只需要看root和mysql的定时任务就行,遗憾的是并没有相关的定时任务, 也没有配置服务管理, /etc/crontab也是空的....我们查看该脚本, 确实发现了启动mysql的命令(我这测试环境的比较简单, 能一眼看出来, 实际环境可能存在多层调用的情况, 最离谱的是父进程都变成1了...)问题基本上就是找到了.

    1.1K20
    领券