一、概述
使用IDEA生成的linux系统可执行程序.sh文件，手动启动没有问题，开机自启动踩了不少坑，网上提供的三种方法都不适合，

有一种方法是在/etc/rc.local文件中加上启动脚本的命令，我加上之后，出现如下错误

我猜可能是mysql服务还没有启动，导致连接请求被拒绝。

因为我一直想将生成的这个.sh文件开机自启动，但是无奈总是不尽人意，后来换个思路，通过xshell脚本来启动这个.sh文件，搞定！…

Linux中zip和tar处理软链接的差异与选择

1. 系统环境

   cat /etc/redhat-release 
   CentOS Linux release 7.3.1611 (Core)
   getenforce
   Disabled

2. 安装zip，unzip

   #直接yum安装
   yum install -y zip unzip

3. 创建实验文件

   #cd到tmp目录下
   cd /tmp

   #创建目录及文件
   mkdir test
   echo "this is a test file" > test.txt
   cd ./test

1.这时候就应该新做一个软件包仓库了，一般仓库文件存放在/etc/yum.repos.d/这个文件夹下，如下图…

最近同事的程序设计过程中用到了Linux的signal机制，从而引发了我对Linux中signal机制的思考。Signal机制在Linux中是一个非常常用的进程间通信机制，很多人在使用的时候不会考虑该机制是具体如何实现的。signal机制可以被理解成进程的软中断，因此，在实时性方面还是相对比较高的。Linux中signal机制的模型可以采用下图进行描述。

个进程都会采用一个进程控制块对其进行描述，进程控制块中设计了一个signal的位图信息，其中的每位与具体的signal相对应，这与中断机制是保持一致的。当系统中一个进程A通过signal系统调用向进程B发送signal时，设置进程B的对应signal位图，类似于触发了signal对应中断。发送signal只是“中断”触发的一个过程，具体执行会在两个阶段发生：

1、  system call返回。进程B由于调用了system call后，从内核返回用户态时需要检查他拥有的signal位图信息表，此时是一个执行点。

2、  中断返回。进程被系统中断打断之后，系统将CPU交给进程时，需要检查即将执行进程所拥有的signal位图信息表，此时也是一个执行点。

综上所述，signal的执行点可以理解成从内核态返回用户态时，在返回时，如果发现待执行进程存在被触发的signal，那么在离开内核态之后（也就是将CPU切换到用户模式），执行用户进程为该signal绑定的signal处理函数，从这一点上看，signal处理函数是在用户进程上下文中执行的。当执行完signal处理函数之后，再返回到用户进程被中断或者system call（软中断或者指令陷阱）打断的地方。

Signal机制实现的比较灵活，用户进程由于中断或者system call陷入内核之后，将断点信息都保存到了堆栈中，在内核返回用户态时，如果存在被触发的signal，那么直接将待执行的signal处理函数push到堆栈中，在CPU切换到用户模式之后，直接pop堆栈就可以执行signal处理函数并且返回到用户进程了。Signal处理函数应用了进程上下文，并且应用实际的中断模拟了进程的软中断过程。

最近写程序，各种bug各种错，有一回程序莫名退出，没报错，也没产生日志和core文件，貌似正常退出一样。

但又不是在程序全部走完后退出，中途莫名退出，这就叫我想到了signal，应该是某些函数错误后发送kill信号给主进程，然后退出。

现在总结下signal各种类型：