Linux

linux上远程协助软件使用攻略

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

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

Linux 常用内核网络参数与相关问题处理

本文总结了常见的 Linux 内核参数及相关问题。修改内核参数前,您需要:

  • 从实际需要出发,最好有相关数据的支撑,若您的业务没有受到影响不建议调整内核参数。
  • 了解每一个参数的具体作用,并且同类型或版本操作系统下内核参数可能有所不同。
  • 备份 ECS 实例中的重要数据。参阅文档创建快照

Linux 常用内核网络参数

参数 描述
net.core.rmem_default 默认的 TCP 数据接收窗口大小(字节)。
net.core.rmem_max 最大的 TCP 数据接收窗口(字节)。
net.core.wmem_default 默认的 TCP 数据发送窗口大小(字节)。
net.core.wmem_max 最大的 TCP 数据发送窗口(字节)。
net.core.netdev_max_backlog 在每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许送到队列的数据包的最大数目。
net.core.somaxconn 定义了系统中每一个端口最大的监听队列的长度,这是个全局的参数。
net.core.optmem_max 表示每个套接字所允许的最大缓冲区的大小。
net.ipv4.tcp_mem 确定 TCP 栈应该如何反映内存使用,每个值的单位都是内存页(通常是
                

Linux 实例常用内核网络参数介绍与常见问题处理

Linux 实例常用内核网络参数介绍与常见问题处理

KB: 41334

 ·

更新时间:2018-11-16 20:26:51

   

本文总结了常见的 Linux 内核参数及相关问题。修改内核参数前,您需要:

  • 从实际需要出发,最好有相关数据的支撑,不建议随意调整内核参数。
  • 了解参数的具体作用,且注意同类型或版本环境的内核参数可能有所不同。
  • 备份 ECS 实例中的重要数据。参阅文档创建快照

查看和修改 Linux 实例内核参数

方法一、通过 /proc/sys/ 目录

查看内核参数:使用 cat 查看对应文件的内容,例如执行命令 cat /proc/sys/net/ipv4/tcp_tw_recycle 查看 

                

linux自定义开机启动脚本

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

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

 

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

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

linux后台执行命令(非阻塞):&和nohup

当我们在终端或控制台工作时,可能不希望由于运行一个作业而占住了屏幕,因为可能还有更重要的事情要做,比如阅读电子邮件。对于密集访问磁盘的进程,我们更希望它能够在每天的非负荷高峰时间段运行(例如凌晨)。为了使这些进程能够在后台运行,也就是说不在终端屏幕上运行,有几种选择方法可供使用。

  • &
    当在前台运行某个作业时,终端被该作业占据;可以在命令后面加上& 实现后台运行。例如:sh test.sh &
    适合在后台运行的命令有f i n d、费时的排序及一些s h e l l脚本。在后台运行作业时要当心:需要用户交互的命令不要放在后台执行,因为这样你的机器就会在那里傻等。不过,作业在后台运行一样会将结果输出到屏幕上,干扰你的工作。如果放在后台运行的作业会产生大量的输出,最好使用下面的方法把它的输出重定向到某个文件中:
        

linux 之信号signal处理机制

最近同事的程序设计过程中用到了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各种类型:

Signal
Description
SIGABRT
由调用abort函数产生,进程非正常退出
SIGALRM
用alarm函数设置的timer超时或setitimer函数设置的interval timer超时
SIGBUS
某种特定的硬件异常,通常由内存访问引起
SIGCANCEL
由Solaris Thread Library内部使用,通常不会使用
SIGCHLD
进程Terminate或Stop的时候,SIGCHLD会发送给它的父进程。缺省情况下该Signal会被忽略
SIGCONT
当被stop的进程恢复运行的时候,自动发送
SIGEMT
和实现相关的硬件异常
SIGFPE