以下来自uwsgi.log的部分日志并做解读

[pid: <进程ID>|app: <应用标识>|req: <请求ID>] <请求源IP> () {<请求变量数量> vars in <请求变量字节数> bytes} [<日期时间>] <请求方法> <请求路径> => generated <生成的字节数> bytes in <耗时> msecs () <响应头信息> (1 switches on core <核心编号>)

---

[pid: 27619|app: 0|req: 54153/75569] 46.19.138.234 () {44 vars in 776 bytes} [Mon Dec 9 14:19:40 2024] GET / => generated 0 bytes in 0 msecs (HTTP/1.1 302) 8 headers in 241 bytes (1 switches on core 0)
M1.进来了
None

---

pid即Process ID，进程ID

req请求ID

req: 54153/75569，其中，75569标识当前进程，即pid27619的生命周期中总的被请求次数

44vars表示请求中包含44个变量

msecs标识毫秒

8 headers in 241 bytes标识请求含有8个HTTP头部，例如Content-Type，User-Agent等

GET / ，GET标识请求方式为get /标识，请求的是根目录

—————————————————————————–

初步来看，应该是被恶意访问攻击了，访问了很多不应该访问的地址。

————————————–

先看服务器的各项服务是否正常运行，先看nginx

systemctl status nginx

可见，nginx噶了

—————————————————————

启动nginx并再次查看nginx状态

sudo systemctl start nginx

可见，nginx又活了

—————————-

换个浏览器继续访问，看是否可以正常工作

情况好一点了至少，至少报错不一样了，愿意敷衍我一下，继续排查

——————————————————————————-

继续看Django的服务器uwsgi是否一切正常

ps aux|grep uwsgi

这些其实是grep产生的进程，详细的参数解释如下

解释各个部分的含义：

1. root：
   • 这是进程的用户。root 是 Linux 系统中的超级管理员用户，通常是系统进程和服务的拥有者。在这个例子中，grep 命令是以 root 用户身份运行的。
2. 8058：
   • 这是进程的 PID（进程 ID）。PID 是一个唯一的标识符，用于区分系统中的每个进程。在这里，grep 命令的进程 ID 是 8058。
3. 0.0：
   • 这是该进程占用的 CPU 百分比。0.0 表示该进程几乎没有占用 CPU 资源。
4. 0.0：
   • 这是该进程占用的内存百分比。0.0 表示该进程几乎没有占用系统内存。
5. 112812：
   • 这是该进程所使用的虚拟内存的大小，单位是 KB（千字节）。这里 112812 KB 即约 110MB。
6. 980：
   • 这是该进程的终端（TTY），即进程在哪个终端或控制台运行。pts/0 表示这是一个伪终端，它通常用于 SSH 会话或其他远程连接。
7. S+：
   • 这是进程的状态。常见的状态包括：
     • S：表示进程处于“睡眠”状态，即正在等待某些资源（如I/O）。
     • +：表示该进程是前台进程组的一部分。一般来说，如果你在终端运行命令时按下 Ctrl+C，它会变为后台进程。
8. 06:53：
   • 这是进程启动的时间，表示进程开始运行的时间。这里是 06:53，表示这个进程大约在 6:53 AM 启动。
9. 0:00：
   • 这是该进程已经消耗的总 CPU 时间。0:00 表示该进程没有消耗 CPU 时间，通常是因为它非常短暂或者只是一个查找命令（如 grep）。
10. grep –color=auto uwsgi：
    • 这是执行的命令行。表示你执行的命令是 grep --color=auto uwsgi，即搜索包含 uwsgi 的进程。

—————————————————————————-

现在来尝试启动uwsgi服务

按照GPT的指导，这个命令并未成功启动。但是uwsgi这个程序是有正确安装的。暂且不讨论深究为什么这个命令无法启动

——————————————————————————-

找到了之前的手动部署Django的笔记，然后按照笔记来运行uwsgi，如下所示

笔记链接http://www.chan.ink/index.php/2024/07/28/django%e9%a1%b9%e7%9b%ae%e9%83%a8%e7%bd%b2-%e5%91%bd%e4%bb%a4%e8%a1%8c%e6%96%b9%e5%bc%8f/

执行记录如下

uwsgi –ini uwsgi.ini

ps aux|grep uwsgi

首先，回到项目的目录下，然后执行笔记中的命令

奇怪的是，sudo systemctl status uwsgi并看不到相关状态，此处亦暂不深究

继续使用之前的查看进程的命令，可以看到，进程起来了

————————————————————————-

此时再在浏览器输入地址，结果如下

可以看到，又不一样了，又敷衍了一次，貌似离结果越来越近

PS：上面的是夸克浏览器，谷歌浏览器一直是下面这个死样子。。没变过，我还使用ctrl+F5的方式了，此处也暂不深究

———————————————-

根据我的经验，Internal Server Error一般是服务端代码错误，但是我之前都是好好运行的，代码不会有问题，难不成恶意攻击的人，修改了相关配置或代码么。继续分析下

———————————————————————-

继续查看uwsgi的日志，最新日志如下

emmm，看起来是在被持续不断的攻击，在持续不断的访问乱七八糟不是我配置的东西。

不过从响应码来看，都是500，他也没有访问成功。

从访问的内容来看，难不成他黑进了我的服务器，并且部署了他的应用程序么。

IP地址缅甸，额，噶腰子的。更换职业方向，改行噶服务器了么。牛皮

———————————————————————————

鉴于uwsgi.log文件较大，每次只能下载到本地才能查看，现在将其移动到其他目录，然后让uwsgi生成新的log文件

—————————————————————-

移动

mv uwsgi.log app01/

————————————————————————

移动完了，现在的情况是，我访问服务器地址，只有nginx的日志有记录，uwsgi.log一直是空。所以我打算关闭之前打开的uwsgi进程，并重新启动来试试看

ps aux|grep uwsgi

uwsgi –ini uwsgi.ini

---

——————————————–

重启uwsgi进程后，终于获得了珍贵的2kb数据记录日志

———————————————————–

查看日志

从这里的记录提示，应该是没找到模块django，故而报错，无法加载相对应的app

—————————————————————–

总算是找到突破口了，大概的问题应该就是在这里，从写这篇文章开始到现在，有2个小时了，吃个饭继续。

2024.12.10 7；53

————————————————————

激活项目的虚拟环境，并查看是否安装了django

可见，对应的虚拟环境中，是有安装django的

那么，uwsgi没有找到django模块，可能并没有冲对应的虚拟环境中找，而是找的linux自带的python环境中查看，故而找不到。

——————————————————————————

这些都是我访问的，可见，nginx正确的将非静态文件请求，发送给了uwsgi服务，但是，uwsgi服务，找不到python应用。

———————————————————————————–

有一个疑问，暂且记录在此

从上一个的uwsgi记录可以看到，我访问的ip为36.33.246.45，而我本机看到的ip于此不同。我猜测是因为，我是在一个大的局域网下，是其中的一个NAT，即端口映射出去的。

————————————————————————————————

继续排查

uwsgi的log日志中显示使用的python版本是3.6.8

而我在linux环境下以及虚拟环境下，查看结果如下图所示

很奇怪的是总共有3个不同的python版本

我猜测，3.6.8也是linux全局环境中的python，只是在查看版本时，默认看到的是2.7，但是使用的时候，默认使用的是3.6.8.此为我猜测，并未证实。

———————————————————————————-

继续杀掉当前的uwsgi进程，然后使用指定的虚拟路径下的python版本启动uwsgi试试看。

uwsgi –ini /www/wwwroot/day16/uwsgi.ini –pythonpath /www/wwwroot/day16/env/bin/python

奇怪的是，uwsgi日志中，显示的还是3.6.8的版本

难道是这3个版本还各有不同么，抑或是权限问题，我看最后的所有者是0，不太懂这个。我再去试试

————————————————————-

经过测试，无论使用哪个，都是3.6.8

———————————————————————

破案，通过GPT的指导，貌似uwsgi和3.6.8的python进行了绑定

接下来的解决办法有两种。一种是通过修改绑定的python版本从3.6.8过度到3.9.5版本。因为3.9.5版本安装有django，亦或者，通过为3.6.8安装对应的django模块。

—————————————————————————

通过在uwsgi.ini中添加了如下解决了问题

添加这个后，uwsgi的日志如下所示

可以看出，此时使用的是虚拟环境中的3.9.5版本，且不再报错没有django模块，因为此虚拟环境中，本来就安装了django模块。

———————————————————————————————-

此时在夸克浏览器上面，显示再次访问显示如下

但奇怪的是，Chrome浏览器，访问仍然如下图所示

而且，我还ctrl+F5了，按照GPT所说，我是用无痕模式也是不行。此处暂不讨论研究，存而不论。

—————————————————————–

——————————————————————-

暂时就先到这里吧。问题解决了。

首先是nginx服务挂了

其次uwsgi服务挂了

依次启动后，uwsgi服务存在无法找到django模块的问题

通过在uwsgi.ini文件中添加如下解决了问题

pythonpath = /www/wwwroot/day16/env/lib/python3.9/site-packages

————————————————————————————-

篇幅过长，历时5个小时才解决。

下一篇再详细研究下手动部署中，uwsgi的配置文件中，chdir，home，virtualenv以及pythonpath有何关系和区别。知其然知其所以然才能对这类问题的解决了如指掌。