没有啥用对我来说,卸载掉:
[root@iZ25dcp92ckZ var]# rpm -qa|grep mail
mailx-12.5-12.el7_0.x86_64
libreport-plugin-mailx-2.1.11-21.el7.centos.0.5.x86_64
[root@iZ25dcp92ckZ var]# rpm -e mailx-12.5-12.el7_0.x86_64
错误:依赖检测失败:
        mailx 被 (已安裝) smartmontools-1:6.2-4.el7.x86_64 需要
        mailx 被 (已安裝) libreport-plugin-mailx-2.1.11-21.el7.centos.0.5.x86_64 需要
[root@iZ25dcp92ckZ var]# rpm -e smartmontools-1:6.2-4.el7.x86_64
[root@iZ25dcp92ckZ var]# rpm -e libreport-plugin-mailx-2.1.11-21.el7.centos.0.5.x86_64
[root@iZ25dcp92ckZ var]# rpm -e mailx-12.5-12.el7_0.x86_64
阅读全文
背景:想用户登录ssh到linux时发邮件里有top,但发现出现top: failed tty get 错误 。
通过其他程序或脚本在非交互式模式下调用top命令,经常会出现:
   top: failed tty get 错误
解决办法:加个-b 选项皆可
-b : Batch mode operation
   Starts  top  in  Batch mode, which could be useful for sending output from top to other programs or to a file.  In this mode, top will not accept input and runs until the iterations limit youve set with the -n command-line option or until killed.
例如执行:top -bn 1


通过其他程序或脚本在非交互式模式下调用top命令,经常会出现:
   top: failed tty get 错误
解决办法:加个-b 选项皆可
-b : Batch mode operation
   Starts  top  in  Batch mode, which could be useful for sending output from top to other programs or to a file.  In this mode, top will not accept input and runs until the iterations limit youve set with the -n command-line option or until killed.
例如执行:top -bn 1


来自:http://blog.chinaunix.net/uid-9554532-id-2000668.html
背景:本文作者主要是讲linux下的nginx处理高效是依赖内核驱动事件处理,但是一个一个的事件处理都是建立在一个消息处理队列循环,而这个一个个的循环的一个(一个事件循环)是得一个一个的处理,而OS系统的瓶颈是磁盘IO,而作者认为linux提供的相关磁盘IO异步操作不如FreeBSD的稳健,没有纳入Linux内核而FreeBSD对这块有优势,再就是nginx从应用层上加入了线程池,避免了这个循环被卡住,这两条的解决,真正提升了应用的效率,总之,Nginx对瞬间就处理完的事件上目前还是不错的,而非瞬间就处理完的操作则目前linux和在上面安装低版本的没有线程池支持的nginx来讲,性能并没有得到最大发挥,而这个新版本的nginx(加入了线程池)如果在FreeBSD上,则性能会最优,最后,作者所说的对于不是一瞬间就处理完的业务理论和实践上的确存在,也就是为何对于一些PHP耗时的处理,大多数是安装在apache上,而不是nginx,这也是有这个原因在里面的,很多人一说nginx牛了,就全用nginx,也是没有认真思考,为何大公司都是nginx和apache2同时使用的根源。

step1:
作者显然是有FreeBSD的立场如下:
要命的是,操作系统可能永远没有这个功能。第一次尝试是 2010 年 linux 中引入 fincore() 系统调用方法,没有成功。接着做了一系列尝试,例如引入新的带有 RWF_NONBLOCK 标记的 preadv2() 系统调用方法。所有的这些补丁前景依旧不明朗。比较悲剧的是,因为 持续的口水战 ,导致这些补丁一直没有被内核接受。
另一个原因是,FreeBSD用户根本不会关心这个。因为 FreeBSD 已经有一个非常高效的异步文件读取接口,完全可以不用线程池。

step2:
发文件这块是nginx的软肋,于是用了aio threads来补充:
Nginx从1.7.11开始为AIO(Asynchronous I/O)引入了线程池支持,能够使用多线程读取和发送文件,不会阻塞工人进程.
http://nginx.org/en/docs/http/ngx_http_core_module.html#aio
location /video/ {
sendfile on;
aio threads;
}
要启用多线程支持,configure时需要显式加入--with-threads选项.

step3:php发文件也交给了nginx,提高了效率减轻了sapi的等待时间,也就减少了nginx事件消息处理队列循环等待时间:
比如对于一些需要经过PHP认证身份的附件,可以通过X-Accel-Redirect告诉Nginx文件的路径,让Nginx利用它的线程池读取文件并发送给浏览器,免得阻塞PHP进程.
<?php
auth(); //用户身份认证
header('Content-type: application/octet-stream');
header('Content-Disposition: attachment; filename="'.basename($filePath).'"');
//PHP通过X-Accel-Redirect告诉Nginx文件的路径,Nginx读取文件并发送给浏览器.
header("X-Accel-Redirect: $filePath");
//对比下面直接通过PHP输出文件
//readfile($filePath); //或者echo file_get_contents($filePath);

step4:有人因老外的这篇文章写了评论,http://xiaorui.cc/2015/06/25/%E5%AF%B9%E4%BA%8Enginx%E7%BA%BF%E7%A8%8B%E6%B1%A0thread-pool%E6%8F%90%E9%AB%98%E6%80%A7%E8%83%BD%E7%9A%84%E7%96%91%E6%83%91/

step4涉及到FreeBSD的kqueque,功能角度来盾kqueue比epoll灵活得多。在写kqueue的时候,内核帮你考虑好了不少东西。但是从效率来看,从我作的压力测试来看epoll比kqueue强。估计是学院派自由派的一个哲学问题:
http://jarit.iteye.com/blog/935283
使用 kqueue 在 FreeBSD 上开发高性能应用服务器:
http://blog.csdn.net/xnn2s/article/details/6047038
____________________________________________________________________________
问题
一般情况下,nginx 是一个事件处理器,一个从内核获取连接事件并告诉系统如何处理的控制器。实际上,在操作系统做读写数据调度的时候,nginx是协同系统工作的,所以nginx能越快响应越好。

nginx处理的事件可以是 超时通知、socket可读写的通知 或 错误通知。nginx 接收到这些消息后,会逐一进行处理。但是所有处理过程都是在一个简单的线程循环中完成的。nginx 从消息队列中取出一条event后执行,例如 读写socket的event。在大多数情况下这很快,Nginx瞬间就处理完了。

如果有耗时长的操作发生怎么办?整个消息处理的循环都必须等待这个耗时长的操作完成,才能继续处理其他消息。所以,我们说的“阻塞操作”其实意思是长时间占用消息循环的操作。操作系统可能被各种各样的原因阻塞,或者等待资源的访问,例如硬盘、互斥锁、数据库同步操作等。

例如,当nginx 想要读取没有缓存在内存中的文件时,则要从磁盘读取。但磁盘是比较缓慢的,即使是其他后续的事件不需要访问磁盘,他们也得等待本次事件的访问磁盘结束。结果就是延迟增加和系统资源没有被充分利用。

有些操作系统提供了异步读写文件接口,在nginx中可以使用这些接口(http://nginx.org/en/docs/http/ngx_http_core_module.html?&&&_ga=1.197764335.1343221768.1436170723#aio)。例如FreeBSD就是一个较好的例子,但不幸的是,linux提供的一系列异步读文件接口有不少缺陷。其中一个问题是:文件访问和缓冲需要队列,但是Nginx已经很好解决了。但是还有一个更严重的问题:使用异步接口需要对文件描述符设置O_DIRECT标识,这意味着任何对这个文件的访问会跳过缓存直接访问磁盘上的文件。在大多数情况下,这不是访问文件的最佳方法。


                              ..............


英文原文:Thread Pools in NGINX Boost Performance 9x!
中文翻译:http://www.infoq.com/cn/articles/thread-pools-boost-performance-9x?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global
背景:直接访问ip没有问题,经过cdn后有问题(穿透当dns用,实现故障自动转移,为何不用GSLB[GSLB 是英文Global Server Load Balance的缩写,意思是全局负载均衡。]的dns和类似腾讯的TGW系统,因为没有自己的dns系统...),此时出现http的400错误。
检测办法:在nginx日志的access log中记录post请求的参数值,http://jackxiang.com/post/7728/ 。
发现:这个post的值根本没有取到。而直接绑定IP的就取到了,说明经过了cdn的数据均被干掉了。

而网上常常说是因为header太大引起:
nginx 400 Bad request是request header过大所引起,request过大,通常是由于cookie中写入了较大的值所引起。
每个请求头的长度也不能超过一块缓冲的容量,否则nginx返回错误400 (Bad Request)到客户端。

来自:http://www.linuxidc.com/Linux/2014-06/103685.htm


这个哥们的博客奇怪:
ail -f /opt/nginx/logs/access.log
    116.236.228.180 - - [15/Dec/2010:11:00:15 +0800] "-" 400 0 "-" "-"
    116.236.228.180 - - [15/Dec/2010:11:00:15 +0800] "-" 400 0 "-" "-"

网上大把的文章说是HTTP头/Cookie过大引起的,可以修改nginx.conf中两参数来修正.
代码如下:

    client_header_buffer_size 16k;
          large_client_header_buffers 4 32k;

修改后
代码如下:

    client_header_buffer_size 64k;
         large_client_header_buffers 4 64k;

没有效果,就算我把nginx0.7.62升到最新的0.8.54也没能解决.
在官方论坛中nginx作者提到空主机头不会返回自定义的状态码,是返回400错误.
http://forum.nginx.org/read.php?2,9695,11560
最后修正如下
改为原先的值
代码如下:

    client_header_buffer_size 16k;
         large_client_header_buffers 4 32k;

关闭默认主机的日志记录就可以解决问题
代码如下:

    server {
    listen *:80 default;
    server_name _;
    return 444;
    access_log   off;
    }



说是header过大,关掉日志解决问题,这种乐观主义我是见识到了,呵呵:
http://www.blogjava.net/xiaomage234/archive/2012/07/17/383329.html


Header长度太长,咱能不能打一下nginx的header?
在Nginx里面取这个HEAD用到的是$http_head参数,Nginx里面需要小写:
http://gunner.me/archives/363
背景: 磁盘没空间了,du -sh ./var/spool/clientmqueue   2.8G    ./var/spool/clientmqueue
____________________________________________________________________
今天收到nagios报警邮件,其中一台server中的磁盘分区空间超过95%,登录到服务器查看

[root@hadoop-node-29 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5              19G   16G  2.8G  95% /var

到目录/var查看哪个目录中的文件最大

[root@hadoop-node-29 var]# du -sh *

找到是/var/spool目录占了很大空间,进入spool目录继续查看 找到是clientmqueue目录中的文件很多占了大部分空间。

删除所有文件
[root@hadoop-node-29 clientmqueue]# rm -rf *
结果返回-bash: /bin/rm: Argument list too long

换用命令find . -print|xargs rm  过了一段时间终于删除了所有文件

不过这种方法只是治标不治本的方法。

为什么var/spool/clientmqueue会产生大量的文件呢,查资料是因为cron执行时会将相关结果以mail方式发送到执行用户的帐号,可是当sendmail 沒有启动 那么所有信件就会暂存在这个目录中,此时就会出现这种情况。

治本的方法是在cron 任务中的后面加上 > /dev/null 2>&1

例如

* * * * * /etc/init.d/snmp_cron.sh > /dev/null 2>&1

参考http://blog.xuite.net/david.welltake/home/45865306-%2Fvar%2Fspool%2Fclientmqueue+%E4%BD%94%E7%94%A8%E7%A3%81%E7%A2%9F%E7%A9%BA%E9%96%93%E7%9A%84%E5%95%8F%E9%A1%8C+linux
背景:对/下的文件大小作统计但想排除一些文件夹。
想计算一下/tmp的总空间,但想排除/tmp//tmp/ssh-sdgAM28929
du -h /tmp --exclude=/tmp/ssh-sdgAM28929

看起来--exclude=/tmp/ssh-sdgAM28929并没有工作
--exclude=PATTERN 不是一个路径,我觉得你可以--exclude="ssh-sdgAM28929"


[root@localhost ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda6              15G   14G     0 100% /
/dev/sda7             743G   67G  639G  10% /data
/dev/sda3              19G  5.2G   13G  29% /usr
/dev/sda2              19G  4.4G   14G  25% /var
/dev/sda1             494M   22M  447M   5% /boot
tmpfs                 7.9G  125M  7.8G   2% /dev/shm
10.70.32.53:/upload   796G   38G  717G   6% /upload

du -sh /* --exclude=/data --exclude=/usr --exclude=/var --exclude=/boot --exclude=/upload
7.0M    /bin
8.0K    /convert
125M    /dev
139M    /etc
244M    /home
196M    /lib
20M     /lib64
4.0K    /logs
16K     /lost+found
8.0K    /media
8.0K    /misc
12K     /mnt
8.0K    /net
0       /opt
4.0K    /playRecord.php
0       /proc
428M    /root
31M     /sbin
8.0K    /selinux
8.0K    /srv
4.0K    /sync
0       /sys
15M     /tmp

背景:前些天在淘宝上的一台vps出现了宕机,转载如下:【阿里云】尊敬的XXX@qq.com:您的云服务器(120.206.54.108)出现宕机,阿里云正在进行宕机保护性迁移,恢复时会第一时间通知您,谢谢。您好,您的ECS本地磁盘实例i-258cfosv4发生了宕机迁移,请您注意尽快恢复数据恢复业务。【阿里云】
一个Linux服务是基于centos7的,居然宕机了,这种情况要么是阿里云水平不行,要不就是linux不稳定导致,不管那么多,但从坚如磐石来讲,还得是FreeBSD,像之前的像邮件服务器啥的磁盘管理来讲都是用FreeBSD,后因为FreeBSD人越来越少(到现在FreeBSD连筹集个项目都只筹集到一半的钱,发动不起来。)推广问题等,像基于linux人相对多一些,大家都跑linux上了(Linux更符合Web的端的webserver和DB性能的需求变化),回想当我刚毕业时接受的就是FreeBSD,于是搜索了一下FreeBSD,发现阿里云也卖FreeBSD,不求其高性能,求其稳定如磐石即可,是我现在的一个新的需求。
——————————————————————————————————————————————————————————————————————————

     阿里云貌似最近推出了FreeBSD镜像,这是我最喜欢的操作系统,个人看法比Linux好太多了。但是阿里云方面文档没有跟上,无任何挂载硬盘相关的操作说明,所以记录一下在阿里云FreeBSD镜像环境下挂载云磁盘的操作过程。

用dmesg查看云硬盘在/dev的设备号,在xen环境的linux里是xvdb1,FreeBSD下通常是xbd1,由于xbd1未按照freebsd标准分区格式化,所以,如直接mount /dev/xbd1 /opt会报错,Invalid augument什么的。
分区格式化,先初始化磁盘
dd if=/dev/zero of=/dev/xbd1 bs=1k count=1
fdisk -BI /dev/xbd1 (完事会出来xbd1s1)
disklabel -B -w -r /dev/xbd1s1 auto
newfs /dev/xbd1s1
mount /dev/xbd1s1 /opt
echo "/dev/xbd1s1     /opt            ufs     rw      1       1" >> /etc/fstab,中间用tab分割

完成
--------20150806修订--------
FreeBSD 10取消pkg_add的等命令,用pkg代替,pkg安装在GFW环境下比较靠谱,中间曾发现rrdtool被GFW屏蔽,无法通过ports编译安装。

转载自:http://slaytanic.blog.51cto.com/2057708/1679151

很久很久以前,一个叫AT&T贝尔实验室的家族生下了一个叫Unix的婴儿。随着Unix的成长,大家都对Unix特别喜爱。贝尔实验室非常骄傲的到处拿Unix摆显。一个叫Berkeley的少女被贝尔吸引,一夜风流过后,Berkeley怀了孕,生下了BSD。
Unix和BSD都逐渐长大。AT&T发现Unix非常能挣钱,但是BSD却专门帮助人们而仅仅收取点感谢费。这样BSD名声渐大,严重影响了Unix的业务。于是AT&T找到Berkeley说BSD不是你一个人的,我是BSD的父亲,BSD不能这么给人办事不收费用。
而Berkeley却不领AT&T的情,说BSD在自己的家里长大,完全是自己的孩子。AT&T翻脸了,把Berkeley告到法庭要取得部分监护权。
官司一打就是十年。BSD就是被折磨了十年。人生能有几个十年?十年中,社会发生了巨大的变革,互联网风靡世界,PC机逐渐成了人们的日常工具,人们开始使用一种叫手机的东西通信。中国开始改革开放。苏联开始崩溃。而BSD只能呆在校园里望着校外的世界潮涨潮落,云卷云舒。
随着AT&T把自己的亲生孩子卖给了Novell。Novell决定迅速结束这场官司。于是最终官司庭外和解。Berkeley退还了一些当年贝尔送给自己的礼物。BSD的兄弟Unix改名System V,此后几经转手,最终社会的风霜将他雕刻成一个高冷的人。如今你会在少数高档场所见到他冷俊的面孔。
自由了的BSD被Berkeley重新打扮一番后,把他叫到面前说:如今你已经长大,不能在妈妈的家里闲着了,该到社会上闯荡了。
BSD满含着热泪离开了Berkeley。开始了他的社会生活。
BSD遇到了一个叫Sun的富家小姐,BSD秉承了他爹的基因,跟Sun一夜风流后,Sun生下了Solaris。
BSD在PC上建立了一个家,并把自己改名自由BSD(FreeBSD)。来纪念自己如同蹲监狱的十年屈辱时光。
有人想把他请到各种场所做客,那些场合他被叫做NetBSD。以及人们从NetBSD装扮出来的OpenBSD。
FreeBSD经过发展,名声渐大,在一次宴会中遇到了淫荡公主(Slut Princess)苹果。他们一见生情,几经来往后,Apple生下了OS X。OS X出现在苹果的各种社交场所。后来OS X又生下了iOS。iOS这个女人秉承了她奶奶的美丽与淫荡。各种装逼耍酷的场所,她都会出现。
FreeBSD跟Apple交往后,变得越发淫荡风流。跟原来的穷小子不一样了,穿着时尚,装逼耍酷样样都行。吸引了社会上的一些大姑娘小媳妇跃跃欲试。从此过上了没羞没臊的幸福生活。

这是个故事 与事实不符的地方:
AT&T 之所以给别人源代码是因为司法部的垄断协议,其不准经营电脑业务。
官司打了四年而非十年,不过这四年正是个人电脑疯狂发展的时机。
AT&T的unix命名为system v是在官司之前,而非之后。因为它被起诉垄断拆解成八个公司,当然这时它又可以经营电脑业务了。
Sun根据bsd做出的系统开始叫SunOS。远在官司之前。后来,他与at&t合作用System iv做出Solaris 2.0。并把以前的sunOS命名为Solaris 1.0
at&t固执的维护unix版权使其丧失开发活力。system v几经转手停止开发。其它厂商根据它开发了自己的系统比如Sun的Solaris,HP的HP-UX,IBM的AIX

来自:tieba.baidu.com/p/3653259841

今天用SSH连接我的远程主机,出现了以下错误:
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

网上查了一下,用

rm -rf .ssh/known_hosts

删除主机列表就行了。

删除的是连接方的主机即可:
mv /root/.ssh/known_hosts /root/.ssh/known_hosts.bak

来自:http://blog.csdn.net/westsource/article/details/6636096



@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
b5:ea:d8:91:4e:98:b8:c7:af:55:c0:e4:68:ff:00:d3.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:104
RSA host key for 10.71.182.7* has changed and you have requested strict checking.
Host key verification failed.
背景:Nginx的断点上传这块涉及到一个创建散列目录的的情况,这块得从0-9,a-z,A-Z, 搜索了一下网上,用awk比较吃香。


________________________________________________________________________________



参考:http://blog.csdn.net/ghosc/article/details/5721178

awk如何输出A-Z ,网上高手很多:
不用麻烦awk了

这样就行了
那个echo {A..Z}够牛逼的~~





http://bbs.chinaunix.net/thread-1815653-1-1.html
/opt   主机额外安装软件所摆放的目录。默认是空的。 一般安装软件的时候,可以自己指定安装到这个目录下,便于查找和管理:
[root@localhost opt]# ls /opt
20120207         mysql-5.6.11  

/根空间太小大了,直接挪动到其它盘符(data目录大: 171G   39G  123G  24% /data),做个软链接:
/opt -> /data/backdata/opt
MegaCli-1.01.39-0.i386.rpm
[root@localhost ~]# rpm -qa|grep MegaCli
MegaCli-1.01.39-0
/opt/MegaRAID/MegaCli/MegaCli
/opt/MegaRAID/MegaCli/MegaCli64


/opt/MegaRAID/MegaCli/MegaCli64  -PDList -aALL   //查看硬盘信息
阅读全文
提问:我管理着一台多人共享的Linux服务器。我刚使用默认密码创建了一个新用户,但是我想用户在第一次登录时更换密码。有没有什么方法可以让他/她在下次登录时修改密码呢?
在多用户Linux环境中,标准实践是使用一个默认的随机密码创建一个用户账户。成功登录后,新用户自己改变默认密码。出于安全考虑,经常建议“强制”用户在第一次登录时修改密码来确保这个一次性使用的密码不会再被使用。
下面是如何强制用户在下次登录时修改他/她的密码。


每个Linux用户都关联这不同的密码相关配置和信息。比如,记录着上次密码更改的日期、最小/最大的修改密码的天数、密码何时过期等等。
一个叫chage的命令行工具可以访问并调整密码过期相关配置。你可以使用这个工具来强制用户在下次登录修改密码、
要查看特定用户的过期信息(比如:alice),运行下面的命令。注意的是除了你自己之外查看其他任何用户的密码信息都需要root权限。
$ sudo chage -l alice


强制用户修改密码
如果你想要强制用户去修改他/她的密码,使用下面的命令。
$ sudo chage -d0 <user-name>
原本“-d ”参数是用来设置密码的“年龄”(也就是上次修改密码起到1970/1/1起的天数)。因此“-d0”的意思是上次密码修改的时间是1970/1/1,这就让当前的密码过期了,也就强制让他在下次登录的时候修改密码了。
另外一个过期当前密码的方式是用passwd命令。
$ sudo passwd -e <user-name>
上面的命令和“chage -d0”作用一样,让当前用户的密码立即过期。
现在检查用户的信息,你会发现:


当你再次登录时候,你会被要求修改密码。你会在修改前被要求再验证一次当前密码。
摘录:http://m.toutiao.com/i6210940210904826370/?tt_from=android_share&iid=3151331199&app=news_article&utm_medium=toutiao_android&utm_campaign=client_share
用 screenfetch 和 linux:

http://m.toutiao.com/i6212380828834447873/?tt_from=android_share&iid=3188867042&app=news_article&utm_medium=toutiao_android&utm_campaign=client_share




来自:http://os.51cto.com/art/201511/496107.htm
Core Dump是什么?
Core Dump乍听之下很抽象。
当程序运行的过程中异常终止或崩溃,操作系统会将程序当时的内存状态记录下来,保存在一个文件中,这种行为就叫做Core Dump(中文有的翻译成“核心转储”)。
我们可以认为Core Dump是“内存快照”,但实际上,除了内存信息之外,还有些关键的程序运行状态也会同时dump下来,例如寄存器信息(包括程序指针、栈指针等)、内存管理信息、其他处理器和操作系统状态和信息。
Core Dump 对于编程人员诊断和调试程序是非常有帮助的,因为对于有些程序错误是很难重现的,例如指针异常,而 Core Dump 文件可以再现程序出错时的情景。
在半导体作为电脑内存材料之前,电脑内存使用的是 磁芯内存(Magnetic Core Memory),Core Dump 中的 Core 沿用了磁芯内存的 Core 表达。图为磁芯内存的一个单元,来自 Wikipedia.


在 APUE 一书中作者有句话这样写的:
Because the file is named core, it shows how long this feature has been part of the Unix System.
这里的Core就是沿用的是早期电脑磁芯内存中的表达,也能看出Unix系统Core Dump机制的悠久历史。
Dump 指的是拷贝一种存储介质中的部分内容到另一个存储介质,或者将内容打印、显示或者其它输出设备。dump 出来的内容是格式化的,可以使用一些工具来解析它。
现代操作系统中,用Core Dump表示当程序异常终止或崩溃时,将进程此时的内存中的内容拷贝到磁盘文件中存储,以方便编程人员调试。
如何开启Core Dump?
临时开启Core Dump,并且设置大小不受限:
命令行输入: ulimit -c unlimited
要永久打开Core Dump并且使之大小不受限,网上说有两种方法:
1. 打开 core dump 功能
在终端中输入命令 ulimit -c ,输出的结果为 0,说明默认是关闭 core dump 的,即当程序异常终止时,也不会生成 core dump 文件。
我们可以使用命令 ulimit -c unlimited 来开启 core dump 功能,并且不限制 core dump 文件的大小; 如果需要限制文件的大小,将 unlimited 改成你想生成 core 文件最大的大小,注意单位为 blocks(KB)。
用上面命令只会对当前的终端环境有效,如果想需要永久生效,可以修改文件 /etc/security/limits.conf文件。增加一行:
# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#<domain> <type> <item> <value> * soft core unlimited
2. 在/etc/profile中加入 ulimit -c unlimited
我试了以上两种方法,但是输入
ulimit -c
输出结果始终是0。
后来自己想了一种方法,在Ubuntu下可以:
编辑 .bashrc 文件:
vi ~/.bashrc
添加:
ulimit -c unlimited
保存,退出。
source ~/.bashrc
source命令使修改立即生效。
来自:http://m.toutiao.com/i6215077284911514113/?tt_from=android_share&iid=3222127616&app=news_article&utm_medium=toutiao_android&utm_campaign=client_share
你曾经想过用安全 shell 挂载一个远程文件系统到本地吗?如果有的话,SSHfs 也许就是你所需要的。它通过使用 SSH 和 Fuse(LCTT 译注:Filesystem in Userspace,用户态文件系统,是 Linux 中用于挂载某些网络空间,如 SSH,到本地文件系统的模块) 允许你挂载远程计算机(或者服务器)到本地。


准备
在使用 SSHfs 挂载之前,需要进行一些设置 - 在你的系统上安装 SSHfs 以及 fuse 软件包。你还需要为 fuse 创建一个组,添加用户到组,并创建远程文件系统将会驻留的目录。
要在 Ubuntu Linux 上安装两个软件包,只需要在终端窗口输入以下命令:
sudo apt-get install sshfs fuse


如果你使用的不是 Ubuntu,那就在你的发行版软件包管理器中搜索软件包名称。最好搜索和 fuse 或 SSHfs 相关的关键字,因为取决于你运行的系统,软件包名称可能稍微有些不同。
在你的系统上安装完软件包之后,就该创建好 fuse 组了。在你安装 fuse 的时候,应该会在你的系统上创建一个组。如果没有的话,在终端窗口中输入以下命令以便在你的 Linux 系统中创建组:
sudo groupadd fuse
添加了组之后,把你的用户添加到这个组。
sudo gpasswd -a "$USER" fuse
别担心上面命令的 $USER。shell 会自动用你自己的用户名替换。处理了和组相关的工作之后,就是时候创建要挂载远程文件的目录了。
mkdir ~/remote_folder
在你的系统上创建了本地目录之后,就可以通过 SSHfs 挂载远程文件系统了。
挂载远程文件系统
要在你的机器上挂载远程文件系统,你需要在终端窗口中输入一段较长的命令。
sshfs -o idmap=user username@ip.address:/remote/file/system/ ~/remote
注意: 也可以通过 SSH 密钥文件挂载 SSHfs 文件系统。只需要在上面的命中用sshfs -o IdentityFile=~/.ssh/keyfile, 替换sshfs -o idmap=user部分。
输入这个命令之后,会提示你输入远程用户的密码。如果登录成功了,你的远程文件系统就会被挂载到之前创建的 ~/remote_folder目录。


使用完了你的远程文件系统,想要卸载它?容易吗?只需要在终端输入下面的命令:
sudo umount ~/remote_folder
这个简单的命令会断开远程连接同时清空 remote_folder 目录。
总结
在 Linux 上有很多工具可以用于访问远程文件并挂载到本地。但是如之前所说,如果有的话,也只有很少的工具能充分利用 SSH 的强大功能。我希望在这篇指南的帮助下,也能认识到 SSHfs 是一个多么强大的工具。
来自:http://m.toutiao.com/i6217571222784311809/?tt_from=android_share&iid=3250063669&app=news_article&utm_medium=toutiao_android&utm_campaign=client_share
背景: 我经常在命令行中切换 shell。是否有一个快速简便的方法来找出我当前正在使用的 shell 呢?此外,我怎么能找到当前 shell 的版本?

其一,一个名为 "$$" 的特殊参数表示当前你正在运行的 shell 实例的 PID。此参数是只读的,不能被修改。所以,下面的命令也将显示你正在运行的 shell 的名字:
$ ps -p $$
PID TTY          TIME CMD
21666 pts/4    00:00:00 bash
上述命令可在所有可用的 shell 中工作。
如果你不使用 csh,找到当前使用的 shell 的另外一个办法是使用特殊参数 “$0” ,它表示当前正在运行的 shell 或 shell 脚本的名称。这是 Bash 的一个特殊参数,但也可用在其他 shell 中,如 sh、zsh、tcsh 或 dash。使用 echo 命令可以查看你目前正在使用的 shell 的名称。
$ echo $0
bash
不要被一个叫做 $SHELL 的单独的环境变量所迷惑,它被设置为你的默认 shell 的完整路径。因此,这个变量并不一定指向你当前使用的 shell。例如,即使你在终端中调用不同的 shell,$SHELL 也保持不变。
$ echo $SHELL

/bin/shell


因此,找出当前的shell,你应该使用 $$ 或 $0,但不是 $SHELL。
找出当前 Shell 的版本
一旦你知道你使用的是哪个 shell,你可能想知道此 shell 的版本。为此,在命令行中输入 shell 并在后面加上 “--version” 参数可以查看版本信息。例如:
对于bashshell:
$ bash --version

GNU bash, version 4.3.30(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
对于zshshell:
$ zsh --version

zsh 5.0.7 (x86_64-pc-linux-gnu)
对于tcshshell: $ tcsh --version
tcsh 6.18.01 (Astron) 2012-02-14 (x86_64-unknown-linux) options wide,nls,dl,al,kan,rh,nd,color,filec
对于某些 shell,你还可以使用 shell 特定的变量(例如,$BASHVERSION 或 $ZSHVERSION)。
$ echo $BASH_VERSION

4.3.8(1)-release

摘自:http://m.toutiao.com/i6221626512869687810/?tt_from=android_share&iid=3283494589&app=news_article&utm_medium=toutiao_android&utm_campaign=client_share
centos7 如何刷新本地的DNS缓存
1)方法一:
[root@fl2 ~]# ping dl.z.com
ping: unknown host dl.z.com
[root@fl2 ~]# /etc/rc.d/init.d/nscd restart
-bash: /etc/rc.d/init.d/nscd: No such file or directory
[root@fl2 ~]# /etc/rc.d/nscd restart
-bash: /etc/rc.d/nscd: No such file or directory
[root@fl2 ~]#
centos7 dns

2)方法二:
centos 7 已经用systemd 了,
试试 systemctl restart nscd。

From:http://segmentfault.com/q/1010000002925549/a-1020000002925718
分页: 23/40 第一页 上页 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 下页 最后页 [ 显示模式: 摘要 | 列表 ]