资讯专栏INFORMATION COLUMN

Linux:system 调用引发的 getcwd 异常

TesterHome / 1370人阅读

摘要:背景幸福的生活总是相似的,天降的大锅各有各不同。那现在其实一目了然了,调用了触发初始化了,在初始化变量时候调用了,因为获取父目录失败了,所以输出了那段错误。

背景

幸福的生活总是相似的,天降的大锅各有各不同。

我们有个功能是这样的:有个以 root 运行的 python 程序,它需要以 test 用户执行 linux 命令,所以就通过 subprocess 库 + sudo 来执行,也就是下面的关系图:

./test_b 就是这么一个很简单的需求,本来是没有什么太大的问题的,然而事实总是喜欢打我们脸。

就输出下面的错误了:

虽然上面的错误不会影响程序的运行,但是处女座没法忍,一定要干干净净,明明白白!

错误定位

凭借过硬的英语水平,我们明白这个报错是因为访问不到父目录导致 getcwd 出错了。

聪明的童鞋一想就觉得是不是和上面的删除目录有关系,这时候肯定得看看 test_b 是什么内容,说不定能解决我们的疑问:

#!/usr/bin/python
import time
import os

time.sleep(3)
os.system("sleep 1")

那么问题来了,test_b 明明就只想睡个觉,不想涉足江湖事,也没有调用getcwd,为什么会输出这个报错咧!

在我们毫无头绪时,可以去喝喝快乐肥宅水,说不定就能脉动回来。

因为我就是这样看到找到线索了:shell-init

凭借过硬的英语水平,我们可以看到这个错误应该在 shell 初始化时候报的,这样很明显啦,去搜 bash 代码。

很快我们就找到这句错误定义的地方了:

root@bash-4.4 $ grep  "shell-init" -r *
variables.c:      temp_string = get_working_directory ("shell-init");

看到 get_working_directory 这个函数名这么正规,感觉这事靠谱了,顺着看看内容:

// builtins/common.c
char *
get_working_directory (for_whom)
     char *for_whom;
{
    ... (跳过)
    if (the_current_working_directory == 0)
    {
      fprintf (stderr, _("%s: error retrieving current directory: %s: %s
"),
           (for_whom && *for_whom) ? for_whom : get_name_for_error (),
           _(bash_getcwd_errstr), strerror (errno));
      return (char *)NULL;
    }
    ... (跳过)
}

虽然大部分是通过变量传值进去,但是还是能看出就是咱们那句报错的原型了,

其实上面的代码实现并不是最关键的,关键的是,这些代码文件是在 bash 里面的,为什么system 会和bash 扯上关系呢?难道 system 还需要撸一发 shell 么,崩溃!我心目中的 system 不是这么随便的!

System 源码

带着不甘心去搜它的实现:

int system(const char * cmdstring)
{
    pid_t pid;
    int status;
    
    if(cmdstring == NULL){ 
         return (1);
    }
    
    if((pid = fork())<0){
         status = -1;
    }
    else if(pid = 0){

        execl("/bin/sh", "sh", "-c", cmdstring, (char *)0);

        exit(127); //子进程正常执行则不会执行此语句

    }
    else{
        while(waitpid(pid, &status, 0) < 0){
            if(errno != EINTER){
                status = -1;
                break;
            }
        }
    }
    return status;
}

它的出厂设置就是这样,原来是我一直没去深入了解它。

那现在其实一目了然了,system调用了 /bin/sh, 触发shell 初始化了, 在初始化变量时候调用了
get_working_directory,因为获取父目录失败了,所以输出了那段错误。

既然我们知道错误是 system 输出的,那么我们换个方式就应该能规避咯?

于是乎,./test_b 代码改成这样就不报错了:

#!/usr/bin/python
import time
import os

time.sleep(3)
# os.system("sleep")
os.execl("/bin/sleep", "sleep", "1")

那么这里又引出了一个问题了

system 和 execl 都能执行系统命令,那两者有什么区别呢?

答案在上面的 system 的源码已经给出 80% 了,他们的区别就是:

system = fork + execl + waitpid

execl 只是系统 exec 族函数的其中一个,说到 exec 族函数,它们是将新的程序内容替换当前进程内容运行,具体大家可以去谷歌看看,这边就不多说了~

我们对 system 的实现已经有一定熟悉了,在后面使用这个方法时候,不管是在资源使用还是问题排查,都应该多一些意识,眼不见不代表没关系~

欢迎各位大神指点交流, QQ讨论群: 258498217
转载请注明来源: https://segmentfault.com/a/11...

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/42856.html

相关文章

  • python中sys,os,time模块使用(包括时间格式各种转换)

    摘要:模块实现从程序外部向程序传递参数。位置参数代表文件本身,运行方法参数,参数。。是正常退出,其他为异常第次第五次退出模块判断现在正在实用的平台,返回返回得到当前工作的目录。指定所有目录下所有的文件和目录名。例检验指定的对象是否存在。 sys模块 sys.argv: 实现从程序外部向程序传递参数。 位置参数argv[0]代表py文件本身,运行方法 python xx.py 参数1,参数2 ...

    mochixuan 评论0 收藏0
  • Android实际开发bug大总结

    摘要:换句话说,环境或应用程序没有处于请求操作的适当状态。项目中异常分析引发崩溃日志的流程分析解决办法常见的出现场景状态异常非法线程操作。导致的方法出来显示消息位于该消息之后,迟迟没有执行。这时候,的超时检测结束,删除了服务中的记录。 目录介绍 1.1 java.lang.UnsatisfiedLinkError找不到so库异常 1.2 java.lang.IllegalStateExce...

    peixn 评论0 收藏0
  • 崩溃bug日志总结2

    摘要:出现错误引发崩溃日志的流程分析这个错误是应用的方法总数限制造成的。 目录介绍 1.1 java.lang.ClassNotFoundException类找不到异常 1.2 java.util.concurrent.TimeoutException连接超时崩溃 1.3 java.lang.NumberFormatException格式转化错误 1.4 java.lang.Illegal...

    sutaking 评论0 收藏0

发表评论

0条评论

TesterHome

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<