pid控制

进程与线程 1、进程的相关概念 (1)、进程与程序： 1、进程是动态的，程序是静态的； 2、进程有生命周期，程序没有生命周期； 3、一个进程只能对应一个程序，一个程序却可以对应多个进程，没有建立进程的程序不能作为一个独立的单位获得操作系统的认可； (2)、进程控制块(PCB) 每个进程在内核中都有一个进程控制块来维护进程的相关信息,linux内核的进程控制块是task-struct结构体。内部成员很多，主要有： a、进程ID：系统中每个进程都有唯一的id，用pid_t类型表示。 b、进程状态：有初始、就绪、运行、挂起、终止五个状态。 c、进程切换需要保存和恢复的CPU寄存器。 d、描述虚拟地址空间的信息。 e、描述控制终端的信息。 f、当前工作目录。 g、文件描述符表：包含很多指向file结构体的指针。 h、和信号相关的信息。 i、用户组id和组id。 j、会话（session）和进程组。 k、umask掩码。 l、进程可以使用的资源上限。 2、进程控制 (1)、fork函数 pid_t fork(void) 问题： a、fork函数的返回值？ 答：当fork函数创建子进程成功后，会返回两个，一个数为0：代表子进程的返回值；当返回值大于0时：父进程返回值，代表子进程的id。 b、子进程创建成功后，代码的执行位置？ 答：父进程执行到哪，子进程就从哪里开始执行。 c、父子进程的执行顺序

点击打开链接 点击打开链接 点击打开链接 ）早已经做过类似的工作了，并且总结出许多经验和错误，但鉴于在论坛中许多错误没有一个完整的回答，信息都是零零散散，于是我打算把我做的一整套流程记录下来，以免日后忘记，同时也希望可以帮助到一些人。 链接1 里面是我最早看到的资料，前辈1在MATLAB中文论坛中发布自己搭建的工程文件及其所遇到的问题，后面楼主说是解决了问题，但是没有上传（这个可以谅解），另外里面有许多热心网友的回答是非常有用的（这些回答对我自己后面解决相关问题，成功实现Simulink仿真是非常关键的，在这里非常感谢论坛中的各位前辈 ）。 链接2 这个确实是可以用的，只不过对MATLAB版本有限制。开始我下载之后用我的MATLAB2016b打开工程，点击run后就报错， The block 'BPPID/Subsystem/Unit Delay1' does not permit continuous sample time (0 or [0,0]) for the parameter 'SampleTime'. 里面分了两大派，一部分人说亲测有效，大赞跟帖；一部分人也像我一样运行报错，此时我疑惑了。于是猜测可能是MATLAB版本问题，于是在另一台电脑上的MATLAB2014b版本运行，果然得到楼主那一条漂亮的曲线（虽然我的工作就是点击一下run，但是还是很开心 ）

第八章 异常控制流ECF 8.1 异常 Exception graph LR E[异常Exception]-->E2[中断:异步异常] E-->E3[同步异常] E3-->陷阱 E3-->故障 E3-->中止 异常是异常控制流的一种形式，他一部分由硬件实现，一部分由操作系统实现。 在任何情况下，当处理器检测到有事情发生时，他就会通过一张叫做异常表（exception table）的跳转表，进行一个简介过程调用（异常），到一个专门用来处理这类事件操作系统子程序（异常处理程序 exception handler）。当异常处理程序完成以后，根据引起异常的事件的类型，会发生以下3种情况的一种： 处理程序将控制返回给当前指令I curr ，既当事情发生时正在执行的指令。 处理程序将控制返给I next ，如果没有发生异常将会执行的下一条指令。 处理器中止被中断的程序。 异常的类别： 类别 原因 异步/同步 返回行为 中断 来自I/O设备的信号 异步 总是返回到下一条指令 陷阱 有意的异常，例如系统调用（syscall） 同步 总是返回到下一条指令 故障 无意可恢复的错误，如页缺失 同步 有可能返回到当前指令 中止 无意不可恢复的错误 同步 不会返回 在故障异常处理中，例如页缺失。系统向内存请求一块内存页，当此页不再内存中时，会触发页缺失异常，此时调用处理页缺失异常的程序

1.操作系统真相还原 2.Linux内核完全剖析:基于0.12内核 3.x86汇编语言 从实模式到保护模式 4.Linux内核设计的艺术 ps:基于x86硬件的pc系统 此时系统已经加载了/etc/rc中的命令进行了执行，我们继续往下分析。 execve( "/bin/sh" ,argv_rc,envp_rc) ; // 系统调用执行命令 _ exit( 2 ) ; 当execve执行完成后，此时就会调用_exit(2)这个函数执行， volatile void _ exit (int exit _code) { __asm__( "int $0x80 " :: "a" (__NR_ exit ), "b" ( exit _code)); } 该函数直接调用了系统调用来处理，此时继续查找sys_exit函数， int sys_ exit (int error_code) { do _ exit ((error_code& 0 xff)<< 8 ); //调用 do _ exit 函数error_code左移八位 } 继续查看do_exit函数； volatile void do_exit(long code) // 程序退出函数 { struct task_struct *p; int i; free_page_tables(get_base(current->ldt[ 1 ])

不知道在大家面试中，有没有遇到这个问题： 生产服务器上部署了几个java程序，突然出现了CPU100%的异常告警，你如何定位出问题呢？ 这个问题分为两版回答！ 高调版 对不起，我是做研发的，这个问题在生产上是不可能遇见的！因为研发是不可能直接操作生产服务器，如果贵公司能出现这个问题，应该要反思一下自己的权限控制是否合理！ 面试官心里活动 ：装13是不是，赶紧走！ 低调版 这个问题我在生产上没碰到过，因为我们是没法直接操作生产环境的。只能说，在测试环境曾经遇见过。操作步骤如下，balabala… 面试官心里活动 ：权限控制的不错，应该是在大厂呆过。 下面开始我们的正文 正文 下面给出两种系统下的排查步骤，都是一模一样的，只是命令稍有区别！ 查消耗cpu最高的进程PID 根据PID查出消耗cpu最高的线程号 根据线程号查出对应的java线程，进行处理。 准备一行死循环代码： 怎么跑，应该不用我说了，直接教大家怎么查！ windows版 可能有人有疑问，我为什么要说windows版的！因为，我曾经给很多政府部门做过系统。我发现他们用的是windows server，不是linux系统。所有必要说一下！ 查消耗cpu最高的进程PID 手边没有windows server机器，我以win 10为例，截图给大家看一下，先调出PID显示项！ 然后发现进程PID如下图所示，为10856 接下来呢？

在之前的文章 一次CAN波形分析之旅 里，根据示波器采集的波形数据，详细地分析了CAN通信。今天来分析USB数据，还是同样的流程，但是这次使用 matplotlib 来协助分析。 USB基本波形 USB通过一对差分信号进行数据传输，这对差分信号叫D+和D-，用示波器抓取一段D+和D-的信号，保存成CSV格式，用 matplotlib 绘制该信号： 分了方便分析，我们将D+和D-分别绘制： 标记数据包(Packet)的组成： 进一步细化数据包(Packet)的内容 USB数据分析 起始帧数据包（FRAMEPACKET） 全速USB会每隔1毫秒发送一包起始帧数据包（FRAME PACKET），由PID，FRAME_NUMBER和CRC三部分： PID（Packet ID）为数据包标识符，为8位长度，低4位为标识符数值，高4位值为低4位数值按位取反。起始帧数据包对应的PID为1010 0101(最左侧为最高位，下同） 这里需要注意，USB数据流先传输最低字节的最低位，同时按照NRZI方式编码，即（值不变表示数据'1'，值发生改变表示数据'0'）。 令牌数据包（TOKEN PACKET） 令牌数据包由PID，ADDR，ENDP和CRC四个段组成。一共有三种令牌： IN OUT SETUP 令牌IN对应的PID为0110 1001 令牌OUT对应的PID为1110 0001

0x00 前言 动态调试是比静态分析更为高效地一种破解手段。因此在破解安卓应用之前，一般会先对应用进行动态调试，了解应用大致运行流程和各个类之间的逻辑关系。 反动态调试可以从以下两个个方向着手： 1.运行环境检测：检测应用的运行环境是否安全，是否可能存在被调试的风险 2.动态调试指令检测：检测应用的运行过程中是否受到动态调试指令的控制 本文完全参考自网友 爱吃菠菜 的反调试总结，由于我的资料是pdf文档，已经找不到出处，在此对网友 爱吃菠菜 说一声抱歉。 0x01 运行环境检测 1.调试端口检测 不同调试器默认使用不同的调试端口，且这些端口默认值往往不被修改。 2.调试器进程检测 不同调试器会在系统中创建不同进程对应用进行劫持以达到动态调试目的。 3.父进程名检测 针对so文件，破解者可以自己编写一个APK对so库进行调试。 （1）正常启动的apk程序：父进程是zygote （2）调试启动的apk程序：在AS中用LLDB调试发现父进程还是zygote （3）附加调试的apk程序：父进程是zygote （4）vs远程调试 用可执行文件加载so:父进程名为gdbserver 父进程名非zygote的，判定为调试状态。 4.自身进程名检测 原理同上条。正常的APK进程名一般为入口类的目录。形如：com.xxx.xxx.xxxx.xxxMainActivity。在开发时，该值是已知的

golang 服务平滑重启小结 背景 golang 程序平滑重启框架 supervisor 出现 defunct 原因 使用 master/worker 模式 背景 在业务快速增长中，前期只是验证模式是否可行，初期忽略程序发布重启带来的暂短停机影响。当模式实验成熟之后会逐渐放量，此时我们的发布停机带来的影响就会大很多。我们整个服务都是基于云，请求流量从 四层->七层->机器。 要想实现平滑重启大致有三种方案，一种是在流量调度的入口处理，一般的做法是 ApiGateway + CD ，发布的时候自动摘除机器，等待程序处理完现有请求再做发布处理，这样的好处就是程序不需要关心如何做平滑重启。 第二种就是程序自己完成平滑重启，保证在重启的时候 listen socket FD （文件描述符） 依然可以接受请求进来，只不过切换新老进程，但是这个方案需要程序自己去完成，有些技术栈可能实现起来不是很简单，有些语言无法控制到操作系统级别，实现起来会很麻烦。 第三种方案就是完全 docker ，所有的东西交给 k8s 统一管理，我们正在小规模接入中。 golang 程序平滑重启框架 与 java、net 等基于虚拟机的语言不同， golang 天然支持系统级别的调用，平滑重启处理起来很容易。从原理上讲，基于 linux fork 子进程的方式，启动新的代码，再切换 listen socket FD