2012年4月16日星期一

system()返回值 return value

http://hi.baidu.com/yyangjjun/blog/item/48ef853a235c0535b9998f0c.html
linux system返回No child processes

system_ret = system(cmd);
    switch (system_ret)
    {
    case 0:
        /* no errors */
        break;
    case -1:
        /* system error */
       printf("%s: system(%s): %s\n", __func__,  cmd, strerror(errno));
        return 1;
    default:
        /* command error */
        lld_trace("%s: system(%s): %u\n", __func__, cmd, WEXITSTATUS(system_ret));
        return 1;
    }
此时system如果返回值是:No child processes,是因为在程序中忽略了SIGCHLD信号导致,取消对此信号的忽略就OK了。
------------------------------------------------------------------------------------------------------------ 


alarm(90);
     
  //Frank@Test
  errno = 0; 
  signal(SIGCHLD,sigchild);
  ilRC = system(pclTmpBuf);
  if(errno!=0)
  {    
          dbg(DEBUG,"file<%s>line<%d>errno<%d>system fails",__FILE__,__LINE__,errno);
          dbg(DEBUG,"%s",strerror(errno));
  }    
  else 
  {    
          dbg(DEBUG,"file<%s>line<%d>errno<%d>system successes",__FILE__,__LINE__,errno);
  } 
  //Frank@Test


  alarm(0);

------------------------------------------------------------------------------------------------------------
相关函数
fork,execve,waitpid,popen
表头文件
#i nclude<stdlib.h>
定义函数
int system(const char * string);
函数说明
system()会调用fork()产生子进程,由子进程来调用/bin/sh-c string来执行参数string字符串所代表的命令,此命>令执行完后随即返回原调用的进程。在调用system()期间SIGCHLD 信号会被暂时搁置,SIGINT和SIGQUIT 信号则会被忽略。
返回值
=-1:出现错误   
=0:调用成功但是没有出现子进程   
>0:成功退出的子进程的id
如果system()在调用/bin/sh时失败则返回127,其他失败原因返回-1。若参数string为空指针(NULL),则返回非零值>。 如果system()调用成功则最后会返回执行shell命令后的返回值,但是此返回值也有可能为 system()调用/bin/sh失败所返回的127,因此最好能再检查errno 来确认执行成功。
附加说明
在编写具有SUID/SGID权限的程序时请勿使用system(),system()会继承环境变量,通过环境变量可能会造成系统安全的问题。

#include<stdlib.h>
main()
{
system(“ls -al /etc/passwd /etc/shadow”);
}
执行结果:
-rw-r--r-- 1 root root 705 Sep 3 13 :52 /etc/passwd
-r--------- 1 root root 572 Sep 2 15 :34 /etc/shado
例2:
char tmp[];
sprintf(tmp,"/bin/mount -t vfat %s /mnt/usb",dev);
system(tmp);
其中dev是/dev/sda1。
//system源码
#include 
#include 
#include 
#include
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接受的命令为NULL时直接返回,否则fork出一个子进程,因为fork在两个进程:父进程和子进程中都返回,这里要检查返回的pid,fork在子进程中返回0,在父进程中返回子进程的pid,父进程使用waitpid等待子进程结束,子进程则是调用execl来启动一个程序代替自己,execl("/bin/sh", "sh", "-c", cmdstring,(char*)0)是调用shell,这个shell的路径是/bin/sh,后面的字符串都是参数,然后子进程就变成了一个shell进程,这个shell的参数是cmdstring,就是system接受的参数。在windows中的shell是command,想必大家很熟悉shell接受命令之后做的事了。

如果上面的你没有看懂,那我再解释下fork的原理:当一个进程A调用fork时,系统内核创建一个新的进程B,并将A的内存映像复制到B的进程空间中,因为A和B是一样的,那么他们怎么知道自己是父进程还是子进程呢,看fork的返回值就知道,上面也说了fork在子进程中返回0,在父进程中返回子进程的pid。
execl是编译器的函数(在一定程度上隐藏具体系统实现),在linux中它会接着产生一个linux系统的调用execve, 原型见下:
    int execve(const char * file,const char **argv,const char **envp);

看到这里你就会明白为什么system()会接受父进程的环境变量,但是用system改变环境变量后,system一返回主函数还是没变,原因从system的实现可以看到,它是通过产生新进程实现的,从我的分析中可以看到父进程和子进程间没有进程通信,子进程自然改变不了父进程的环境变量。

------------------------------------------------------------------------------------------------------------
windows中的情况也类似,就是execl换了个又臭又长的名字,参数名也换的看了让人发晕的,我在MSDN中找到了原型,给大家看看:

HINSTANCE   ShellExecute(
               HWND   hwnd,
               LPCTSTR   lpVerb,
               LPCTSTR   lpFile,
               LPCTSTR   lpParameters,
               LPCTSTR   lpDirectory, 
               INT   nShowCmd 
   );   

      用法见下:

     ShellExecute(NULL,   "open",   "c:\\a.reg",   NULL,   NULL,   SW_SHOWNORMAL);   


    你也许会奇怪 ShellExecute中有个用来传递父进程环境变量的参数 lpDirectory,linux中的 execl却没有,这是因为execl是编译器的函数(在一定程度上隐藏具体系统实现),在linux中它会接着产生一个linux系统的调用 execve, 原型见下:
    int execve(const char * file,const char **argv,const char **envp);
   
    看到这里你就会明白为什么system()会接受父进程的环境变量,但是用system改变环境变量后,system一返回主函数还是没变。原因从system的实现可以看到,它是通过产生新进程实现的,从我的分析中可以看到父进程和子进程间没有进程通信,子进程自然改变不了父进程的环境变量。希望小菜们不要拿tc或使用tc库的其他编译器中的system的调用结果来反驳我,这不是一个概念,DOS早死翘翘了,玩linux吧。就说到这里了。






2012年4月12日星期四

真正认识 REALLOC 的工作方式<转载>

http://www.cnblogs.com/ren54/archive/2008/11/20/1337545.html

realloc 用过很多次了。无非就是将已经存在的一块内存扩大。
char* p = malloc(1024);
char* q = realloc(p,2048);
现在的问题是我们应该如何处理指针 p。 刚开始按照我最直观的理解,如果就是直接将 p = NULL;。 到最后只需要释放 q的空间就可以了。
因为最近在做个封装。结果在做单元测试的时候发现。有时候我在 free(q); 的时候会出错。这样我就郁闷了。
后来仔细一跟踪,发现 realloc 完以后 q 和 p 的指针地址是一样。不过有时候又不一样。
仔细查了下资料。得到如下信息:
       1.如果 当前连续内存块足够 realloc 的话,只是将p所指向的空间扩大,并返回p的指针地址。 这个时候 q 和 p 指向的地址是一样的。
       2.如果 当前连续内存块不够长度,再找一个足够长的地方,分配一块新的内存,q,并将 p指向的内容 copy到 q,返回 q。并将p所指向的内存空间删除。
这样也就是说 realloc 有时候会产生一个新的内存地址 有的时候不会。所以在分配完成后。我们需要判断下 p 是否等于 q。并做相应的处理。
这里有点要注意的是要避免 p = realloc(p,2048); 这种写法。有可能会造成 realloc 分配失败后,p原先所指向的内存地址丢失。

2012年4月3日星期二

Linux inode耗尽导致No space left on device错误


周五客户说有台机器服务一直起不了,叫马上过去帮忙看一下。
到现场查看了一下,发现Oracle linstener无法启动,说linux: No space on device。另一个web服务也无法启动,log也说在尝试创建lock文件的时候No space on device。使用df -h命令查看文件空间,发现都有空间剩余,没满。
网上查了一下,说可能是文件系统的inode满了,使用df -i 查看inode的使用情况。果然,/var目录下inode已经耗尽。使用du –ah  /var > /tmp/1.txt 发现/var/spool/clientmqueue目录下的文件有100多万个,怪不得inode被耗尽。使用命令 find  /var/spool/clientmqueue -type f | xargs rm -f  删除 /var/spool/clientmqueue目录下的文件后,Oracle linstener和web服务成功启动,问题解决。

 关于inode:

Linux/Unix like OS 的文件系统中每个目录树中的节点并不是像 Windows 那样直接包含文件的具体信息,而只包含了文件名和 Inode number 。通过 Inode number 所找到对应于文件名的 Inode 节点中才真正记录了文件的大小/物理地址/所有者 /访问权限/时间戳/被硬链接的次数等实际的 metadata 。因此你可以在 Linux 系统中通过硬链接( hard link ) 的方式给某个文件创建无数个位于不同目录下的文件名,而实际的文件数据只需要一份拷贝。
但也正因为这种文件系统的结构,当你在 Linux 中进行 IO 操作的时候,需要的资源除了磁盘空间以外,还要有剩余的 Inode 才行。缺省情况下, Linux 在系统安装过程中按照1 个 Inode 对应 2k 磁盘空间来计算每个分区的最大 Inode 数。一旦文件系统创建之后,每个分区可用 Inode 数就无法进行动态调整。
正常来说,一般不太会出现某个分区的 Inode 耗尽而磁盘空间尚余的情况,除非像我碰到的这样垃圾小文件疯长而又没进行有效的清理。但如果确实需要的话,可以在创建文件系统(比如用 mke2fs )的时候根据实际需要来调整这个参数(比如分区如果用于存放超大视频文件的话 Inode 的数量可以少一些;如果打算存放的文件是大量小于 2k 的迷你文件的话就要考虑多创建一些 Inode)。

关于/var/spool/clientmqueue目录:

问题现象:linux操作系统中的/var/spool/clientmqueue/目录下存在大量文件。
原因分析:系统中有用户开启了cron,而cron中执行的程序有输出内容,输出内容会以邮件形式发给cron的用户,而sendmail没有启动所以就产生了这些文件;
解决办法: 将crontab里面的命令后面加上> /dev/null 2>&1

关于标准输出、错误输出、/dev/null

find / -size  +5000000c  2> /dev/null
1>/dev/null   表示将命令的标准输出重定向到   /dev/null  
2>/dev/null   表示将命令的错误输出重定向到   /dev/null 

tar zcvfp cvs.tar.gz /repository >/dev/null 2>&1
>/dev/null   将输出重定向到/dev/null,这是个空设备,也就是忽略其输出。    
2>&1     是将错误输出到标准输出,如果在控制台调试,也就是屏幕上,方便调试

/dev/mapper/VolGroup00-LogVol00 100% 如何处理 ?

df -h
df -il
du -sh /* 2>/dev/null| sort -nr

-------------

服务器磁盘跑满了, 命令查看 如下
[root@localhost mapper]# df
文件系统               1K-块        已用     可用 已用% 挂载点
/dev/mapper/VolGroup00-LogVol00
269232512 255332084      3520 100% /
/dev/sda1               101086     20998     74869  22% /boot
tmpfs                  5956256         0   5956256   0% /dev/shm
none                   5956256       104   5956152   1% /var/lib/xenstored
挂载点  /  满了。。。
通过命令
du -sh /* | sort -nr  查看
[root@localhost data0]# du -sh /* | sort -nr
200G      /data1                (这个目录超大)
677M    /var
240M    /lib
236K    /root
148K    /dev
134M    /etc
56K     /tmp
42M     /sbin
23M     /lib64
16M     /boot
16K     /lost+found
8.7M    /bin
8.1G    /data0
8.0K    /srv
8.0K    /opt
8.0K    /mnt
发现 /data1  目录超大, 找到原因 , 这是NGINX 的日志记录,  啥都不说, 直接删除(rm)
删除后在查看
[root@localhost data0]# du -sh /* | sort -nr


1.1G       /data1
677M    /var
240M    /lib
236K    /root
148K    /dev
134M    /etc
56K     /tmp
42M     /sbin
23M     /lib64
16M     /boot
16K     /lost+found
8.7M    /bin
8.1G    /data0
8.0K    /srv
8.0K    /opt
8.0K    /mnt

妥妥的日志下来了:
[root@localhost data1]# df
文件系统               1K-块        已用     可用 已用% 挂载点
/dev/mapper/VolGroup00-LogVol00
269232512  14898204 240437400 6% /
/dev/sda1               101086     20998     74869  22% /boot
tmpfs                  5956256         0   5956256   0% /dev/shm
none                   5956256       104   5956152   1% /var/lib/xenstored
总结:   通过命令查看  到底是那个文件占用的空间大, 然后去分析这个文件是什么左右, 如果是日志之类的, 备份,直接干掉