在您开启愉快的优麒麟生活后，尽管优麒麟已经具有不错的易用性，但您可能还会遇到一些无法独立解决的问题，例如：电脑发生故障、帮助父母使用优麒麟等等。可能条件不足以在用户手册或搜索引擎获取解决方案，这时请求其他富有经验的优麒麟用户远程协助您是一个不错的选择。一些场景下尽管您提供了详细的错误信息，他人仍会无法复现您遇到的问题，笔者建议您选择信任的其他用户远程连接至您的电脑获取协助。那么，如何在优麒麟上发起远程协助呢？

目前在优麒麟中有多种远程协助他人电脑的方案可选，这些方案采用的软件、加密和连接协议各有千秋，本文将从安装方法、安全性、连接协议和连接稳定性等方面介绍不同方案之间的区别以供用户参考。…

一、概述
使用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各种类型：