exit
exit
There are stopped jobs.

原因:有vim后以Ctrl+z退出挂起的任务,运行fg后,直接退出后即可。

来源:https://unix.stackexchange.com/questions/116959/there-are-stopped-jobs-on-bash-exit
dig pypi.doubanio.com @202.106.0.20
202.106.0.20

我们平时用的最多的最常见的是反向代理。反向代理想必都会配置的,有不会的可以到本博客里面搜索下,有相关文档。 那么nginx的正向代理是如何配置的呢?

server {
  listen 8090;
  location / {
      resolver 218.85.157.99 218.85.152.99;
      resolver_timeout 30s;
      proxy_pass http://$host$request_uri;
  }
  access_log  /data/httplogs/proxy-$host-aceess.log;      
}

server {
listen 8090;
location / {
resolver 218.85.157.99 218.85.152.99;
resolver_timeout 30s;
proxy_pass http://$host$request_uri;
}
access_log  /data/httplogs/proxy-$host-aceess.log;      
}
就这么简单哈。
测试:
http://www.ttlsa.com:8090
resolver指令
语法: resolver address ... [valid=time];
默认值: —
配置段: http, server, location
配置DNS服务器IP地址。可以指定多个,以轮询方式请求。
nginx会缓存解析的结果。默认情况下,缓存时间是名字解析响应中的TTL字段的值,可以通过valid参数更改。
resolver_timeout指令
语法: resolver_timeout time;
默认值: resolver_timeout 30s;
配置段: http, server, location
解析超时时间。
如需转载请注明出处:http://www.ttlsa.com/html/3287.html


nginx正向代理加上DNSIP及超时时间在upstream中的使用方法:
https://www.nginx.com/resources/wiki/modules/domain_resolve/

http {
        resolver 8.8.8.8;
  resolver_timeout 10s;

        upstream backend {
                jdomain  www.baidu.com;
                #keepalive 10;
  }
  server {
    listen       8080;

    location / {
      proxy_pass http://backend;
    }
        }
}
Linux下处理JSON的命令行工具:jq---安装:
JSON是前端编程经常用到的格式。Linux下也有处理处理JSON的神器:jq。
       对于JSON格式而言,jq就像sed/awk/grep这些神器一样的方便,而且,jq没有乱七八糟的依赖,只需要一个binary文件jq,就足矣。
       本篇中,我们来看一下jq的安装。
1、执行yum list| grep jq查看是否有jq安装包。
2、若有,直接安装jq,执行命令:yum -y install jq。
安装完毕后,直接在命令行输入:jq,然后回车,看到以下信息说明安装完毕。
3.使用方法:
(1)简单使用: curl "http://127.0.0.1:8001/apis"|jq .
(2)获取显示Json里面的串及值:curl http://127.0.0.1:8001/apis|jq '.data[1].name'    得到返回:apiadmin

参考:http://blog.csdn.net/sunny_much/article/details/50668871

简单使用方式:
1,json文件友好显示
cat jsonfile | path_to_jq/jq .  

2,获取json某key的value
cat jsonfile | path_to_jq/jq ".key"  

3.较为复杂的结构里面的数据访问:
curl "http://127.0.0.1:8001/apis"|jq .data[0].upstream_url
"http://address.v1.service/address"
curl "http://127.0.0.1:8001/apis"|jq .total
1

curl "http://127.0.0.1:8001/apis"|jq .data[0].name
"address-service"

curl "http://127.0.0.1:8001/apis"|jq .data[0].hosts
[
  "address.mydomain.com"
]

curl "http://127.0.0.1:8001/apis"|jq .data[0].hosts[0]
"address.mydomain.com"

整个返回的结构体情况如下所示:
现象:点击网址栏里面的,翻译出现:无法翻译此网页内容。
步骤:得先装这个插件,再就是插件的翻译URL地址得能访问。
1、首先我们得先确定你安装了这个翻译插件,还没有安装或者不会的可以参考:http://www.pc6.com/infoview/Article_72630.html
2、安装好之后,还是无法翻译的,那么就要修改host的了:
(1)大家可以打开“我的电脑”然后进到C:/Windows/System32/drivers/etc/hosts,记得以记事本方式打开hosts文件
(2)在加入如下两行(IP地址与网址之间必须有一空格):点击“文件”→“保存”
203.208.46.145 translate.google.com
203.208.46.145 translate.googleapis.com

参考:
https://www.kafan.cn/edu/84094646.html
http://www.pc6.com/infoview/Article_72630.html
================================================================================
简介:
Google 翻译:谷歌浏览器翻译扩展工具 Google Translate for Chrome,Google Chrome的翻译扩展工具,由Google官方发布。安装后,会在你的Chrome浏览器菜单栏中添加一个按钮,你可以方便的在任何时候点击翻译你当前正在访问的页面。本扩展能自动侦测你正在访问的页面语言和Chrome浏览器的界面语言,并根据这两种语言进行互译,你也可以选择其它语言。
DownLoad:http://down.tech.sina.com.cn/content/46326.html
官方:https://chrome.google.com/webstore/detail/google-translate/aapbdbdomjkkjkaonfhkkikfgjllcleb/related?hl=zh-CN
yum remove mysql时出现移除perl-DBD-MySQL的情况原因排查:
根本原因是之前的CentOS6.X里默认安装了mysql-libs,而在CentOS的7.x里,先安装了自己制作的Mysql包,于是出现:
1)CentOS6.X里需要:
rpm -q perl-DBD-MySQL --requires|grep libmysqlclient
libmysqlclient.so.16()(64bit)  
libmysqlclient.so.16(libmysqlclient_16)(64bit)  
2)CentOS7.X里需要:
rpm -q perl-DBD-MySQL --requires|grep libmysqlclient
libmysqlclient.so.18()(64bit)
libmysqlclient.so.18(libmysqlclient_18)(64bit)

而这两个不同版本的MySQL自制的包均分别提供了libmysqlclient.so.16@CentOS6.X和libmysqlclient.so.18@CentOS7.X(7里叫:mariadb-libs),且加入到动态链接库的cat /etc/ld.so.conf.d/mysql.conf,
/usr/local/mysql/lib,并ldconfig生效了,于是这个perl-DBD-MySQL就和它建立起了依赖,导致卸载Mysql@CentOS7.x时,因为perl-DBD-MySQL依赖mysql的libmysqlclient.so.18,于是出现被一同卸载的情况。怎么办@CentOS7.X里装perl-DBD-MySQL,先卸载Mysql一并把perl-DBD-MySQL卸载了,yum remove mysql -y,然后,yumdownloader mysql-libs,它会下载:mariadb-libs-5.5.56-2.el7.x86_64.rpm,rpm -ihv mariadb-libs-5.5.56-2.el7.x86_64.rpm,以解决直接yum install perl-DBD-MySQL时会出现安装:mysql-5.7.12-171123111505的情况,装好后,再安装yum install perl-DBD-MySQL ,也就不会安装mysql-5.7.12-171123111505了,因为链接已经在mariadb-libs-5.5.56有了,不需要mysql-5.7.12-171123111505来补充了。

一)CentOS7上安装perl-DBD-MySQL:
[root@ha_mysql-mha_manager_bj_szq_10_70_36_177 ~]# yum remove mysql
Loaded plugins: langpacks
Resolving Dependencies
--> Running transaction check
---> Package mysql.x86_64 0:5.7.12-171123111505.el7.centos will be erased
--> Processing Dependency: libmysqlclient.so.18()(64bit) for package: perl-DBD-MySQL-4.023-5.el7.x86_64
--> Processing Dependency: libmysqlclient.so.18(libmysqlclient_18)(64bit) for package: perl-DBD-MySQL-4.023-5.el7.x86_64
--> Running transaction check
---> Package perl-DBD-MySQL.x86_64 0:4.023-5.el7 will be erased
--> Finished Dependency Resolution

libmysqlclient.so.18被perl-DBD-MySQL需要:
ls -lart /usr/local/mysql/lib/libmysqlclient.so.18
/usr/local/mysql/lib/libmysqlclient.so.18 -> /usr/local/mysql/lib/libmysqlclient.so.18.1.0
rpm -qf /usr/local/mysql/lib/libmysqlclient.so.18.1.0
mysql-5.7.12-171123111505.el7.centos.x86_64

ldconfig -p|grep libmysqlclient.so.18
        libmysqlclient.so.18 (libc6,x86-64) => /usr/local/mysql/lib/libmysqlclient.so.18

验证,如果没有咱自己打的包的情况,理论上perl-DBD-MySQL也是和CentOS6.x一样需要这个mysql-libs的:
yumdownloader mysql-libs
rpm -qpl  mariadb-libs-5.5.56-2.el7.x86_64.rpm|grep libmysqlclient.so
/usr/lib64/mysql/libmysqlclient.so.18            #得证!!
/usr/lib64/mysql/libmysqlclient.so.18.0.0  


二)CentOS6.x Ver:
ldconfig -p|grep libmysqlclient.so
        libmysqlclient.so.16 (libc6,x86-64) => /usr/lib64/mysql/libmysqlclient.so.16
rpm -qf /usr/lib64/mysql/libmysqlclient.so.16
mysql-libs-5.1.73-7.el6.x86_64

[root@ha_mysql-mha-manager_bj_sjs_10_71_182_246 ~]验证依赖:
yum remove mysql-libs
perl-DBD-MySQL  x86_64  4.013-3.el6  @CentOS-Base
背景:有时操作一些命令出现问题,后来才发现,而如果把屏幕缓冲区设置大小变大,能够回看,有可能是一些”证据“,比如:挂载的NAS硬盘好的,一会 就不行了,这个会话的缓冲区大小设置大点能助于反查问题。

在使用SecureCRT操作设备时,默认的回滚行数为500行。可以通过打开[选项]->[会话选项]->[Terminal]->[Emulation]-[Scrollback],默认为500行,可以最大调整到128000行。
设置所有呢?
在Option->Global Option->General->Default Session->Edit Default Settings...->Session Options - Default->Terminal->Emulation->Scrollback :Scrollback Buffer:128000 ,点Ok后,如果你的那个 服务器太多,得卡住没有响应,等一会就好了,全部修改了。

来自:http://blog.csdn.net/imxiangzi/article/details/7457703
https://www.cnblogs.com/lidabo/p/4169396.html
今天在使用冷备份文件重做从库时遇到一个报错,值得研究一下。
版本:MySQL5.6.27 
一、报错现象

dba:(none)> start slave;
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository
这个时候查看error.log:

2017-07-17 16:19:02 9022 [ERROR] Failed to open the relay log './tjtx-96-67-relay-bin.017814' (relay_log_pos 172582079).
2017-07-17 16:19:02 9022 [ERROR] Could not find target log file mentioned in relay log info in the index file './tjtx135-1-95-relay-bin.index' during relay log initialization.
2017-07-17 16:19:02 9022 [ERROR] Failed to initialize the master info structure
2017-07-17 16:19:02 9022 [Note] Check error log for additional messages. You will not be able to start replication until the issue is resolved and the server restarted.
2017-07-17 16:19:02 9022 [Note] Event Scheduler: Loaded 0 events
2017-07-17 16:19:02 9022 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.6.27-log'  socket: '/tmp/mysql.sock'  port: 3306  MySQL Community Server (GPL)
2017-07-17 16:19:06 9022 [ERROR] Slave SQL: Slave failed to initialize relay log info structure from the repository, Error_code: 1872
从报错上看,意思是启动slave时,使用repository中信息初始化relay log结构失败了。为什么失败了?原来是从tjtx135-1-95-relay-bin.index文件中找不到tjtx-96-67-relay-bin.017814文件。到这里,答案就很清楚了,由于我使用的是冷备份文件恢复的实例,在mysql库中的slave_relay_log_info表中依然保留之前relay_log的信息,所以导致启动slave报错。

那如何解决呢?先来简单的了解MySQL Relay log的基础知识:

二、MySQL Relay log介绍

在MySQL复制结构下,Slave服务器会产生三种日志文件,用来保存主库的二进制日志事件以及relay log已执行到的位置和状态。

1、relay log 文件:由IO thread线程从主库读取的二进制日志事件组成,该日志被Slave上的SQL thread线程执行,从而实现数据的复制。

2、master info log:该文件保存slave连接master的状态以及配置信息,如用户名,密码,日志执行的位置等。在5.6版本之前,都是使用master.info文件,从5.6开始,通过在my.cnf  中配置 --master-info-repository=TABLE。这些信息会被写入mysql.slave_master_info 表中,代替原来的master.info文件了。

3、relay log info log:该文件保存slave上relay log的执行位置。在5.6版本之前,都是使用relay-log.info文件,从5.6开始,通过在my.cnf中配置 --relay-log-info-repository=TABLE,使用mysql.slave_relay_log_info表代替原来的文件。每次当slave上执行start slave时,就会读取该表中的位置信息。

新版本使用表来代替原来的文件,主要为了crash-safe replication,从而大大提高从库的可靠性。为了保证意外情况下从库的可靠性,mysql.slave_master_info和mysql.slave_relay_log_info表必须为事务性的表,从5.6.6起,这些表默认使用InnoDB存储引擎。在5.6.5及之前的版本默认使用MyISAM引擎,可用下面语句进行转换:

ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
【注意】不要试图手工的更新、插入、删除以上两个表的内容,以免出现意料不到的问题。

三、问题解决

通过上面的报错以及relay log介绍,很容易知道由于mysql.slave_relay_log_info表中保留了以前的复制信息,导致新从库启动时无法找到对应文件,那么我们清理掉该表中的记录不就可以了。再次提醒,不要手动删该表数据,MySQL已经提供工具给我们了:reset slave:

reset slave干的那些事:

1、删除slave_master_info ,slave_relay_log_info两个表中数据;
2、删除所有relay log文件,并重新创建新的relay log文件;
3、不会改变gtid_executed 或者 gtid_purged的值
下面解决问题:


dba:(none)> reset slave;
Query OK, 0 rows affected (0.00 sec)
1
dba:(none)> change master to ......
1
2
dba:(none)> start slave;
Query OK, 0 rows affected (0.00 sec)
到这里问题解决了。
来自:https://www.cnblogs.com/mysql-dba/p/7201513.html
【经验】:以后用冷备份恢复实例后,在启动slave前,先进行reset slave清空下以前的旧信息。

【参考资料】:https://dev.mysql.com/doc/refman/5.6/en/slave-logs.html
https://dev.mysql.com/doc/refman/5.6/en/reset-slave.html
现象:

现象:
mysql: [Warning] World-writable config file '/root/.my.cnf' is ignored.
解决Ok:
chmod 644 /root/.my.cnf  就好了。

参考:http://blog.csdn.net/xeay123/article/details/44127951
经测试,一是一旦进入某个分支,即使断开SSH,再次进入此目录,分支不变。
二是Git merge 并不需要git commit -a"xx",而是在git merge dev,@master里,直接git push即可。
一)假如git merge dev,后,再git commit -am"git merge release2",提示领先1个提交。
1)#git commit -am"git merge release2"
位于分支 master
您的分支领先 'origin/master' 共 1 个提交。
  (使用 "git push" 来发布您的本地提交)
无文件要提交,干净的工作区

2)操作时的编号在:3fee86c
git reset --hard origin/master
HEAD 现在位于 3fee86c modified README.md deploy by jenkins

因为Merge并没有commit写上注释,其看GitLab的Log是:
modified README.md deploy by jenkins
xiangdong committed 23 minutes ago  3fee86c3

========================================
二)正常操作如下@master:
git merge dev
更新 c9cd0f9..3fee86c
Fast-forward
README.md | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)

git status
位于分支 master
您的分支领先 'origin/master' 共 5 个提交。
  (使用 "git push" 来发布您的本地提交)
无文件要提交,干净的工作区

git push
/home/git/gitlab-shell/lib/gitlab_shell.rb:146: warning: Insecure world writable dir /root in PATH, mode 040777
Total 0 (delta 0), reused 0 (delta 0)
To git@gitlab.boosh.com.cn:irdcdev/iot.***.com.git
   c9cd0f9..3fee86c  master -> master

warning: Insecure world writable dir /root in PATH, mode 040777:
这个提示是说,给/usr/local 这个文件777的权限太大,不安全。 改为775,就没有这个提示了。是指在GitServer的权限不对,在GitServer的服务器里配置,
chmod 550 /root



在GitServer上对/root权限作出修改后,再次提交GitServer就不报错了:
git commit -m"test deploy" README.md
[master 9718db7] test deploy
1 file changed, 1 insertion(+)
#git push                            
对象计数中: 3, 完成.
压缩对象中: 100% (3/3), 完成.
写入对象中: 100% (3/3), 280 bytes | 0 bytes/s, 完成.
Total 3 (delta 2), reused 0 (delta 0)
To git@gitlab.boosh.com.cn:irdcdev/iot.***.com.git
   602b041..9718db7  master -> master

顺带看了一下Git的gitlab-shell配置文件,没懂,摘抄如下:
vi +146 /home/git/gitlab-shell/lib/gitlab_shell.rb
145       'HOME' => ENV['HOME'],
146       'PATH' => ENV['PATH'],                                                        
147       'LD_LIBRARY_PATH' => ENV['LD_LIBRARY_PATH'],
148       'LANG' => ENV['LANG'],
149       'GL_ID' => @key_id,
150       'GL_PROTOCOL' => GL_PROTOCOL
151     }

来自:http://www.cnblogs.com/tanglimei/p/5010239.html
现象:git checkout dev,出现,error: pathspec 'dev' did not match any file(s) known to git.
阅读全文
How does netcat know if a UDP port is open?  From:https://unix.stackexchange.com/questions/235830/how-does-netcat-know-if-a-udp-port-is-open

软件下载地址-------http://down.51cto.com/data/1982508
解压密码:zerosecurity
  放到:C:\Windows\System32下面,
download:

因为telnet走的是tcp协议,DNS可能是UDP,探测UDP端口通不通,使用如下参数:
Linux:
nc -vuz 202.106.0.20 53
Connection to 202.106.0.20 53 port [udp/domain] succeeded!
nc -vuz 115.182.218.210 53
Connection to 115.182.218.210 53 port [udp/domain] succeeded!
Window:
http://blog.csdn.net/iw1210/article/details/51603772
Nc和NetCat好像有些不一样,这个:http://blog.csdn.net/xysoul/article/details/52270149
用nc -v -z -u 192.168.0.25 1-100  #这是扫描1到00间的UDP端口
D:\Program Files\curl_wget_tail>nc -v -z -u 115.182.218.210 50-54
115.182.218.210: 反向连接查询主机: h_errno 11004: 无数据
(UNKNOWN) [115.182.218.210] 54 (?) 打开
(UNKNOWN) [115.182.218.210] 53 (?) 打开
(UNKNOWN) [115.182.218.210] 52 (?) 打开
(UNKNOWN) [115.182.218.210] 51 (?) 打开
(UNKNOWN) [115.182.218.210] 50 (?) 打开
用NC自己创建一个UDP的侦听器,From:https://serverfault.com/questions/773110/make-netcat-listen-for-multiple-udp-packets
nc -l -u -p 1234

DNSServer的两个端口都开了的:
netstat -atlunp|grep 53
tcp        0      0 0.0.0.0:53                  0.0.0.0:*                   LISTEN      34933/dnsmasq              
udp        0      0 0.0.0.0:53                  0.0.0.0:*                               34933/dnsmasq  


Windows 下,DNS的UDP端口在53端口存在,和58不存的返回对比:
C:\Users\Administrator>nc -vuz 202.106.0.20 53
gjjline.bta.net.cn [202.106.0.20] 53 (domain) 打开
没有的返回:
C:\Users\Administrator>nc -vuz 202.106.0.20 58
gjjline.bta.net.cn [202.106.0.20] 58 (?) 打开
Telnet其同样的端口是TCP,也没返回,但是用dig解释是OK的,说明其打开的是53的UDP端口:
像上面这个IP只是UDP,用Telnet其TCP53就没有返回,如下:
C:\Users\Administrator>telnet 202.106.0.20 53
正在连接202.106.0.20...无法打开到主机的连接。 在端口 53: 连接失败

windows server 2012 R2下运行dig和nslookup查看cdn是否配置生效,Window Server 2012 R2 下安装 dig 命令后查看DNS是否网路53tcp/udp口生效的检测方法:
http://jackxiang.com/post/8776/
--------------------------------------------------------------------
阅读全文
git version 2.7.4在提交时出现 push.default 警告问题。
两步解决:
步骤一:git config --global push.default simple
步骤二:git push -u origin master  #第一次,或:git push -u origin devel
步骤三:后再直接执行 git push 就可以了。


新建立分支后及时上面设置还是会报错怎么办?如下:
#git push
fatal: 当前分支 release1 没有对应的上游分支。
为推送当前分支并建立与远程上游的跟踪,使用

    git push --set-upstream origin release1

git config -l|grep simple
push.default=simple

按它提示的设置一下呢?就好了,如下:

git push --set-upstream origin release1
Total 0 (delta 0), reused 0 (delta 0)
remote:
remote: To create a merge request for release1, visit:
.....
remote:
To git@gitlab.xxx.com.cn:devel/iot.lewo.com.git
* [new branch]      release1 -> release1
分支 release1 设置为跟踪来自 origin 的远程分支 release1。

在merge后,其并没有啥状态不一样的,因为没有冲突啥的,Merge后,以及提交后的一个对比:
Merge后:
#git status
位于分支 release1
无文件要提交,干净的工作区
提交Merge到GitServer后(git push --set-upstream origin release1):
#git status
位于分支 release1
您的分支与上游分支 'origin/release1' 一致。
无文件要提交,干净的工作区

=====================实践如下======================


git提交时,出现问题如下:
#git push origin/devel
warning: push.default 尚未设置,它的默认值在 Git 2.0 已从 'matching'
变更为 'simple'。若要不再显示本信息并保持传统习惯,进行如下设置:

  git config --global push.default matching

若要不再显示本信息并从现在开始采用新的使用习惯,设置:

  git config --global push.default simple

当 push.default 设置为 'matching' 后,git 将推送和远程同名的所有
本地分支。

从 Git 2.0 开始,Git 默认采用更为保守的 'simple' 模式,只推送当前
分支到远程关联的同名分支,即 'git push' 推送当前分支。

参见 'git help config' 并查找 'push.default' 以获取更多信息。
('simple' 模式由 Git 1.7.11 版本引入。如果您有时要使用老版本的 Git,
为保持兼容,请用 'current' 代替 'simple')

fatal: 'origin/devel' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
interactive_timeout :连接空闲超时时间。与服务器端无交互状态的连接,直到被服务器端强制关闭而等待的时间。
    interactive_timeout和wait_timeout意义虽然相同,但是有使用对象有本质的区别。interactive_timeout针对交互式连接(比如通过mysql客户端连接数据库),wait_timeout针对非交互式连接(比如一般在PHP中使用PDO连接数据库,当然你可以设置CLIENT_INTERACTIVE选项来改变)。所谓的交互式连接,即在mysql_real_connect()函数中使用了CLIENT_INTERACTIVE选项。
wait_timeout:连接空闲超时时间。与服务器端无交互状态的连接,直到被服务器端强制关闭而等待的时间。可以认为是服务器端连接空闲的时间,空闲超过这个时间将自动关闭。

交互连接:
interactive_timeout 需在mysql_connect()设置CLIENT_INTERACTIVE选项后起作用,并被赋值为wait_timeout;  #Mysql自己的客户端mysql命令。
mysql>set global wait_timeout = 60; 对当前交互链接有效; (由于mysql的BUG所有这边必须加global)
mysql>set global interactive_timeout = 60; 对后续起的交互链接有效;


解决MySQL server has gone away
应用程序(比如PHP)长时间的执行批量的MYSQL语句。最常见的就是采集或者新旧数据转化。
解决方案:
在my.cnf文件中添加或者修改以下两个变量:
wait_timeout=2880000
interactive_timeout = 2880000
关于两个变量的具体说明可以google或者看官方手册。如果不能修改my.cnf,则可以在连接数据库的时候设置CLIENT_INTERACTIVE,比如:
sql = "set interactive_timeout=24*3600";
mysql_real_query(...)

wait_timeout过大有弊端,其体现就是MySQL里大量的SLEEP进程无法及时释放,拖累系统性能,不过也不能把这个指设置的过小,否则你可能会遭遇到“MySQL has gone away”之类的问题,通常来说,我觉得把wait_timeout设置为10是个不错的选择,但某些情况下可能也会出问题,比如说有一个CRON脚本,其中两次SQL查询的间隔时间大于10秒的话,那么这个设置就有问题了(当然,这也不是不能解决的问题,你可以在程序里时不时mysql_ping一下,以便服务器知道你还活着,重新计算wait_timeout时间)

本质:
变量wait_timeout:服务器关闭非交互连接之前等待活动的秒数。也就是说你PHP获取一次数据后作计算了,并没有释放Mysql连接句柄,而你处理完后,继续获取数据,这个中间等待的秒数。  为了防止出现这个问题,用了mysql_ping:https://mo2g.com/view/128/
问题:这个秒数,DBA一般写10秒,能否突破和Mysql的Client一样,让它的值和interactive_timeout一样呢?

From:http://www.04007.cn/article/292.html
============================================================================================
总之,Mysql的原生客户端,在设置其wait_timeout的值时不受全局的设置限制,均等于全局(/etc/my.cnf)interactive_timeout的值,而PHP则并不改变全局的值,而是里面配置wait_timeout多少,此次连接就是多少,当然,也提供了类似Mysql自带客户端的参数。
阅读全文
背景:MHA里面有的LVS有兄弟用这样一句,也不会LVS,好像是用来检测Mysql的进程否还活着的Shell,vrrp_script chk_mysqld { script "killall -0 mysqld && exit 0 || exit 1"。这句是否完备,实践发现如果对于多进程模型,可能并不完备,如下实践。

后台服务需要不间断运行,意外退出后,需要将其重新拉起。常常可以通过向进程发送信号0,然后根据返回值来判断一个进程是否存在。比如进程名字为A,那么
exsit="killall -0 A;echo $?"
exsit为0就表示进程A存在,否则表示不存在。
然而,当有多个进程名字都是A的时候,只有在全部名字为A的进程都退出后,exsit才非0,所以这种监控方法并不太适合多进程环境(为了负载均衡,服务器常常采用多进程)。

我们来看例子。
testbin.c

make testbin
g++     testbin.cpp   -o testbin

然后我们运行他。
     1.启动父子总共5个进程。
./testbin
Start.....
summer 42187 start.......
summer 42186 start.......
summer 42185 start.......
summer 42184 start.......

2.发送killall -0
killall -0 testbin && echo 0 || echo 1          
0

发现有进程接收了信号

3..杀掉一个子进程
ps aux|grep testbin
root     45125  0.0  0.1  11880  1048 pts/0    S+   10:52   0:00 ./testbin
root     45126  0.0  0.0  11748   392 pts/0    S+   10:52   0:00 ./testbin
root     45127  0.0  0.0  11880   400 pts/0    S+   10:52   0:00 ./testbin
root     45128  0.0  0.0  11880   400 pts/0    S+   10:52   0:00 ./testbin
root     45129  0.0  0.0  11880   400 pts/0    S+   10:52   0:00 ./testbin

kill -s 9 PID
----------------
kill -s 9 45125
kill -s 9 45126

kill -s 9 45129
killall -0 testbin && echo 0 || echo 1
0

killall -0 testbin && echo 0 || echo 1
0

最后还剩下一个进程了:
ps aux|grep testbin                    
root     45128  0.0  0.0  11880   400 pts/0    S    10:52   0:00 ./testbin
killall -0 testbin && echo 0 || echo 1
0


注意此时这个子进程成了僵尸进程。虽然现在只有4个进程,但是killall -0发出的信号仍然被接收,所以返回0.再杀一个,只剩3个所以仍然又能进程接收相关信号,返回0.

4..killall杀掉所有的父子进程
kill -s 9 45128

此时没有进程接收信号,返回1.
killall -0 testbin && echo 0 || echo 1
testbin: no process killed
1


实践源来自:http://blog.csdn.net/wjj547670933/article/details/44535761
来自:https://www.zhihu.com/question/20019419
The -u tells Git to remember the parameters, so that next time we can simply run git push and Git will know what to do.相当于第一次串门的时候你登了个记办了个vip。。以后再来就知道是你来了。不用脱裤子搜身了

链接:https://www.zhihu.com/question/20019419/answer/80590142

http://m.blog.csdn.net/shen_gan/article/details/8167715
由于git的index文件出错。

需要删除.git/index文件,

然后运行git reset,重新生成index文件。
git reset还可以删除已经commit,但未push上去的信息。

From:https://my.oschina.net/dyxp/blog/380642
FreeBSD11.1好像不是这样的,清空/root/.bash_history没有用:在 /root/.history里,不是.bash_history。
  1000  1:10    mysql -S /tmp/mysql.sock
  1002  1:26    vi /root/.bash_history

history命令的記錄如何刪除?

1、修改/etc/profile將HISTSIZE=1000改成0或1

清除用戶home路徑下.bash_history

2、立即清空裏的history當前曆史命令的記錄

history -c

3、bash執行命令時不是馬上把命令名稱寫入history文件的,而是存放在內部的buffer中,等bash退出時會一並寫入。

不過,可以調用'history -w'命令要求bash立即更新history文件。

history -w
分页: 1/197 第一页 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 下页 最后页 [ 显示模式: 摘要 | 列表 ]