问题:rm -rf /data/www/*
rm: cannot remove ‘/data/www/yum.boosh.com.cn/centos/5/x86_64/rsyslog_v8/RPMS’: Directory not empty

办法:
在linux系统中,我们有时候删除文件夹的时候,提示rm: cannot remove `dir-name’: Directory not empty,或者文件夹非空,即使使用sudo也无法删除,那是因为系统存在使用或者执行文件夹中可执行程序,我们只需要执行命令:

lsof dir-name/.fuse_hidden000bd8c100000*

which lsof
/usr/sbin/lsof

rpm -qf /usr/sbin/lsof
lsof-4.82-5.el6.x86_64

找到那些程序在使用文件夹中的文件,

然后使用

kill 命令结束进程,如:kill 2739

然后就可以删除文件夹了。

From:https://blog.csdn.net/u014001964/article/details/82291064
一)nginx的引入epoll后惊群处理:
accept() 和 epoll_wait() 调用,还存在一个惊群的问题。换句话说,当网络 I/O 事件发生时,多个进程被同时唤醒,但实际上只有一个进程来响应这个事件,其他被唤醒的进程都会重新休眠。

其中,accept() 的惊群问题,已经在 Linux 2.6 中解决了;
而 epoll 的问题,到了 Linux 4.5 ,才通过 EPOLLEXCLUSIVE 解决。
为了避免惊群问题, Nginx 在每个 worker 进程中,都增加一个了全局锁(accept_mutex)。这些 worker 进程需要首先竞争到锁,只有竞争到锁的进程,才会加入到 epoll 中,这样就确保只有一个 worker 子进程被唤醒。

简单点说:Apache动辄就会启动成百上千的进程,如果发生惊群问题的话,影响相对较大;但是对Nginx而言,一般来说,worker_processes会设置成CPU个数,所以最多也就几十个,即便发生惊群问题的话,影响相对也较小。
另:高版本的Linux中,accept不存在惊群问题,不过epoll_wait等操作还有。

  假设你养了一百只小鸡,现在你有一粒粮食,那么有两种喂食方法:
你把这粒粮食直接扔到小鸡中间,一百只小鸡一起上来抢,最终只有一只小鸡能得手,其它九十九只小鸡只能铩羽而归。这就相当于关闭了accept_mutex。
你主动抓一只小鸡过来,把这粒粮食塞到它嘴里,其它九十九只小鸡对此浑然不知,该睡觉睡觉。这就相当于激活了accept_mutex。
  可以看到此场景下,激活accept_mutex相对更好一些,让我们修改一下问题的场景,我不再只有一粒粮食,而是一盆粮食,怎么办?
此时如果仍然采用主动抓小鸡过来塞粮食的做法就太低效了,一盆粮食不知何年何月才能喂完,大家可以设想一下几十只小鸡排队等着喂食时那种翘首以盼的情景。此时更好的方法是把这盆粮食直接撒到小鸡中间,让它们自己去抢,虽然这可能会造成一定程度的混乱,但是整体的效率无疑大大增强了。
  Nginx缺省激活了accept_mutex(最新版缺省禁用),是一种保守的选择。如果关闭了它,可能会引起一定程度的惊群问题,表现为上下文切换增多(sar -w)或者负载上升,但是如果你的网站访问量比较大,为了系统的吞吐量,我还是建议大家关闭它。

链接:https://www.jianshu.com/p/129dd4320ae1

二)边缘触发和水平触发主要体现在边缘触发程序复杂还是系统承担这个复杂而用水平触发,边缘触发只通知一次,增加程序处理难度和各种异常处理:
第一种,使用非阻塞 I/O 和水平触发通知,比如使用 select 或者 poll。

根据刚才水平触发的原理,select 和 poll 需要从文件描述符列表中,找出哪些可以执行 I/O ,然后进行真正的网络 I/O 读写。由于 I/O 是非阻塞的,一个线程中就可以同时监控一批套接字的文件描述符,这样就达到了单线程处理多请求的目的。

所以,这种方式的最大优点,是对应用程序比较友好,它的 API 非常简单。

但是,应用软件使用 select 和 poll 时,需要对这些文件描述符列表进行轮询,这样,请求数多的时候就会比较耗时。并且,select 和 poll 还有一些其他的限制。

select 使用固定长度的位相量,表示文件描述符的集合,因此会有最大描述符数量的限制。比如,在 32 位系统中,默认限制是 1024。并且,在 select 内部,检查套接字状态是用轮询的方法,再加上应用软件使用时的轮询,就变成了一个 O(n^2) 的关系。

而 poll 改进了 select 的表示方法,换成了一个没有固定长度的数组,这样就没有了最大描述符数量的限制(当然还会受到系统文件描述符限制)。但应用程序在使用 poll 时,同样需要对文件描述符列表进行轮询,这样,处理耗时跟描述符数量就是 O(N) 的关系。

除此之外,应用程序每次调用 select 和 poll 时,还需要把文件描述符的集合,从用户空间传入内核空间,由内核修改后,再传出到用户空间中。这一来一回的内核空间与用户空间切换,也增加了处理成本。

有没有什么更好的方式来处理呢?答案自然是肯定的。

第二种,使用非阻塞 I/O 和边缘触发通知,比如 epoll。

既然 select 和 poll 有那么多的问题,就需要继续对其进行优化,而 epoll 就很好地解决了这些问题。

epoll 使用红黑树,在内核中管理文件描述符的集合,这样,就不需要应用程序在每次操作时都传入、传出这个集合。
epoll 使用事件驱动的机制,只关注有 I/O 事件发生的文件描述符,不需要轮询扫描整个集合。
不过要注意,epoll 是在 Linux 2.6 中才新增的功能(2.4 虽然也有,但功能不完善)。由于边缘触发只在文件描述符可读或可写事件发生时才通知,那么应用程序就需要尽可能多地执行 I/O,并要处理更多的异常事件。

第三种,使用异步 I/O(Asynchronous I/O,简称为 AIO)。在前面文件系统原理的内容中,我曾介绍过异步 I/O 与同步 I/O 的区别。异步 I/O 允许应用程序同时发起很多 I/O 操作,而不用等待这些操作完成。而在 I/O 完成后,系统会用事件通知(比如信号或者回调函数)的方式,告诉应用程序。这时,应用程序才会去查询 I/O 操作的结果。

异步 I/O 也是到了 Linux 2.6 才支持的功能,并且在很长时间里都处于不完善的状态,比如 glibc 提供的异步 I/O 库,就一直被社区诟病。同时,由于异步 I/O 跟我们的直观逻辑不太一样,想要使用的话,一定要小心设计,其使用难度比较高。

工作模型优化

了解了 I/O 模型后,请求处理的优化就比较直观了。使用 I/O 多路复用后,就可以在一个进程或线程中处理多个请求,其中,又有下面两种不同的工作模型。

第一种,主进程 + 多个 worker 子进程,这也是最常用的一种模型。这种方法的一个通用工作模式就是:

主进程执行 bind() + listen() 后,创建多个子进程;
然后,在每个子进程中,都通过 accept() 或 epoll_wait() ,来处理相同的套接字。
比如,最常用的反向代理服务器 Nginx 就是这么工作的。它也是由主进程和多个 worker 进程组成。主进程主要用来初始化套接字,并管理子进程的生命周期;而 worker 进程,则负责实际的请求处理。我画了一张图来表示这个关系。
示例五:显示每个进程的上下文切换情况(-w)
pidstat -w -p 2831









PID:进程id
Cswch/s:每秒主动任务上下文切换数量
Nvcswch/s:每秒被动任务上下文切换数量
Command:命令名

示例六:显示选择任务的线程的统计信息外的额外信息 (-t)
pidstat -t -p 2831
$pidstat -t -p 4194
Linux 4.20.3-1.el7.elrepo.x86_64 (levoo-web_php_bj_cp_101_200_228_135)   02/03/19        _x86_64_        (1 CPU)

15:51:17      UID      TGID       TID    %usr %system  %guest    %CPU   CPU  Command
15:51:17        0      4194         -    0.00    0.00    0.00    0.00     0  minivtun
15:51:17        0         -      4194    0.00    0.00    0.00    0.00     0  |__minivtun


链接:https://www.jianshu.com/p/3991c0dba094
centos6.8不能安装最新版git的解决办法:
1  Install WANDisco repo package:
yum install http://opensource.wandisco.com/centos/6/git/x86_64/wandisco-git-release-6-1.noarch.rpm

2 Install the latest version of Git 2.x:
yum install git

3 Verify the version of Git that was installed:
git --version


来自链接:https://www.jianshu.com/p/ab98dd540919
option + command+esc  #发现微信截图让微信程序死了,于是用这个快捷键呼出后强制退出后系统好了。

注64位系统

第一步下载 wget http://www.rarlab.com/rar/rarlinux-x64-5.3.0.tar.gz
第二步解压 tar -zxvf rarlinux-x64-5.3.0.tar.gz
第三步     进入解压出的“rar”文件夹 cd rar
第四步    进行配置 make
       显示如下表示成功
mkdir -p /usr/local/bin

mkdir -p /usr/local/lib

cp rar unrar /usr/local/bin

cp rarfiles.lst /etc

cp default.sfx /usr/local/lib
可以用rar命令开始解压 
rar x test.rar //解压 test.rar 到当前目录
压缩
rar test.rar ./test/ //将 test目录打包为 test.rar
---------------------
原文:https://blog.csdn.net/weixin_41404058/article/details/80304869
部分应用可使用common+n快捷键
相信不少使用 Mac 的朋友对 OS X 里的时间显示都有很大意见,只能显示当前日期,功能缺失得很厉害,所以不少朋友都使用第三方的日历软件来取代系统自带的,像 Fantastical。不过 Fantastical 是一款收费软件,如果想要免费软件的话,其实大家还可以试试这款 Itsycal。
官方网站:https://www.mowglii.com/itsycal/

http://www.apprcn.com/itsycal.html


brew install tree

来自:https://blog.csdn.net/xidiancoder/article/details/72654583
brew install iproute2mac
来自:https://blog.csdn.net/u010164190/article/details/79474309

实用工具-》网络工具-》Traceroute
来自:https://blog.csdn.net/qq_38789531/article/details/82734646
密钥登陆能,发现SSH不行,提示:
$ssh -l xiangdong 10.244.25.**
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

到:
$ssh -l xiangdong 10.244.25.**
xiangdong@10.244.25.89's password:


实践OK办法,能密钥能密码:
cat  /etc/ssh/sshd_config|grep -E "PermitRootLogin|UsePAM|PasswordAuthentication"

UsePAM yes  #改成NO后出现需要密钥,还登陆不了。后修改为yes后重启oK service sshd restart
PermitRootLogin yes
PasswordAuthentication yes


root依然不行,修改UsePAM no,还是不行,后来加一个irdcops帐号且能 sudo ,也就用它去SSH就行了:
$ssh -l root 10.244.25.**
root@10.244.25.**'s password:
Permission denied, please try again.

==================================
首先:配置ssh服务器配置文件。

在root 用户下才能配置。

vi /etc/ssh/sshd_config

权限设为no:

#PermitRootLogin yes

#UsePAM yes

#PasswordAuthentication yes

如果前面有# 号,将#号去掉,之后将yes修改为no。

修改之后为:

PermitRootLogin no

UsePAM no

PasswordAuthentication no

权限设为yes:

RSAAuthentication yes

PubkeyAuthentication yes

(2)重启sshd服务

systemctl restart sshd.service

systemctl status sshd.service #查看ssh服务的状态

#systemctl start sshd.service  #开启ssh服务

#sytemctl enable sshd.service #ssh服务随开机启动,还有个disabled

#systemctl stop sshd.ervice #停止

正常情况下应该是Active:active(running)
摘自:https://www.cnblogs.com/xubing-613/p/6844564.html
Demon:
code ~/.bashrc

根据终端命令行使用 bash 还是 zsh 选择编辑环境变量的文件。

bash,写入 ~/.bash_profile

zsh, 写入 ~/.zshrc

阅读全文
以下四条命令搞定,谁用谁知道



来自:https://blog.csdn.net/weixin_40545512/article/details/82685927
背影:买了个Mac本,无法用.vbs脚本,输入个密码啥的更快一些。
xiangdongAutoEnterPasswd*.py


secureCRT支持运行.js和.vbs以及.py格式的脚本,无奈mac上识别前两个格式的脚本只能写一写python脚本,
举个简单的例子,利用脚本直接ssh连接一台机器,
在View菜单中勾选Button Bar让这个菜单在下方显示出来,
在下方的Default右方右键出现一个菜单点击New Button按钮,在显示框的Function一栏选择Run Script中间选择编写好的.py文件
.py文件的内容大致如下:


另外一个:


来自:https://blog.csdn.net/medivhq/article/details/52119572
好不容易买个Mac,最近一段时间在使用 git log 和 git diff 命令的时候一直有乱码出现,具体表现为在行首出现 ESC[33,而在行尾出现 ESC[m,如下所示:


解决
经过搜索之后了解到,出现该问题的原因是 git 使用的默认分页程序是 less,而默认的直接运行 less 的话,会无法正确解析转义字符。但是如果以 -r 命令来运行 less 的话,就可以解决了。故解决办法就是将 git 的默认分页程序改为 “less -r” 来运行,如下:
git config --global core.pager "less -r" 后:
好了,买个Mac花了十年,用它得花一年。

Git log 和Git diff显示正常:

方向来自:https://blog.yongli1992.com/2015/08/14/git-log-diff-esc-garbled/
装在台式机上,先在笔记本上用一个USB给Win上用软件UltraISO把extix-19.1-64bit-kde-kodi18-refracta-calamares-nvidia-1970mb-181228.iso给写入硬盘映像,开机启动BIOS设置从这个U盘启动,然后,再用一个U盘给把这个extix-19.1-64bit-kde-kodi18-refracta-calamares-nvidia-1970mb-181228.iso给拷贝进去,再插入到台式机上,这个ExTix会自动识别为/dev/sdc,用fdisk -l也能看到,于是把这台式机的那个磁盘/dev/sda给格式化:
mkfs.ext4 /dev/sda


cp extix-19.0-64bit-deepin-refracta-calamares-kodi18-1760mb-181208.iso /dev/sda

重启,设置BIOS从台式机磁盘启动,OK。但是空间没有500G和之前U盘一样大,怎么办?
https://blog.csdn.net/huanghai381/article/details/50033775


From:https://www.extix.se/?page_id=24

ExTiX - The Ultimate Linux System
Based on Debian/Ubuntu with Deepin/LXQt/KDE and kernel 4.20-rc4
Deepin:  https://sourceforge.net/projects/extix/files/
https://cytranet.dl.sourceforge.net/project/extix/extix-19.0-64bit-deepin-refracta-calamares-kodi18-1760mb-181208.iso
Linux嵌入式由于诸多的限制,调试方法有限,常常出现面对Bug束手无策的情况,现在介绍一种通过信号处理对Linux嵌入式应用程序进行调试的方法。

linux中一共有32种信号,在/usr/include/bits/signum.h 头文件中可以看到,具体如下:SIGHUP ;SIGINT ;SIGQUIT ;SIGILL ;SIGTRAP ;SIGABRT ;SIGIOT ;SIGBUS ;SIGFPE ;SIGKILL ;SIGUSR1 ;SIGSEGV ;SIGUSR2 ;SIGPIPE ;SIGALRM ;SIGTERM ;SIGSTKFLT ;SIGCLD ;SIGCHLD ;SIGCONT ;SIGSTOP ;SIGTSTP ;SIGTTIN ;SIGTTOU ;SIGURG ;SIGXCPU ;SIGXFSZ ;SIGVTALRM ;SIGPROF ;SIGWINCH ;SIGPOLL ;SIGIO ;SIGPWR ;SIGSYS ;SIGUNUSED
以上来自:https://blog.csdn.net/u010133805/article/details/53899667 ,他用的c++,改成c研究研究,如下:

看编号,用kill -l,SIGUSR1编号为10,如下所示:
#kill -l
1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

其中SIGUSER1信号用户可以自己定义其处理行为,处理范例如下:

#make usr1
cc     usr1.c   -o usr1
./usr1

ps -ef|grep usr1

kill -s SIGUSR1 17331
sig_num=10
flag is true!
sig_num=10
flag is false
flag is false
分页: 7/40 第一页 上页 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 下页 最后页 [ 显示模式: 摘要 | 列表 ]