今日，已经在linux服务器运行了一年多的mysql突然挂掉了两次，用navicat连接不上。第一次是在早上，发现挂了之后，马上就用mobaXterm登录到腾讯云服务器，输入命令
systemctl restart mysqld.service
即将mysql重新跑起来了。但今天下午，又出现了挂掉的情况，不管那么多，还是采用上午的方法，但这次却不管用了，执行命令之后，却报错了，错误显示如下：
那就按提示输入命令 
systemctl status mysqld.service
吧，然后执行，显示如下：
这里还是完全看不出什么错误。。认真回想了一下，最近在这个服务器上部署了几个项目，而且没有做优化的那种，我猜想很有可能是服务器内存不够用，导致mysql挂掉了，而且也启动不起来。 
这样想了以后，还是不能确定原因，那还是需要找出具体原因。mysql是有启动日志文件的，查了一下，找到了启动日志文件所在路径，即/var/log/mysqld.log(查找方法，可以看/etc/my.cnf文件，最后一张图片有显示)，用cat 命令显示该日志文件，拉到最底，发现了错误原因：
只见显示InnoDB:Cannot allocate memory for the buffer pool，哈哈，原来是内存不足，不够分给缓冲池了。。既然这样，那就好办了，如上图所示，初始化缓冲池需要128m，那就想办法让他小于128m吧。
修改mysql的配置文件，/etc/my.cnf，只修改一个配置参数，即innodb_buffer_pool_size，原本是注释掉的，现在放开注释，而且将值改为100M。命令如图：
重新执行mysql启动命令，即可成功启动mysql。。。。

今日，已经在linux服务器运行了一年多的mysql突然挂掉了两次，用navicat连接不上。第一次是在早上，发现挂了之后，马上就用mobaXterm登录到腾讯云服务器，输入命令

systemctl restart mysqld.service

即将mysql重新跑起来了。但今天下午，又出现了挂掉的情况，不管那么多，还是采用上午的方法，但这次却不管用了，执行命令之后，却报错了，错误显示如下：

那就按提示输入命令

systemctl status mysqld.service

吧，然后执行，显示如下：

这里还是完全看不出什么错误。。认真回想了一下，最近在这个服务器上部署了几个项目，而且没有做优化的那种，我猜想很有可能是服务器内存不够用，导致mysql挂掉了，而且也启动不起来。

这样想了以后，还是不能确定原因，那还是需要找出具体原因。mysql是有启动日志文件的，查了一下，找到了启动日志文件所在路径，即/var/log/mysqld.log（查找方法，可以看/etc/my.cnf文件，最后一张图片有显示），用cat 命令显示该日志文件，拉到最底，发现了错误原因：

只见显示InnoDB:Cannot allocate memory for the buffer pool，哈哈，原来是内存不足，不够分给缓冲池了。。既然这样，那就好办了，如上图所示，初始化缓冲池需要128m，那就想办法让他小于128m吧。

修改mysql的配置文件，/etc/my.cnf，只修改一个配置参数，即innodb_buffer_pool_size，原本是注释掉的，现在放开注释，而且将值改为100M。命令如图：



重新执行mysql启动命令，即可成功启动mysql。。。。

出现的问题
公司使用树莓派当作开发板，使用ntp服务作为时间同步工具，之前一直运行正常，今天突然不能正常使用，查看状态如下：



绿色字体可以看出服务启动异常，正常应该是acitve(running)
解决方法
查看 /lib 目录的权限，如果是700，则修改为755，再次启动服务，发现可以执行成功。

当然，我这个解决方法不一定适用您遇到的问题，所以我接下来会梳理解决该问题流程，或许对您可以有所启发。

解决问题的流程


step1 加日志

修改/etc/ntp.conf文件内容如下，加入日志文件路径。



重启服务sudo service ntp restart,服务依旧启动失败，打开日志文件内容如下：



可以看见出错原因就是Cannot find user ID 106


step 2 查找用户信息

使用id ntp命令



可以看到ntp服务的user id就是106，此时怀疑是不是保存这些内容的文件有问题
查看相关文件信息



文件的权限，及文件内容都正确(这里判断内容正确是因为与其它ntp服务正常运行的开发板输出内容一致）。

到这步，卡了很久。去ntp官网，Stack Overflow，Google都没搜到，于是尝试查看ntp源码，找到报错的原因。



step 3 查看ntp服务源码

GitHub地址

代码片段如图：



可以看出来，是函数**getpwuid()**返回空指针导致的，接下来就来测试该函数。


step 4 测试**getpwuid()**函数

编写的测试代码：


#include <pwd.h>
#include <sys/types.h>
main()
{
    struct passwd *user;
    user= getpwuid(106);
    printf("name:%s\n", user->pw_name);
    printf("uid:%d\n", user->pw_uid);
    printf("home:%s\n", user->pw_dir);
}

交叉编译之后放到开发板上运行，输出如下：
pi@raspberrypi:~ $ ./testgetpwuid.out 
name:ntp
uid:106
home:/home/ntp

居然正确执行了！！！！  难道是用户出问题了？


step 5 尝试删除ntp用户，重新添加

userdel ntp && useradd ntp

此时，ntp的user id等都发生了变化
pi@raspberrypi:~ $  id ntp
uid=1001(ntp) gid=1001(ntp) groups=1001(ntp)

重启服务，依然失败！

难道和运行环境有关系？


step 6 切换到ntp用户下


步骤如下：
pi@raspberrypi:~ $ passwd ntp
passwd: You may not view or modify password information for ntp.
pi@raspberrypi:~ $ sudo passwd ntp
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
pi@raspberrypi:~ $ sudo su ntp
Cannot execute /bin/bash: Permission denied  


Cannot execute /bin/bash: Permission denied 解决办法

注意：按照解决办法，修改了/lib权限，从700改为755
ntp@raspberrypi:/home/pi$ sudo service ntp restart

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for ntp: 
ntp is not in the sudoers file.  This incident will be reported.


ntp is not in the sudoers file  解决办法

root@raspberrypi:~# su - ntp
No directory, logging in with HOME=/
ntp@raspberrypi:/$ sudo mkdir /home/ntp
ntp@raspberrypi:/$ /home/pi/testgetpwuid.out 
name:ntp
uid:1001   --> id变了是因为step 5
home:/home/ntp

发现还是执行成功了！

再次重启服务：



AMAZING！！！成功了
step 7 总结

梳理步骤，逐步还原，发现只要/lib目录权限修改为755(或者说让其它用户也有访问权限），服务就可以启动成功，看一下ntp服务的依赖:



可以看见，依赖了/lib目录！！！
思路坎坷，所幸解决了~~~
————————————————

版权声明：本文为CSDN博主「風居住的街道_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/qq_27727147/article/details/107496107

一、django的调试模式

django的调试模式功能强大，但是在该模式下，所有的SQL查询都会被保存在内存中，所以项目上线后应该关闭调试模式，避免内存溢出。如果你发现自己的django项目内存占用不断升高，不用慌，可能仅仅是由于开启了调试模式。

二、werkzeug的调试模式

安全团队的同事提醒我们django项目的调试模式被打开了，找了半天才发现打开的是werkzeug的调试模式而不是django的调试模式。那么怎么关闭它呢？

经过定位，我们发现是django_extensions库的runserver_plus命令调用了werkzeug的接口函数，因此我们需要定义自己的runserver_plus命令，覆盖django_extensions库的runserver_plus命令，在调用werkzeug的接口时关闭调试模式。步骤如下：

1. 复制命令文件

django_extensions库是django的命令扩展库，我们需要把runserver_plus命令对应的文件从它的安装路径复制到我们自己项目的根目录。

python_path/dist-packages/django_extensions/management/commands/runserver_plus.py复制到project_path/management/commands/runserver_plus.py，其中python_path是python库的安装路径，project_path是项目的根目录。

2. 修改自定义命令文件

修改project_path/management/commands/runserver_plus.py，把Command.inner_run方法调用的run_simple的入参use_debugger改为False。

        run_simple(
            self.addr,
            int(self.port),
            handler,
            use_reloader=use_reloader,
            use_debugger=True,
            extra_files=extra_files,
            reloader_interval=reloader_interval,
            reloader_type=reloader_type,
            threaded=threaded,
            request_handler=WSGIRequestHandler,
            ssl_context=ssl_context,
        )

改成

        run_simple(
            self.addr,
            int(self.port),
            handler,
            use_reloader=use_reloader,
            use_debugger=False,
            extra_files=extra_files,
            reloader_interval=reloader_interval,
            reloader_type=reloader_type,
            threaded=threaded,
            request_handler=WSGIRequestHandler,
            ssl_context=ssl_context,
        )

3. 修改项目配置

修改settings.py的INSTALLED_APPS项，确保我们的项目的应用写在django_extensions之前，这样我们自定义的runserver_plus命令才会覆盖django_extensions的runserver_plus命令。

INSTALLED_APPS = [
    ...
    'project.ProjectConfig',  # 安装我们的项目的应用，要放在django_extensions前面
    'django_extensions',  # 安装django_extensions应用
    ...
]

重新启动项目以后我们就会发现Debugger is active!的提示已经没有了。