1。问题描述某客户生产环境GreatSQL数据库紧急重启过程中，发现启动失败--正常启动2022-07-16T09:30:27.428609+08:000[Note][MY-010252][Server]服务器主机名（绑定地址）：'127.0.0.1'；port:330622022-07-16T09:30:27.429134+08:000[Note][MY-010264][Server]-'127.0.0.1'解析为'127.0.0.1';2022-07-16T09:30:27.429792+08:000[Note][MY-010251][Server]在IP上创建的服务器套接字：'127.0.0.1'.2022-07-16T09:30:27.430296+08:000[Note][MY-010252][服务器]服务器主机名（绑定地址）：'*'；端口：33062022-07-16T09:30:27.430816+08:000[注意][MY-010254][服务器]IPv6不可用。2022-07-16T09:30:27.431308+08:000[注意][MY-010264][Server]-'0.0.0.0'解析为'0.0.0.0';2022-07-16T09:30:27.431991+08:000[ERROR][MY-010250][Server]无法创建IPv4'0.0.0.0'的套接字：errno：24.2022-07-16T09：30：27.432466+08：000[错误][MY-010255][服务器]无法创建IP套接字：打开的文件太多-可以'创建IP套接字：Toomany打开文件2022-07-16T09:30:27.433711+08:000[错误][MY-010119][服务器]中止2022-07-16T09:30:27.435690+08:000[注意][MY-012330][InnoDB]FTSoptimizethreadexiting.2022-07-16T09:30:28.164281+08:000[Note][MY-010120][Server]Binlogend2022-07-16T09:30:28.165714+08:000[Note][MY-000000][Server]PluginGreatSQL报告：'Gdb_job_threadstopped!'2022-07-16T09:30:28.165960+08:000[Note][MY-000000][Server]PluginGreatSQLreported:'Jobmanagerlocalthreadstopped!'--接下来，开始关闭进程。上面的错误日志明确指向openfiles的相关设置，所以查看ulimit信息[GreatSQL@GDB02-DB01~]$ulimit-a...openfiles(-n)1024...[GreatSQL@GDB02-DB01~]$但是运维人员确认/etc/security/limits.conf中设置的最大文件数是正常的65535[GreatSQL@GDB02-DB01~]$tail-10/etc/security/limits.conf#@facultysoftnproc20#@facultyhardnproc50#ftphardnproc0#@student-maxlogins4*softnofile65535*hardnofile65535#Endoffile[GreatSQL@GDB02-DB01~]$虽然堡垒机登录GreatSQL用户不正常，但是root用户切换回GreatSQL用户后，打开的文件会恢复正常65535--bastion电脑直接用GreatSQL用户登录，有提示打开的文件没有修改成功。-bash:ulimit:openfiles:cannotmodifylimit:Operationnotpermitted--此时openfiles配置不生效。ulimit-a|grep'openfiles'打开文件(-n)1024--su切换到root，root的打开文件正常[GreatSQL@GDB02-DB01~]$sudosu-rootLastlogin:TueJul1911:40:45CST2022onpts/5[root@GDB02-DB01~]#ulimit-a|grep'打开文件'打开文件(-n)65535--su切换到GreatSQL，打开文件也正常[root@GDB02-DB01~]#su-GreatSQLLastlogin:TueJul2614:23:56CST2022fromXXXXXXonpts/8[GreatSQL@GDB02-DB01~]$ulimit-a|grep'openfiles'openfiles(-n)65535[GreatSQL@GDB02-DB01~]$为了尽快恢复业务，建议运维人员从root用户切换回GreatSQL普通用户再启动数据库。此时启动成功。启动数据库）并恢复正常2、ulimits不生效问题分析在对同一批备机进行问题复现分析时，运维人员发现了更多信息。(1)堡垒机直接登录GreatSQL普通用户执行ulimit命令报错[GreatSQL@GDB02-DB02~]$ulimit-n1026-bash:ulimit:openfiles:cannotmodifylimit:Operationnotpermitted[GreatSQL@GDB02-DB02~]$ulimit-Hn1024--可以发现这里使用的硬件资源限制是1024(2)堡垒机直接登录GreatSQL用户，也有相关的错误信息（之前被忽略）正在连接到XXXXXX...已建立连接。要转义到本地shell，请按“Ctrl+Alt+]”。上次登录：2022年7月26日星期二14:32:32从XXXXXX准备登录到目标设备，请等一下。上次登录：2022年7月26日星期二14:31:21来自XXXXXX-bash：ulimit：打开文件：无法修改限制：不允许操作[GreatSQL@GDB02-DB01~]$ulimit-a根据以上信息，堡垒机ssh登录ulimits异常，同用户结合su的ulimits正常，查看ssh配置文件，发现UsePAM是默认的nocat/etc/ssh/sshd_config.......#设置这个为'yes'来启用PAM认证，账户处理，#和会话处理。如果启用，PAM身份验证将#通过ChallengeResponseAuthentication和#PasswordAuthentication被允许。取决于您的PAM配置,#通过ChallengeResponseAuthentication的PAM身份验证可能会绕过#“PermitRootLoginwithout-password”的设置。#如果你只是想让PAM帐户和会话检查在没有#PAM身份验证的情况下运行，那么启用它但将PasswordAuthentication#和ChallengeResponseAuthentication设置为“否”。#UsePAMno...现在原因很清楚了，因为/etc/security/limits.conf文件其实就是LinuxPAM（PluggableAuthenticationModules）中pam_limits.so的配置文件，在没有使用PAM的场景下使用了PAM模块，/etc/security/limits.conf的内容自然是没有读到的，而su切换用户时，使用的是终端TTY登录（默认使用PAM模块），导致堡垒的GreatSQL机器切换到root，suGreatSQL后，limits的相关设置正常。3.解决方案(1)修改ssh配置文件，UsePAM=yesvi/etc/ssh/sshd_config.......#设置为'yes'，开启PAM认证，账户处理，#和会话处理。如果启用，PAM身份验证将#通过ChallengeResponseAuthentication和#PasswordAuthentication被允许。根据您的PAM配置，#通过ChallengeResponseAuthentication的PAM身份验证可能会绕过#“PermitRootLoginwithout-password”的设置。#如果您只是希望PAM检查在没有#PAM身份验证的情况下运行，则启用此功能但将PasswordAuthentication#和ChallengeResponseAuthentication设置为'no'.UsePAMyes...PS：经与局方确认，局方的机器规范也推荐UsePAM=yes，所以出现这个问题的原因应该是这些机器在投入时没有检查相关配置项生产。(2)重启sshd服务[root@GDB02-DB01~]#systemctlrestartsshd[root@GDB02-DB01~]#systemctlstatussshdsshd.service-SYSV:OpenSSHserverdaemonLoaded:loaded(/etc/rc.d/init.d/sshd；坏；供应商预设：已启用）活动：活动（运行）自星期二2022-07-2610:28:30CST；2s前文档：man:systemd-sysv-generator(8)进程：46808ExecStop=/etc/rc.d/init.d/sshdstop(code=exited,status=0/SUCCESS)进程：46815ExecStart=/etc/rc.d/init.d/sshdstart(code=exited,status=0/SUCCESS)MainPID:46823(sshd)Tasks:14Memory:85.8M......[root@GDB02-DB01~]#（3）验证：堡垒机不再通过GreatSQL应用程序用户连接错误，打开的文件也设置为65535已建立连接。要退出到本地shell，请按'Ctrl+Alt+]'。上次登录：7月26日星期二10:28:112022fromXXXXXX准备登录目标设备，请稍等。上次登录：2022年7月26日星期二10:28:17来自XXXXXX[GreatSQL@GDB02-DB01~]$ulimit-a...打开文件(-n)65535...[GreatSQL@GDB02-DB01~]$4。limits.conf配置文件相关说明limits.conf限制了每个用户可以使用的最大文件数、最大线程数、最大内存等资源配置。相关设置如下：*softnofile655350#任何用户可以打开的最大文件描述符数，默认1024，这里的值会限制tcp连接*hardnofile655350*softnproc655350#any的最大进程数usercanopen*hardnproc650000@studenthardnofile65535@studentsoftnofile4096@studenthardnproc50#学生组内进程不能超过50个，超过30个进程会提示@studentsoftnproc30(1)查看每个用户创建的进程数$psh-Led-ouser|排序|uniq-c|sort-n1chrony1dbus2postfix7polkitd129root1326GreatSQL(2)系统最大打开文件描述符数--check$cat/proc/sys/fs/file-max6550--set$vim/etc/sysctl.confs.file-max=6553600(3)一个进程最大打开文件句柄数--查看软限制，ulimit-n默认为软限制$ulimit-n65535--查看硬限制$ulimit-Hn65535--临时设置--通过ulimit-Sn设置最大打开文件描述符数的软限制，注意软限制必须小于硬限制$ulimit-Sn65535--同时设置软限制和硬限制只能用于非root用户设置比原来小的硬限制。$ulimit-n65535永久设置#root权限，在/etc/security/limits.conf中添加如下两行，表示所有用户打开文件描述符的最大数量软限制为102400，硬限制为104800。重启生效*softnofile655350*hardnofile655350Copy注意：设置nofile的硬限制还有一点要注意，硬限制不能大于/proc/sys/fs/nr_open。如果硬限制大于nr_open，注销后将无法正常登录。(4)查看当前系统使用的打开文件句柄数$cat/proc/sys/fs/file-nr56640186405其中第一个数字表示当前系统分配的打开文件描述符数，第二个数字分配后释放（目前不再使用），第三个数字等于file-max。(5)使用ulimt-n命令测试nofile的最大值。如果小于系统允许的最大值，则设置成功；如果大于最大值，系统会报错提示。$ulimit-n1100000-bash：ulimit：打开文件：无法修改限制：不允许操作$ulimit-n1048576$ulimit-n1048577-bash：ulimit：打开文件：无法修改限制：不允许操作$ulimit-n71048$ulimit-n1048576(6)ulimit-a/n/H/S/u的含义ulimit-a显示所有当前资源限制ulimit-n设置进程打开文件描述符的最大数量ulimit-H设置硬件资源限制ulimit-S设置软件资源限制描述符个数ulimit-u用户最多可以打开的程序个数
