<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[tusong86的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/tusong86</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; tusong86]]></copyright><item><title><![CDATA[gcc链接静态库的时候的最小单位是文件，没有精确到函数]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/148502878</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/148502878</guid><author>tusong86</author><pubDate>Sun, 08 Jun 2025 00:50:23 +0800</pubDate><description><![CDATA[这是因为链接是以文件为单位的，mul函数的实现在mul.c里面，mul.c里面有两个函数：mul和add2，其中add2里面调用了add。可以看到main.c里面用到的mul函数位于libmul.a库里面，位于这里面的mul.o文件的mul函数，而mul函数并没有依赖其他函数(没有依赖add.o，即没有依赖libadd.a)。并不是整个静态库里面的全部的.o文件里面的函数。可以看到main2.c里面用到的mul2函数位于libmul.a库里面，位于这里面的mul2.o文件的mul2函数.]]></description><category></category></item><item><title><![CDATA[linux下命令行参数都是以空格为分隔的吗]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/148059064</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/148059064</guid><author>tusong86</author><pubDate>Mon, 19 May 2025 11:17:02 +0800</pubDate><description><![CDATA[命令行参数是5个，其中第一个参数是mycommand，即命令本身，后面发现不是这样。123 234 456 789这4个合在一起可能是一个参数，主要看调用方怎么写。比如mycommand 123 234 456 789。首先准备一个程序argtest，用于打印命令行参数。一直以来，我以为命令行参数以空格为分隔。]]></description><category></category></item><item><title><![CDATA[linux中如何获取其他进程的退出状态]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/146527866</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/146527866</guid><author>tusong86</author><pubDate>Wed, 26 Mar 2025 13:58:20 +0800</pubDate><description><![CDATA[进程的退出状态至关重要，用wait系列函数，父进程可以捕捉到子进程的退出状态，若给定任意进程，其父进程已经确定，无法改变，自己如何获取到其退出状态呢。]]></description><category></category></item><item><title><![CDATA[linux 进程pid产生的值是多少]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/146294645</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/146294645</guid><author>tusong86</author><pubDate>Sun, 16 Mar 2025 13:59:20 +0800</pubDate><description><![CDATA[当前系统的进程最大值被保存在/proc/sys/kernel/ns_last_pid。linux进程pid是往上增加的，直到遇到系统设置的最大值，然后接着从头开始产生。可以看到新产生的进程id是4054。]]></description><category></category></item><item><title><![CDATA[关于chmod u+s文件所在目录的问题]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/145911970</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/145911970</guid><author>tusong86</author><pubDate>Thu, 27 Feb 2025 19:42:43 +0800</pubDate><description><![CDATA[查看passwd进程的有效用户id和实际用户id，发现有效用户id是root，表明其进程执行时，具有root权限，这样它才有权限修改密码文件/etc/shadow(该文件属于root)。后面自己随意写了一个命令，比如叫setuidtest，所属用户也是root，也给u+s权限。到底放到哪些目录下才有root权限，哪位大神，请不吝赐教，告知下里面的门道。]]></description><category></category></item><item><title><![CDATA[glibc中xdr的一个bug]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/143253808</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/143253808</guid><author>tusong86</author><pubDate>Sat, 26 Oct 2024 15:11:10 +0800</pubDate><description><![CDATA[本人是64位的gcc编译器，long类型是8个字节，所能表示的数字范围远远大于4294967295。本人在64位linux服务器上(centos7)，发现xdr_u_long这个函数有个bug，就是数字的范围如果超过unsigned int的最大值(4294967295)时，xdr_u_long失败。经过测试，xdr_u_long所能编码的最大值为4294967295，此时间戳对应的时间大概是2106年。而uint64_t和u_long的类型是一致的，都是unsigned long int。]]></description><category></category></item><item><title><![CDATA[c++中引用是通过指针的方式实现]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/142312342</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/142312342</guid><author>tusong86</author><pubDate>Tue, 17 Sep 2024 11:48:21 +0800</pubDate><description><![CDATA[可以看到，红色方框圈里来的有两部分，其中第一部分是栈帧大小的圈定，bp是栈底，sp是栈顶，由于栈是自顶向下生长，所以sp其实比bp小。红色部分的3部分，第一部分是栈帧大小的开辟，第二部分是栈帧数据的初始化，第三部分是首先将x的值赋给eax，然后将0Ah，即数字10，赋给eax所指的内存单元，即x所指的内存单元。第一步，lea eax,[a]是指将a的地址赋给eax，第二部push eax，这步是参数压栈，而eax目前的值是a的地址，故压栈的参数就是a的地址。然后按F11，进入到fuzhi函数的汇编代码处。]]></description><category></category></item><item><title><![CDATA[关于setrlimit RLIMIT_STACK的一点说明]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/142304800</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/142304800</guid><author>tusong86</author><pubDate>Mon, 16 Sep 2024 17:40:25 +0800</pubDate><description><![CDATA[main函数栈帧的限制在编译的时候就确定了，是8M。故main函数中设置的栈大小为1M，在后面的函数print中生效。而print函数中定义了2M大小的栈变量szBuf，在main函数真正调用print时，会先进行栈限制检查。下面代码，设置栈大小为1024字节，然后后面又定义了2 * 1024的数组，并在print也定义了2 * 1024的数组，但是程序并没有崩溃。可以看到进程崩溃了，但是可以看其打印，print打印出来的，这说明崩溃的时候，是在进入print崩溃的。不是在main函数里面崩溃的。]]></description><category></category></item><item><title><![CDATA[fork出的子进程，调用exec函数后，其信号处理函数会被继承吗]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/141226963</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/141226963</guid><author>tusong86</author><pubDate>Thu, 15 Aug 2024 17:12:13 +0800</pubDate><description><![CDATA[首先需要说明的是，exec后，子进程和父进程属于不同的代码段。信号处理函数不会被继承，但是某些针对信号的设置，还是可以传递的，比如exec前，设置信号处理为SIG_IGN，则exec后，该信号依然保持SIG_IGN属性。该程序名叫做forktest3，终端上运行./forktest3 &；放入后台运行，可以看到后台有两个进程：forktest3和sleep 1000。设置后，尽管后面调用了exec，但是该信号设置依然有效。然后关闭掉终端，可以发现forktest3消失了，但是sleep 1000还在。]]></description><category></category></item><item><title><![CDATA[linux 父进程退出时，激活了子进程的情况说明]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/141199302</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/141199302</guid><author>tusong86</author><pubDate>Wed, 14 Aug 2024 20:28:21 +0800</pubDate><description><![CDATA[针对第二种情况，为何子进程会退出，这里做简单说明，杀掉父进程后，子进程会接收到SIGHUP信号，而此信号，子进程没有处理，则默认结束子进程；此时暂停子进程，然后杀掉父进程，则子进程被激活，并且不会退出。今天在此记录一下几种情况。]]></description><category></category></item><item><title><![CDATA[文件描述符中设置FD_CLOEXEC的用处]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/141033959</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/141033959</guid><author>tusong86</author><pubDate>Thu, 08 Aug 2024 18:49:47 +0800</pubDate><description><![CDATA[linux中，父进程fork出子进程，子进程本身会继承父进程的所有文件描述符。若子进程再调用exec系列函数转化为新的进程实体，其实父进程的描述符对其没有意义。此时文件上只需要设置FD_CLOEXEC即可。注意，如果fork进程后，没有调用exec，则无论FD_CLOEXEC是否设置，子进程一定会继承父进程的全部文件描述符。再运行看看情况，如下所示，产生的两个进程号分别是64187，64188，可以看到文件描述符被子进程继承了。然后查看进程的fd信息，可以看到my.txt这个文件描述符没有继承下去。]]></description><category></category></item><item><title><![CDATA[linux父进程fork出子进程后，子进程为何首先需要close文件描述符。]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/139098385</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/139098385</guid><author>tusong86</author><pubDate>Tue, 21 May 2024 17:46:54 +0800</pubDate><description><![CDATA[考虑到一种情况，父进程创建了tcp服务端套接字，并且listen，此时fork出子进程，若子进程里面不close此监听套接字，则子进程里面是否能接收到客户端的连接。答案是可以的，现在构造一个服务端程序，listen后，fork出子进程，然后父进程进入sleep，子进程调用accept，在accept成功后，打印对应的信息。在linux c/c++编程时，父进程fork出子进程后，子进程经常第一件事就是close掉所有的文件描述符；所以后续父进程fork出子进程后，子进程需要关闭对应的文件描述符。]]></description><category></category></item><item><title><![CDATA[关于命令行中 ＜ 的代码说明]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/139097496</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/139097496</guid><author>tusong86</author><pubDate>Tue, 21 May 2024 17:14:28 +0800</pubDate><description><![CDATA[标准输入]]></description><category></category></item><item><title><![CDATA[当全连接队列满了，tcp客户端收到服务端RST信令的模拟]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/137836899</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/137836899</guid><author>tusong86</author><pubDate>Tue, 16 Apr 2024 19:33:54 +0800</pubDate><description><![CDATA[当tcp服务端全连接队列满了后，并且服务端也不accept取出连接，客户端再次连接时，服务端能够看到SYN_RECV状态。但是客户端看到的是ESTABLISHED状态，所以客户端自认为成功建立了连接，故其写往服务端写数据，发现数据也确实写成功了。但是后面等到服务端通过ACK+SYN告知客户端重新ACK时，发现此时客户端的业务数据已经到来了，故而认为出了问题，故重置连接。其中104代表连接被对端重置。]]></description><category></category></item><item><title><![CDATA[tcp的全连接队列和半连接队列满时，客户端再connect发生的情况]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/137564879</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/137564879</guid><author>tusong86</author><pubDate>Tue, 09 Apr 2024 20:31:20 +0800</pubDate><description><![CDATA[为何ESTABLISHED的数量是3，不是2，即刚好比全连接队列的长度大1，这里本人给出自己的看法，即在最后一个连接(即第3个)建立后，再往accept队列塞的时候，发现队列已经满了，所以就不塞了，但是连接已经建立好了。所以数目是队列的长度+1。为模拟这种情况，可以先将服务端的accept函数注释掉，这样accept queue中的连接无法被消费，从而很快就满了，而且为了快速达到效果，本人在sysctl.conf中，设置net.core.somaxconn=2，即全连接队列的长度为2.]]></description><category></category></item><item><title><![CDATA[linux printf往文件里面写入内容]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/134537070</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/134537070</guid><author>tusong86</author><pubDate>Tue, 21 Nov 2023 17:37:16 +0800</pubDate><description><![CDATA[代码里面，先将fd=1关闭掉，然后open一个文件，出来的文件描述符fd1的值就是1，然后printf向fd为1的文件里面写入东西，执行时，最终可以看到log.txt里面的字符串。为何fsync不行，fflush可以，难道是因为printf和fflush都是stdio.h里面的吗，有大神知道原因的，请不吝赐教。此时相当于疯狂往log.txt里面写入，很快发现log.txt文件很大。最后将fsync(fd1);此种请看下，程序一直在运行，每隔1秒写入一行内容，但是可以发现log.txt中看不到任何内容。]]></description><category></category></item><item><title><![CDATA[AF_UNIX和127.0.0.1(AF_INET)回环地址写数据速度对比(二)]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/133702088</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/133702088</guid><author>tusong86</author><pubDate>Mon, 09 Oct 2023 16:13:36 +0800</pubDate><description><![CDATA[由于测试时发送的是1.15G大小的文件，比较快就发送结束了，而且读文件，写文件是个比较费时的操作，本人考虑到读写文件费时的影响，决定发送端自己构造字符串，接收方只统计接收到的字符个数，并不写文件。然后发送端发送100秒，对比下100秒之内，AF_UNIX和回还地址接收到的字节个数。然后利用的是发送端读取大文件，接收方接收并保存为文件的方式进行测试，结果发现，AF_UNIX并未比127.0.0.1(AF_INET)回环地址优秀，若单次发送的字节数少时，回环地址反而更快。]]></description><category></category></item><item><title><![CDATA[AF_UNIX和127.0.0.1(AF_INET)回环地址写数据速度对比]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/133688361</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/133688361</guid><author>tusong86</author><pubDate>Sun, 08 Oct 2023 19:42:27 +0800</pubDate><description><![CDATA[本人想当然认为AF_UNIX速度比127.0.0.1更快，为此鄙人进行了实验。2. 用127.0.0.1写客户端和服务端，由客户端读取文件，发送给127.0.0.1服务端，然后服务端写文件，看看用127.0.0.1传递一个文件需要多久。用AF_UNIX写客户端和服务端，由客户端读取文件，发送给AF_UNIX服务端，然后服务端写文件，看看用AF_UNIX传递一个文件需要多久。今天发现linux服务端创建socket的时候，协议族用AF_UNIX即可，AF_LOCAL和AF_UNIX的值是一样的。]]></description><category></category></item><item><title><![CDATA[criu简单例子]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/133648063</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/133648063</guid><author>tusong86</author><pubDate>Sat, 07 Oct 2023 18:12:58 +0800</pubDate><description><![CDATA[linux dump功能]]></description><category></category></item><item><title><![CDATA[cgroup限制cpu使用率]]></title><link>https://blog.youkuaiyun.com/tusong86/article/details/133420090</link><guid>https://blog.youkuaiyun.com/tusong86/article/details/133420090</guid><author>tusong86</author><pubDate>Fri, 29 Sep 2023 20:54:31 +0800</pubDate><description><![CDATA[现在想限制该cpu使用率为20%，可以通过cgroup来限制，进入/sys/fs/cgroup/cpu，通过mkdir创建cputest目录，然后进入到该目录，这里面有两个文件需要说下：cpu.cfs_period_us和cpu.cfs_quota_us，cpu.cfs_quota_us表示一个调度周期内，可以使用的cpu时间，故cpu.cfs_quota_us/cpu.cfs_period_us就是cpu使用率。，发现cgroup限制内存需要在内存涨起来之前就进行限制，cpu限制是否也有这个约束呢。]]></description><category></category></item></channel></rss>