过年十几天假，在老家都快把我的生物钟给纠正过来了，十点左右睡觉，早上7点多自然醒，不熬夜感觉皮肤都好多了。但自从上班之后，又开始以前熬夜的生活了，所以我决定努力纠正生物钟，努力不熬夜。而这样又让我感觉下班之后的时间更少了，甚至连记录一些事情的时间都没有。

#工作上的一些事

年后的工作很和谐，仿佛我开始习惯这样的日子了。有些开心，也有些担忧。同事之间相处更融洽了当然开心了。可如今的状态跟前年家家购物快不行的时候感觉很相似，总觉得自己前路迷惘，很没出息的样子，想上进却没有途径。

2月10日上午，惯例叫货拉拉发货到京东物流园，司机到达目的地是11点钟，等了20分钟，跟我打电话提醒我免费等待时长不足10分钟，并告诉我，说是安排人来卸货，却迟迟未见人。我在沟通群里提醒交接人，就是之前说的那位大姐。她也说已经安排人过去了。就这样，直到我吃完午饭，发现订单还未结束，我一看等候时长已经超了一个多小时。于是我再次在群里询问那位大姐，“货还没卸货吗？有一个多小时了”。这么长时间显然不合理。

过了一会儿，订单结束时，司机跟我打电话说，装卸工是12点之后吃过饭才来的，车上一半货是司机自己卸的。听到这里，我很生气，同时对这位司机师傅感到很抱歉。从11点到13点，等了近两个小时，而且还卸了一半货。司机在电话里很无奈，但态度还是很平和的。按照1分钟5毛钱超时费，付了40多块钱。对京东的做事态度，管理不到位极其不满。所以这件事一定要有个说法，不然那边还以为我们无所谓，好欺负呢。但又不能把事情闹僵，毕竟我们是长期合作的，要是后面一直给我们穿小鞋，工作就更不好做了。

所以我没说责任问题，只是将这个事实反映给那位大姐。并刻意询问对方工作人员中午吃饭时间安排，说我们安排送货能规避这个时间。说的很含蓄，我的本意是让对方知道这次卸货超时的主要原因是他们卸货师傅不积极的问题，并希望她管理好他们家的员工，不会再出现这样的情况。她表示已经和装卸师傅说了，而且她当时不在现场，不知道情况。嘴笨不知道我说的她可理解，后来我想了想，没有强调不应该让司机等太久，好像没讲重点似的。

今天我们又叫货拉拉发京东的货了。和上次一样的数量。因为发货前点数发现多了一件，找那件货耽误了一点时间，后来到达目的地也是11点。不过今天卸货还是蛮快的，超时10分钟，这都在合理范围里。今天这个司机有点不专业，在发货的时候，用绳网固定货物的时候，耽搁了十几分钟，本来几分钟就搞定的事，他用了二十几分钟，还是在我们帮忙的情况下。

#网站无法访问

前一段时间，博客经常无法访问，显示连不上redis。我发现redis经常因为超内存自动掉进程了。于是，我将虚拟机的内存从8G升级到12G，观察了两天，但情况仍然出现，好像内存再高，都会被吃掉。所以索性直接关掉redis服务。内存占用上，这段时间好多了。

但新的问题出现了。MySQL进程掉了。这个进程掉了，问题就严重了。

Starting mysql (via systemctl): mysql.serviceJob for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xeu mysql.service" for details.
 failed!

systemctl status mysql.service
x mysql.service - MySQL Community Server
     Loaded: loaded (/etc/systemd/system/mysql.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sun 2025-02-16 18:34:55 CST; 1min 53s ago
    Process: 2043 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)
        CPU: 495ms

Feb 16 18:34:54 Debian systemd[1]: Starting mysql.service - MySQL Community Server...
Feb 16 18:34:54 Debian mysql[2043]: Starting MySQL
Feb 16 18:34:55 Debian mysql[2043]: .The server quit without updating PID file (/usr/local/mysql/var/Debian.pid). ... faile>
Feb 16 18:34:55 Debian systemd[1]: mysql.service: Control process exited, code=exited, status=1/FAILURE
Feb 16 18:34:55 Debian systemd[1]: mysql.service: Failed with result 'exit-code'.
Feb 16 18:34:55 Debian systemd[1]: Failed to start mysql.service - MySQL Community Server.

Debian.pid文件没了。这个问题只要重新执行/usr/local/mysql/support-files/mysql.server start就可以了，但是重启还会出现上面的问题。

从这篇文章找到了原因，并解决了问题。

support-files目录下的mysql.server 执行的是 mysqld_safe 而不是 mysqld，使用nano查看mysql.server的内容，找到第266行 可以看出,执行参数start时,运行的是$bindir目录下的/mysqld_safe 程序，这是由于我的所有操作都是用root 用户执行的, (这是个坑)，而用root用户执行mysqld 跟mysqld_safe 不加--user=root参数 指定用户时会报错的。

2025-02-16T10:34:32.317936Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2025-02-16T10:34:32.524313Z 0 [Warning] [MY-011070] [Server] 'binlog_format' is deprecated and will be removed in a future release.
2025-02-16T10:34:32.524436Z 0 [System] [MY-010116] [Server] /usr/local/mysql/bin/mysqld (mysqld 8.4.0) starting as process 1982
2025-02-16T10:34:32.527087Z 0 [ERROR] [MY-010123] [Server] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!
2025-02-16T10:34:32.527186Z 0 [ERROR] [MY-010119] [Server] Aborting
2025-02-16T10:34:32.527690Z 0 [System] [MY-010910] [Server] /usr/local/mysql/bin/mysqld: Shutdown complete (mysqld 8.4.0)  MySQL Community Server - GPL.
2025-02-16T10:34:32.527694Z 0 [System] [MY-015016] [Server] MySQL Server - end.

为了让mysqld_safe能过执行,需要对/etc/init.d/mysql文件进行一点点修改，还是在266行, 在执行mysqld_safe 时 我加入了 --user=root 参数.

好了，后面无论重启服务还是重启系统都OK了。