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
根本原因是之前的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
镁着火时,可以采用的灭火方法是用沙子掩埋:
38℃-40℃是镁的燃点,燃烧的镁温度很高(3000度,足以点燃树木枯树枝),用水来灭火的话会发生如下反应,使燃烧更旺
Mg+2H2O=Mg(OH)2+H2↑
2H2+O2=2H2O
也不能用二氧化碳,因为镁在二氧化碳中也会燃烧,方程如下,2Mg+CO2==2MgO+C
在空气中,
2Mg+O2=点燃=2MgO,3Mg+2N2=点燃=2Mg3N2,2Mg+CO2=点燃=2MgO+C.
38℃-40℃是镁的燃点,燃烧的镁温度很高(3000度,足以点燃树木枯树枝),用水来灭火的话会发生如下反应,使燃烧更旺
Mg+2H2O=Mg(OH)2+H2↑
2H2+O2=2H2O
也不能用二氧化碳,因为镁在二氧化碳中也会燃烧,方程如下,2Mg+CO2==2MgO+C
在空气中,
2Mg+O2=点燃=2MgO,3Mg+2N2=点燃=2Mg3N2,2Mg+CO2=点燃=2MgO+C.
背景:有时操作一些命令出现问题,后来才发现,而如果把屏幕缓冲区设置大小变大,能够回看,有可能是一些”证据“,比如:挂载的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
在使用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
Q:在excel中输入的手机号码 然后打印的时候打出的不是完整的手机号,比如手机号是10000000000的话 打出的就是1.00E+10的字样 请问这是为什么啊 应该如何设置,已经尝试在手机号码的那一竖栏的单元格的设置单元格格式的选项里点了 文本模式了 仍然打不出完整的手机号码。
A:你的顺序不对,设置后得再输入:
法一,先将表格设为文本格式,然后再输入即可。
法二,或者在输入手机号码之前,输入一个英文状态下的‘ 就可以了!
来自:https://zhidao.baidu.com/question/118805241.html
想把手机号格式再变化一下的步骤URL:https://jingyan.baidu.com/article/22a299b51339db9e19376a18.html , 实践:新的纯Excel可以,请假单的手机号栏无效。
A:你的顺序不对,设置后得再输入:
法一,先将表格设为文本格式,然后再输入即可。
法二,或者在输入手机号码之前,输入一个英文状态下的‘ 就可以了!
来自:https://zhidao.baidu.com/question/118805241.html
想把手机号格式再变化一下的步骤URL:https://jingyan.baidu.com/article/22a299b51339db9e19376a18.html , 实践:新的纯Excel可以,请假单的手机号栏无效。
今天在使用冷备份文件重做从库时遇到一个报错,值得研究一下。
版本: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
版本: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
首先先生,如果您觉得淘宝的价格和正常销售的价格能一样吗?产品质量能一样吗?获得的保修时间能一样吗?
您不能把潜在的责任风险抹除,单算成本吧 您是联系那个保修电话
壁挂炉:官方指定售后安工电话:13311196671
13311196671,这个是我们官方指定售后
如果是13311196671这个电话给您报的价,那就是对的,淘宝上有卖控制天燃气控制板的,见下在的图,到时用图搜索即可。
产生E2的解决方法:AddTime:2021/01/06 ===>壁挂炉右侧有E2的说明。
1)更换燃气表的电池。
2)将温度由51度调节到47度。(这样就以点上火了)的确有点奇怪,实践的确如此(一是温度太高可能燃气费不少,二是温度高水泵可能循环慢,出现新的一些保护性措施。)。
3)水压按微信海顿燃气壁挂炉(北京售后服务)讲的调到1.2-1.5之间。
烧了两三周,中间出现F2是由于在过程中压力不够,出现问题,停电一会儿,把水压力加到近3时就Ok了(建议1.5左右)。AddTime:2020-12-27。
步骤如下:AddTime:2019/11/16
1、首先通上电和天然气,把地暖的两个阀门打开(逆时针旋转到拧不动就是打开到最大化了,一年用一次容易出现误判,尤其是第4步骤,出现天然气点火几秒就关了,出现过一次就是因为还是关的,感觉是逆时针拧到底了的原因!!!),从左到右第一和最后一根,第一是出热水,最后是降温的回水。
2、打开自来水管充压力到1.5-2之间,也就是要打开从左向右第三个阀门(逆时针旋转到拧不动就是打开到最大化了),然后接通自来水后,
打开壁挂炉下面的黑色补水钮(逆时针旋转),将壁挂炉上压力表压力补到1.5(1-2之间都可以),关闭补水钮,每次补完水一定要关闭(关闭从左到右第三根自来水管阀门和沉着上去靠近壁挂炉上面的黑色补水按钮)。
3、壁挂炉操作面板上ON/OFF为壁挂炉开关键,按一下打开。
4、雪花和太阳的键是模式选择键,冬天选择雪花是冬季(IN)模式,夏天(SU)选太阳模式,只有生活热水?(这个待实践考证),IN冬季模式打开后点火后,智能燃气表会自动转动起来,也就是计消耗的燃气度数。
PS:如果出现烧一会就不消耗天然气了,很可能是第一个也就是热水出口被关掉了,也可能是从左到右第四根回水给关掉了导致一加热没有散发就到了设置的温度海顿据程序也就关掉了燃气,一定要逆时针拧打开拧到拧不动了也就算是接通了。究其原因是烧的水一下子就达到了设置的温度,没有循环降温,于是据程序的判断,也就关掉了继续天然气加热,导致现象也就是不会一直燃,而是燃不到半分钟(不到10秒)就关掉了。
5、带暖气符号的加减按钮是调暖气温度,一般地暖调到50度,带水龙头符号的按钮是调生活热水温度的,调到40多度。
6、点火后屏幕上的火苗指示灯会亮。
7、REST按钮为复位重启键,当壁挂炉出现故障需要复位时按一下,回清除故障重启
8、每组散热片,譬如:厨房、客厅、主卧、次卧、厕所都在其入水处有一个开关,得打开。因为厨房的那个桌子安装时没打开,拧出来顶着桌子了,现在都是无法进水加热的。
总结,左右数第一根管子是暖气出热水口,第二根是洗菜热水,第三根是压力自来水进水(补水后关掉),第四根是暖气片回水,第一第四根水管要完全逆生长拧到头完全打开,第三根压力到2后拧紧,壁挂炉上面黑色扭也拧紧,也就是说加水压来自第三个阀门和它下游的一个黑社旋钮实现加压力到1.5-2Pa,而在打开天然气物理通路(一路的阀门打开后,直通到壁挂炉待燃烧。)后,得将室内温度也就是两排按钮中第二排的从左向右第1第2按钮给设置到50度,也样也就能按4,5步骤能够让壁挂炉自动点燃这个天然气加热暖气片的循环水源,加热后再由水泵泵到家里各个散热片,使其室内得到采暖。
阅读全文
您不能把潜在的责任风险抹除,单算成本吧 您是联系那个保修电话
壁挂炉:官方指定售后安工电话:13311196671
13311196671,这个是我们官方指定售后
如果是13311196671这个电话给您报的价,那就是对的,淘宝上有卖控制天燃气控制板的,见下在的图,到时用图搜索即可。
产生E2的解决方法:AddTime:2021/01/06 ===>壁挂炉右侧有E2的说明。
1)更换燃气表的电池。
2)将温度由51度调节到47度。(这样就以点上火了)的确有点奇怪,实践的确如此(一是温度太高可能燃气费不少,二是温度高水泵可能循环慢,出现新的一些保护性措施。)。
3)水压按微信海顿燃气壁挂炉(北京售后服务)讲的调到1.2-1.5之间。
烧了两三周,中间出现F2是由于在过程中压力不够,出现问题,停电一会儿,把水压力加到近3时就Ok了(建议1.5左右)。AddTime:2020-12-27。
步骤如下:AddTime:2019/11/16
1、首先通上电和天然气,把地暖的两个阀门打开(逆时针旋转到拧不动就是打开到最大化了,一年用一次容易出现误判,尤其是第4步骤,出现天然气点火几秒就关了,出现过一次就是因为还是关的,感觉是逆时针拧到底了的原因!!!),从左到右第一和最后一根,第一是出热水,最后是降温的回水。
2、打开自来水管充压力到1.5-2之间,也就是要打开从左向右第三个阀门(逆时针旋转到拧不动就是打开到最大化了),然后接通自来水后,
打开壁挂炉下面的黑色补水钮(逆时针旋转),将壁挂炉上压力表压力补到1.5(1-2之间都可以),关闭补水钮,每次补完水一定要关闭(关闭从左到右第三根自来水管阀门和沉着上去靠近壁挂炉上面的黑色补水按钮)。
3、壁挂炉操作面板上ON/OFF为壁挂炉开关键,按一下打开。
4、雪花和太阳的键是模式选择键,冬天选择雪花是冬季(IN)模式,夏天(SU)选太阳模式,只有生活热水?(这个待实践考证),IN冬季模式打开后点火后,智能燃气表会自动转动起来,也就是计消耗的燃气度数。
PS:如果出现烧一会就不消耗天然气了,很可能是第一个也就是热水出口被关掉了,也可能是从左到右第四根回水给关掉了导致一加热没有散发就到了设置的温度海顿据程序也就关掉了燃气,一定要逆时针拧打开拧到拧不动了也就算是接通了。究其原因是烧的水一下子就达到了设置的温度,没有循环降温,于是据程序的判断,也就关掉了继续天然气加热,导致现象也就是不会一直燃,而是燃不到半分钟(不到10秒)就关掉了。
5、带暖气符号的加减按钮是调暖气温度,一般地暖调到50度,带水龙头符号的按钮是调生活热水温度的,调到40多度。
6、点火后屏幕上的火苗指示灯会亮。
7、REST按钮为复位重启键,当壁挂炉出现故障需要复位时按一下,回清除故障重启
8、每组散热片,譬如:厨房、客厅、主卧、次卧、厕所都在其入水处有一个开关,得打开。因为厨房的那个桌子安装时没打开,拧出来顶着桌子了,现在都是无法进水加热的。
总结,左右数第一根管子是暖气出热水口,第二根是洗菜热水,第三根是压力自来水进水(补水后关掉),第四根是暖气片回水,第一第四根水管要完全逆生长拧到头完全打开,第三根压力到2后拧紧,壁挂炉上面黑色扭也拧紧,也就是说加水压来自第三个阀门和它下游的一个黑社旋钮实现加压力到1.5-2Pa,而在打开天然气物理通路(一路的阀门打开后,直通到壁挂炉待燃烧。)后,得将室内温度也就是两排按钮中第二排的从左向右第1第2按钮给设置到50度,也样也就能按4,5步骤能够让壁挂炉自动点燃这个天然气加热暖气片的循环水源,加热后再由水泵泵到家里各个散热片,使其室内得到采暖。

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.
两步解决:
步骤一: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自带客户端的参数。
阅读全文
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自带客户端的参数。

[实践OK]用killall -0监控服务的注意事项
Unix/LinuxC技术 jackxiang 2017-11-14 10:58
背景: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
后台服务需要不间断运行,意外退出后,需要将其重新拉起。常常可以通过向进程发送信号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
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
C语言中的数据对齐问题,内存中的存储并不等于其所包含元素的宽度之和。
Unix/LinuxC技术 jackxiang 2017-11-2 20:44
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
需要删除.git/index文件,
然后运行git reset,重新生成index文件。
git reset还可以删除已经commit,但未push上去的信息。
From:https://my.oschina.net/dyxp/blog/380642
[实践OK]FreeBSD/ux系统下history命令的记录如何删除
Unix/LinuxC技术 jackxiang 2017-10-14 01:24
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
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
[实践OK]自定义Linux/FreeBSD 终端/ssh登录前后的欢迎信息
Unix/LinuxC技术 jackxiang 2017-10-13 14:36
Linux/FreeBSD 终端/ssh登录前后的欢迎信息修改,均无问题,实践Ok,操作如下:
cat /etc/motd
Welcome to jackxiang's Compute Service !
From:http://xoyabc.blog.51cto.com/7401264/1679402
cat /etc/motd
Welcome to jackxiang's Compute Service !
From:http://xoyabc.blog.51cto.com/7401264/1679402
[实践OK]vim在FreeBSD下退出时SecureCRT的Tab标签出现Thanks for flying Vim的取消方法。
Unix/LinuxC技术 jackxiang 2017-10-13 11:29
解决办法:
vi ~/.vimrc
FreeBSD下实践OK:
最后修改为:
SecureCRT显示:
root@jackxiang_owncloud_tools_diff_nginx_php_mysql_redis_47_94_8*_23*:/root
连接字串来自:https://git.codingallnight.com/chris/dotfiles/commit/46921501e65ab5c731b82280d0497680ff31418e
=================================================
'titleold' 選項。替換固定的字符串 "Thanks for flying Vim",用來在退出時設置標題。
let &titleold=getcwd()
From:http://vim.wikia.com/wiki/Show_a_useful_title_on_exit_in_an_xterm
My current ~/.vimrc contains (in part)
set title
set titleold=""
set titlestring=VIM:\ %F
From:https://github.com/lazywei/vim-doc-tw/blob/master/doc/version5.twx
More:http://vim.wikia.com/wiki/Show_a_useful_title_on_exit_in_an_xterm
vi ~/.vimrc
FreeBSD下实践OK:
最后修改为:
SecureCRT显示:
root@jackxiang_owncloud_tools_diff_nginx_php_mysql_redis_47_94_8*_23*:/root
连接字串来自:https://git.codingallnight.com/chris/dotfiles/commit/46921501e65ab5c731b82280d0497680ff31418e
=================================================
'titleold' 選項。替換固定的字符串 "Thanks for flying Vim",用來在退出時設置標題。
let &titleold=getcwd()
From:http://vim.wikia.com/wiki/Show_a_useful_title_on_exit_in_an_xterm
My current ~/.vimrc contains (in part)
set title
set titleold=""
set titlestring=VIM:\ %F
From:https://github.com/lazywei/vim-doc-tw/blob/master/doc/version5.twx
More:http://vim.wikia.com/wiki/Show_a_useful_title_on_exit_in_an_xterm
FreeBSD Install Strace,不支持AMD的64位CPU, strace-4.5.18_1 is only for i386, while you are running amd64.。
Unix/LinuxC技术 jackxiang 2017-10-13 10:12
cd /usr/ports/devel/strace/ && make install clean
A package is not available for ports marked as: Forbidden / Broken / Ignore / Restricted
PKGNAME: strace
ONLY_FOR_ARCHS: i386 #不支持AMD.
distinfo:
SHA256 (strace-4.5.18.tar.bz2) = 95e7b7470e04f22c3ec8dc6d0b1fdd8944306cb5313c84c4545cd83abada26d0
SIZE (strace-4.5.18.tar.bz2) = 480973
Install strace
First update FreeBSD ports collection and install strace from /usr/ports/devel/strace:
# portsnap fetch update
# cd /usr/ports/devel/strace
# make install clean
From:https://www.cyberciti.biz/faq/howto-installl-strace-under-freebsd/
A package is not available for ports marked as: Forbidden / Broken / Ignore / Restricted
PKGNAME: strace
ONLY_FOR_ARCHS: i386 #不支持AMD.
distinfo:
SHA256 (strace-4.5.18.tar.bz2) = 95e7b7470e04f22c3ec8dc6d0b1fdd8944306cb5313c84c4545cd83abada26d0
SIZE (strace-4.5.18.tar.bz2) = 480973
Install strace
First update FreeBSD ports collection and install strace from /usr/ports/devel/strace:
# portsnap fetch update
# cd /usr/ports/devel/strace
# make install clean
From:https://www.cyberciti.biz/faq/howto-installl-strace-under-freebsd/