最近为测试自己写的服务器，临时写了一个客户端，总是发现客户端收到SIGPIPE的信号，然后进程退出。
 
为了客户端进程收到SIGPIPE不退出，我打算忽略该信号，下面是我用过的方法：
 
（1）间接忽略
 
 
static void SignalHandler(int nSigno)
{
    signal(nSigno, SignalHandler);
    switch(nSigno)
    {
    case SIGPIPE:
        printf("Process will not exit\n");
        break;
    default:
        printf("%d signal unregister\n", nSigno);
        break;
    }
}

atic void InitSignalHandler()
{
    signal(SIGPIPE , &SignalHandler);
}

int main（）
{
        InitSignalHandler();
           ........
         return 0；
}
 

 
 
 
 
（2）直接忽略
 
 
signal(SIGPIPE,SIG_IGN);
 
 
（3）重载signaction 
 
struct sigaction sa;
sa.sa_handler = SIG_IGN;
sigaction( SIGPIPE, &sa, 0 );
 
 
（1）（2）（3）都不能够忽略，客户端收到SIGPIPE之后依然进程退出。 
于是乎，查SIGPIPE这个信号的特性：
 
如果在写到管道时读进程已终止，则产生此信号。当类型为SOCK_STREAM的套接字已不再连接时，进程写到该套接字也产生此信号。
 
                                                                                                                        ——《UNIX环境高级编程》中10.2节
 
由于我的客户端是用send（）进行发送数据的，通过man手册查看send（）函数，看到有一条这样说：
 
       MSG_NOSIGNAL
               Requests not to send SIGPIPE on errors on stream oriented sockets when the other end breaks the connection. The EPIPE error is still returned.
 于是将send（）最后一个参数flags改为MSG_NOSIGNAL，再次启动客户端测试。SIGPIPE被忽略，客户端没有因为该信号退出。
 
将这次经历记录下来，与看到的人共享。
 

 

 
    

     make执行过程中所产生错误并不都是致命的；特别是在命令行之前存在“-”、或者make使用“-k”选项执行时。make执行过程的致命错误都带有前缀字符串“***”。错误信息都有前缀，一种是执行程序名作为错误前缀（通常是“make”）；另外一种是当makefile本身存在语法错误无法被make解析并执行时，前缀包含了makefile文件名和出现错误的行号。
     

     
在下述的错误列表中，省略了普通前缀：
     

     
[FOO] Error NN
     
[FOO] signal description
     
这类错误并不是make的真正错误。它表示make检测到make所调用的作为执行命令的程序返回一个非零状态（Error NN），或者此命令程序以非正常方式退出（携带某种信号），参考 5.4 命令的错误 一节。
     
如果错误信息中没有附加“***”字符串，则是子过程的调用失败，如果Makefile中此命令有前缀“-”，make会忽略这个错误。
     

     

     
missing separator. Stop.
     
missing separator (did you mean TAB instead of 8 spaces?). Stop.
     
不可识别的命令行，make在读取Makefile过程中不能解析其中包含的内容。GNU make在读取Makefile时根据各种分隔符（:, =, [TAB]字符等）来识别Makefile的每一行内容。这些错误意味着make不能发现一个合法的分隔符。
     
出现这些错误信息的可能的原因是（或许是编辑器，绝大部分是ms- windows的编辑器）在Makefile中的命令之前使用了4个（或者8个）空格代替了[Tab]字符。这种情况，将产生上述的第二种形式产生错误信息。且记，所有的命令行都应该是以[Tab]字符开始的。
     

     

     
commands commence before first target. Stop.
     
missing rule before commands. Stop.
     
Makefile可能是以命令行开始：以[Tab]字符开始，但不是一个合法的命令行（例如，一个变量的赋值）。命令行必须和规则一一对应。
     
产生第二种的错误的原因可能是一行的第一个非空字符为分号，make会认为此处遗漏了规则的“target: prerequisite”部分。
     

     

     
No rule to make target `XXX'.
     
No rule to make target ` XXX ', needed by `yyy'.
     
无法为重建目标“XXX”找到合适的规则，包括明确规则和隐含规则。
     
修正这个错误的方法是：在Makefile中添加一个重建目标的规则。其它可能导致这些错误的原因是Makefile中文件名拼写错误，或者破坏了源文件树（一个文件不能被重建，可能是由于依赖文件的问题）。
     

     

     
No targets specified and no makefile found. Stop.
     
No targets. Stop.
     
第一个错误表示在命令行中没有指定需要重建的目标，并且make不能读入任何makefile文件。第二个错误表示能够找到makefile文件，但没有终极目标或者没有在命令行中指出需要重建的目标。这种情况下，make什么也不做。参考 第九章 执行make
     

     

     
Makefile `XXX' was not found.
     
Included makefile `XXX' was not found.
     
没有使用“-f”指定makefile文件，make不能在当前目录下找到默认Makefile（makefile或者GNUmakefile）。使用“-f”指定文件，但不能读取这个指定的makefile文件。
     

     

     
warning: overriding commands for target `XXX'
     
warning: ignoring old commands for target `XXX'
     
对同一目标“XXX”存在一个以上的重建命令。GNU make规定：当同一个文件作为多个规则的目标时，只能有一个规则定义重建它的命令（双冒号规则除外）。如果为一个目标多次指定了相同或者不同的命令，就会产生第一个告警；第二个告警信息说新指定的命令覆盖了上一次指定的命令。
     

     

     
Circular XXX <- YYY dependency dropped.
     
规则的依赖关系产生了循环：目标“XXX”的依赖文件为“YYY”，而依赖“YYY”的依赖列表中又包含“XXX”。
     

     

     
Recursive variable `XXX' references itself (eventually). Stop.
     
make的变量“XXX”（递归展开式）在替换展开时，引用它自身。无论对于直接展开式变量（通过:=定义的）或追加定义（+=），这都是不允许的。
     

     

     
Unterminated variable reference. Stop.
     
变量或者函数引用语法不正确，没有使用完整的的括号（缺少左括号或者右括号）。
     

     

     
insufficient arguments to function `XXX'. Stop.
     
函数“XXX”引用时参数数目不正确。函数缺少参数。
     

     

     
missing target pattern. Stop.
     
multiple target patterns. Stop.
     
target pattern contains no `%'. Stop.               <<<====我编译J_SIM时出现的错误!
     
mixed implicit and static pattern rules. Stop.
     
不正确的静态模式规则。
     
第一条错误的原因是：静态模式规则的目标段中没有模式目标；
     
第二条错误的原因是：静态模式规则的目标段中存在多个模式目标；
     
第三条错误的原因是：静态模式规则的目标段目标模式中没有包含模式字符“%”；
     
第四条错误的原因是：静态模式规则的三部分都包含了模式字符“%”。正确的应该是只有后两个才可以包含模式字符“%”。
     

     

     
warning: -jN forced in submake: disabling jobserver mode.
     
这一条告警和下条告警信息发生在：make检测到递归的make调用时，可通信的子make进程出现并行处理的错误。递归执行的make的命令行参数中存在“-jN”参数（N的值大于1），在有些情况下可能导致此错误，例如：Makefile中变量“MAKE”被赋值为“make –j2”，并且递归调用的命令行中使用变量“MAKE”。在这种情况下，被调用make进程不能和其它make进程进行通信，其只能简单的独立的并行处理两个任务”。
     

     
warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
     
为了现实make进程之间的通信，上层make进程将传递信息给子make进程。在传递信息过程中可能存在这种情况，子make进程不是一个实际的make进程，而上层make却不能确定子进程是否是真实的make进程。它只是将所有信息传递下去。上层make采用正常的算法来决定这些。当出现这种情况，子进程只会接受父进程传递的部分有用的信息。子进程会产生该警告信息，之后按照其内建的顺序方式进行处理。
     

     

     

     
我写了一个Makefile,是用来在Linux2.4下编译一个模块的,其内容如下:
     
INCLUDEDIR = /usr/src/linux-2.4/include
     
DEBFLAGS = -O2
     
CC = gcc
     
CFLAGS = -D__KERNEL__ -DMODULE -Wall $(DEBFLAGS)
     
CFLAGS += -I$(INCLUDEDIR)
     
TARGET = ds1307
     
OBJS = $(TARGET).o
     
SRC = $(TARGET).c
     
$(CC) $(CFLAGS)
     
当我执行make的时候,所报错误为:
     
Makefile:9:*** commands commence before first target. Stop
     
请问高手,我的错误出在什么地方.
     

     
没定义目标,加一行，变成下面这个样子：
     
dsl307:
     
$(CC) $(CFLAGS)
     

     
我写了一个模块，名字叫zariphix_modules_001.c,内容如下：
     
#include<linux/kernel.h>
     
#include<linux/module.h>
     

     
int init_module(){
     
printk("Hello World!/n");
     
return 0;
     
}
     

     
void cleanup_module(){
     
printk("Bye-bye!/n");
     
}
     

     
然后写了一个Makefile，内容如下：
     

     
CC=gcc
     
MODFLAGS := -Wall -DMODULE -D__KERNEL__ -DLINUX
     
zariphix_modules_001.o: zariphix_modules_001.c /usr/include/linux/version.h
     
$(CC) $(MODFLAGS) -c zariphix_modules_001.c
     

     
我在make的时候提示以下错误：
     
Makefile:5: *** 遗漏分隔符 。 停止。
     
分隔符是什么呢？还有我找不到我的内核源码树在系统的哪个位置，/usr/src下面没有
     
我用的系统是 ubuntu 5.10
     

     
$(CC) $(MODFLAGS) -c zariphix_modules_001.c
     
这一行最前面要有一个 TAB，不能在第一列上，注意，是TAB, 不是空格，
     

     
运行 $ sudo make
     
又有了一大串错误提示：
     
引用:
     
gcc -Wall -DMODULE -D__KERNEL__ -DLINUX -c zariphix_modules_001.c
     
In file included from /usr/include/linux/sched.h:16,
     
from /usr/include/linux/module.h:9,
     
from zariphix_modules_001.c:2:
     
/usr/include/linux/signal.h:2:2: warning: #warning "You should include <signal.h>. This time I will do it for you."
     
In file included from /usr/include/linux/resource.h:4,
     
from /usr/include/linux/sched.h:79,
     
from /usr/include/linux/module.h:9,
     
from zariphix_modules_001.c:2:
     
/usr/include/linux/time.h:9: 错误：‘struct timespec’ 重定义
     
/usr/include/linux/time.h:15: 错误：‘struct timeval’ 重定义
     
/usr/include/linux/time.h:20: 错误：‘struct timezone’ 重定义
     
/usr/include/linux/time.h:47: 错误：‘struct itimerval’ 重定义
     
In file included from zariphix_modules_001.c:2:
     
/usr/include/linux/module.h:41: 错误：字段 ‘attr’ 的类型不完全
     
/usr/include/linux/module.h:49: 错误：字段 ‘kobj’ 的类型不完全
     
zariphix_modules_001.c: 在函数 ‘init_module’ 中：
     
zariphix_modules_001.c:5: 警告：隐式声明函数 ‘printk’
     
make: *** [zariphix_modules_001.o] 错误 1
     
这是怎么回事呢？
     
解决这个问题了，原来是因为我的机器中没有内核源码树。
     
我下了一个新的内核源码包，编译了一下，但没有安装。再次make就通过。
     
可新的问题又出现了，当我用insmod加载模块的时候提示：
     
insmod: error inserting 'zariphix_modules_001.ko': -1 Invalid module format
     
郁闷。我试过了使用绝对路径和相对路径，也使用modprobe来加载，可都显示错误，这又是怎么回事呢？
     
也终于解决了~~~
     
安装了编译的内核~~就OK了
    
 

问题描述：今天写程序，socket后send出现这个问题，send的返回值为-1，而errno为32，这个错误代码为broken pipe，即管道破裂。
 
 
 
 
 
问题形成原因：后来通过排查研究，发现出现该种问题出现的可能性为以下两种：
 
1.socket失败，与服务器端的链接没有成功，从而管道破裂。
 
2.服务端将客户端的socket断开，一样造成这样的问题。
 
 
 
 
 
此时这样的程序收到broken pipe的信号，会自动退出我们可以在产生信号前利用方法 signal(int signum, sighandler_t handler) 设置信号的处理。如果没有调用此方法，系统就会调用默认处理方法：中止程序，显示提示信息(就是我们经常遇到的问题)。我们可以调用系统的处理方法，也可以自定义处理方法。 
 
对一个已经收到FIN包的socket调用read方法, 如果接收缓冲已空, 则返回0, 
 这就是常说的表示连接关闭. 但第一次对其调用write方法时, 如果发送缓冲没问题, 
 会返回正确写入(发送). 但发送的报文会导致对端发送RST报文, 
 因为对端的socket已经调用了close, 完全关闭, 既不发送, 也不接收数据. 所以, 
 第二次调用write方法(假设在收到RST之后), 会生成SIGPIPE信号, 导致进程退出.
 
为了避免进程退出, 可以捕获SIGPIPE信号, 或者忽略它, 
 给它设置SIG_IGN信号处理函数:
 
signal(SIGPIPE, SIG_IGN);
 
这样, 第二次调用write方法时, 会返回-1, 同时errno置为SIGPIPE. 
 程序便能知道对端已经关闭.

/dev/null linux下的黑洞，类似于垃圾桶，任何东西到里面都会被粉碎
 
> 重定向 >>追加
 
1 标准输出
 
2 错误输出
 
& 表示等同于的意思， 2>&1 表示2的重定向等同于1
 
 
 
bash xxx.sh > /dev/null 2>&1