皮皮网

1.Linux下软件包类故障排错方案详解
2.CentOS7.9安装mysql-8.0.36踩坑小记
3.Compile，Make和Build的区别
4.徒手码一千行以上代码是源码一种怎样的体验？
5.app开发版和标准版区别

Linux下软件包类故障排错方案详解

       软件包类故障在Linux系统中比较常见，例如：需要编译源码包程序时系统中没有安装gcc编译工具，编译安装RPM软件包时有未解决的排错依赖关系，程序库文件或头文件的源码安装路径不正确等，软件包类故障产生的编译原因非常多，通常只需要根据相应的排错swoole聊天源码错误提示信息，确认安装好编译环境，源码找到所需要的编译依赖软件包，纠正库文件或对应的排错头文件路径即可。

       下面主要介绍rpm数据库损坏和找不到.so文件的源码故障解决方法。

1、编译rpm数据库损坏

       rpm数据库损坏的排错故障并不多见，出现该故障的源码原因一般是由于经常强制关机，误删除运行中的编译文件，强制替换一些rpm包文件等。排错rpm数据库损坏后，在使用rpm工具查询或安装软件时，将无法正常运行。

       eg：模拟rpm数据库损坏故障，并验证错误信息。

       RPM作为Linux系统中的软件包管理机制，维护着一份独立的文件数据库，用于存储在系统中已安装的rpm包信息。当数据文件损坏时，将导致不能使用rpm命令或yum命令来查询、安装、升级、删除rpm类软件包。解决该故障一般只需要执行rpm --rebuilddb命令，星元nft源码重建数据库即可。

       Ps:本系统httpd包已经安装！

       eg：清除损坏的rpm数据文件，并重建数据库信息。

       看图提示可以了吧！

2、缺少*.so类文件

       在通过源码编译的方式安装软件包时，程序的可执行文件、函数库、配置文件等一般会默认安装到/usr/local'目录下的相应位置(前提是你的程序安装在/usr/local下喔，比如：/usr/local/mysql/bin、/usr/local/mysql/lib等)，以便与系统程序的相关目录区别开来。

       *.so文件就如同Windows系统中的.dll文件一样，是库文件。一个程序的正常安装和运行需要特定库文件的支持。由于类似于/usr/local/mysql/lib的目录并不包括在Linux系统的默认库文件路径下，当安装其他软件包时，如果需要用到这些目录中的动态链接库文件，将会无法找到，从而出现缺少.so文件的错误信息。

       在RHEL5系统中，配置文件/etc/ld.so.conf记录了动态链接库的默认搜索路径。当需要添加新的库文件搜索路径时，则必须在该文件中进行相应修改，修改完毕后执行ldconfig命令，重新读取新的配置信息。

       eg：将/usr/local/mysql/lib/mysql'目录添加到系统的代理授权系统源码库文件搜索路径中。

       vi /etc/ld.so.conf//在文件末尾添加一行记录

       /usr/local/mysql/lib/mysql

       ldconfig

       当安装新的应用程序时，如果提示缺少.so文件，应首先使用find命令查找系统中是否存在对应的文件，若不存在则表示提供该链接库的依赖软件并没有安装，需要先获取相应的软件包并安装才行。若在系统中已经存在对应的.so文件，则可以通过上述修改ld.so.conf文件的方法解决库文件搜索的问题。

3、修复文件系统

       Linux主机经常因为非正常关机、突然断电、设备数据读写异常等原因导致文件系统的破坏。比较常见的是超级块（super-block）损坏，超级块是文件系统的核心档案，它记录了该文件系统的类型、大小、空闲磁盘块等信息。当文件系统的超级块数据损坏时，Linux将无法识别该文件系统，也就无法挂载使用。

       当通过/etc/fstab配置文件自动加载的文件系统出现错误时，Linux系统开机后一般会自动进行检测，并提示用户需要进行文件系统的修复操作，例如：当/dev/sdb1分区的超级块出现错误时，启动后系统将提示Give root password for maintenance

       这时只需要输入root用户的密码，即可进入到一个临时的Shell环境，在这里用户可以对出现错误的文件系统进行修复。修复一般的文件系统错误可以使用fsck命令，结合-t选项指定文件系统类型，模板展示网站源码结合-y选择对发现的问题自动回答yes。需要注意的是，如果该文件系统遭受破坏的情况很严重，则修复完毕后可能仍然会丢失一些数据，因此请慎重决定是否进行修复。

       eg：使用fsck命令修复位于/dev/sdb1分区中的ext3文件系统。

       fsck -yt ext3 /dev/sdb1

       exit//退出临时Shell环境后将自动重启。

4、磁盘资料耗尽故障

       显而易见，当一个文件系统的磁盘空间被耗尽以后，将无法继续在该分区创建新的文件数据，从而导致故障的出现，例如：当根分区/中的磁盘空间耗尽以后，将可能导致部分程序乃至整个系统无法正常启动或进行，因为一些临时的运行文件将无法建立。

       当根分区磁盘空间不足无法启动进入Linux系统时，可以通过RHEL5的光盘进入急救模式，转移或清除掉根分区占用大量空间的文件。过程不再描述。

       除此以外，当ext3文件系统中，i节点作为文件的索引节点，决定了该磁盘中文件数据的存储位置。当一个文件系统被创建以后，其i节点数就已经固定下来了，从而在该文件系统中能够使用的文件数量也就固定下来了。如果用户在该分区中创建了巨量的细小文件（耗尽i节点），将可能出现这种情况；虽然该分区中仍然有大量的ios短视频源码剩余磁盘空间，但是用户却无法再 建立新的文件。

       4.1、模拟i节点耗尽故障

       eg：1、以一个M的ext3文件系统为例（/dev/sdb2），将其挂载到/data目录下。并使用带-i选项的df命令确认该分区的i节点的使用情况。

       4.2、编写一个循环创建空文件的脚本程序，运行该脚本直至耗尽sdb2分区中的i节点。

       4.3、i节点耗尽以后，再次创建新的文件时，将会出现设备上没有空间的错误信息，但是使用df命令可以查看到该分区中还有可用的剩余空间，只是i节点数已经用完。

       4.4、修复i节点耗尽故障

       理解i节点耗尽故障的根结以后，问题就好了点了，只要找出该分区中占用大量i节点的细小文件，并进行转移或者删除即可。

       rm -rf `find /data -empty -a -type f`

5、无法卸载已挂载的设备

       在Linux系统中，通过umount命令卸载光驱等设备时，有时候会出现device is busy的提示信息，而无法卸载。这表示设备正忙，很可能是由于用户或者其他程序正在使用设备的资料而造成的，系统基于保护性考虑，将禁止直接卸载该设备。

       eg：当用户的当前功能路径位于光盘中的目录时，将无法卸载该光盘设备。

       由于umount命令并不会告知是那个用户、程序正在使用该设备中的资源，因此在当前登录的用户数量较多、进程结构复杂的情况下会很难定位正在使用该目录的进程。使用fuser命令可以帮助解决这个问题

       fuser命令用户找出正在使用某个设备或文件/目录的用户、程序等相关信息。通过-m选项可以指定相应的文件或目录，-v选项可以显示详细信息。如果使用-k选项，还可以强制关闭正在使用该文件或目录的进程（当然，也可以使用kill命令终止该进程。）

       eg：查看正在使用/media目录的用户、进程等相关信息，然后关闭正在使用该目录的进程。

6、检测硬盘坏道

       磁盘坏道分为逻辑坏道和物理坏道两种，前者主要由于软件操作不当造成，可以使用软件修复；而后者是物理性损坏，只能通过更改磁盘分区或扇区占用位置来进行改善，排除掉包含坏块的磁盘空间。当磁盘出现一下现象时，有可能是磁盘出现坏道，需要进行检测和修复。

       ：读取磁盘中的数据时，磁盘设备发出异常声响。

       ：访问磁盘中的某个文件时，反复读取且出错，提示文件损坏。

       ：对于新建立的分区无法完成格式化。

       ：系统使用该磁盘时频繁死机。

       硬盘出现坏道后，如果不及时更换或进行技术出来，坏道就会越来越多，并可能造成频繁死机和数据丢失的后果。所有必要时应该对磁盘进行定期检测，检测是否存在坏道。

       在Linux系统中，检测磁盘的坏道情况可以使用badblocks命令进行，在创建文件系统的过程中也可以结合mkfs命令的选项进行检测。使用badblocks命令时，-s选项用户显示进度信息，-v选项用于显示详情。

       eg：使用mkfs命令格式化/dev/sdb2分区，并结合-c选项进程坏块检测。

       eg：使用badblocks命令检测/dev/sdb2分区中是否存心坏块。

       以上为常见问题；欢迎补充~~

CentOS7.9安装mysql-8.0.踩坑小记

       前言：

       最近在一台测试服务器上尝试安装最新的MySQL 8.0.版本数据库，本以为轻松搞定，却意外遇到了一个小问题，耗费了不少时间。以下是我对此次安装过程中遇到的坑的记录。

       1. 排错记录

       执行./mysqld --initialize初始化命令后，出现报错，提示某些so文件版本过低。我检查了libstdc++.so.6库版本，发现缺少GLIBCXX_3.4.等几项。于是，我从公司其他服务器上拷贝了6.0.版本的libstdc++.so替换，初始化成功，报错减少。然而，替换其他so文件时，发现基础命令都无法执行，提示找不到libc.so.6库文件。经过查询，发现是glibc库文件损坏，幸好我还有SSH连接，一番操作后终于恢复正常。

       经过反思，我才意识到问题是glibc和gcc版本过低。尝试更新glibc，发现已是最新版，于是怀疑yum源太老。我尝试更换yum源或使用源码编译安装，但都无果。回顾安装包，我发现下载的是glibc2.版本的安装包，需要glibc版本在2.及以上。再次查看MySQL官网，发现不同glibc版本的安装包，低版本的Linux发行版可以使用低版本的安装包。

       经过查阅资料，我了解到CentOS 7.9系统默认的glibc版本是2.，glibc是Linux系统中非常重要的库，几乎所有Linux程序都依赖于它。因此，生产服务器在进行升级时应谨慎。建议在CentOS 7.9上安装MySQL时，使用glibc版本为2.或2.的安装包。

       2. 全面认识MySQL安装包

       这次排错经历让我对MySQL安装包有了更深入的了解。以Linux系统MySQL 8.0.版本为例，官网提供了三种处理器架构的安装包：x_-bit、x_-bit和ARM_-bit。服务器通常使用x -bit架构，可以通过uname -m或arch命令查看。根据glibc版本，官方提供了glibc2.、glibc2.和glibc2.三种安装包。对于特定的glibc版本及处理器架构，MySQL官方提供了三种不同的安装包，包括用于生产环境的MySQL服务器二进制文件、测试套件和集成包。

       总结：

       这次小插曲让我重新认识了MySQL安装包。从MySQL 8.0.版本开始，官方才提供基于glibc2.的安装包。安装MySQL时，应根据操作系统及glibc版本选择匹配的安装包，以避免初始化失败。

Compile，Make和Build的区别

       ã€€ã€€Compile、Make和Build的区别

       ã€€ã€€

       ã€€ã€€é’ˆå¯¹Java的开发工具，一般都有Compile、Make和Build三个菜单项，完成的功能的都差不多，但是又有区别。

       ã€€ã€€

       ã€€ã€€ç¼–译，是将源代码转换为可执行代码的过程。编译需要指定源文件和编译输出的文件路径（输出目录）。Java的编译会将java编译为class文件，将非java的文件（一般成为资源文件、比如图片、xml、txt、poperties等文件）原封不动的复制到编译输出目录，并保持源文件夹的目录层次关系。

       ã€€ã€€

       ã€€ã€€åœ¨Java的集成开发环境中，比如Eclipse、IDEA中，有常常有三种与编译相关的选项Compile、Make、Build三个选项。这三个选项最基本的功能都是完成编译过程。但又有很大的区别，区别如下：

       ã€€ã€€1、Compile：只编译选定的目标，不管之前是否已经编译过。

       ã€€ã€€

       ã€€ã€€2、Make：编译选定的目标，但是Make只编译上次编译变化过的文件，减少重复劳动，节省时间。（具体怎么检查未变化，这个就不用考虑了，IDE自己内部会搞定这些的）

       ã€€ã€€

       ã€€ã€€3、Build：是对整个工程进行彻底的重新编译，而不管是否已经编译过。Build过程往往会生成发布包，这个具体要看对IDE的配置了，Build在实际中应用很少，因为开发时候基本上不用，发布生产时候一般都用ANT等工具来发布。Build因为要全部编译，还要执行打包等额外工作，因此时间较长。

徒手码一千行以上代码是一种怎样的体验？

       徒手写一千行以上的代码根本就不算什么。语言不同对应的难度也不一样。C算比较有难度的，但是用汇编语言更具挑战性。时间跨度不同，也不一样。bug的多少难度也不一样。这个问题有点类似于开手动档十公里不熄火是怎样的体验。我至今犹记得上学的时候一个老师吹嘘他（还是他同学）可以一下子写一千多行的C然后一次性编译通过，有没有bug就不记得了。

app开发版和标准版区别

       app 开发版是指程序的源代码，没有经过混淆和压缩之前的原始版本，所有代码的注释和空行都没有被删除，变量名也没有被转换成单个的字符。这种版本非常便于开发人员调试和排错。

       标准版是开发版经过编译打包之后生成的最终版，日常用户使用的都是 app 的标准版。这种版本的应用因为删除了调试信息，所以运行速度和性能要优于开发版。