太阳侠

我是一颗恒星


  • 首页

  • 分类

  • 归档

  • 标签

  • 关于

项目的服务器迁移的问题的总结

发表于 2020-11-22   |   分类于 服务器

一、一个具体项目的服务器迁移和升级的问题总结

注意以下关键点:

1、数据库备份,不能再使用Discuz自带的备份功能,会丢失数据(不足够安全)。可以使用mysqldump直接从数据库导出sql文件,然后再目标主机导入。

2、数据库备份导出时,注意对emoji表情的兼容性,需要增加–default-character-set=utf8mb4参数。

3、新安装的项目中的字符集需要设置为utf8mb4而不是utf8,否则某些字段表情不显示(或者显示问号)。

4、新安装的项目不能使用MySQL总管理员账号,需要每个项目新建一个数据库,并配置一个项目数据库专用管理员,只授权管理这一个数据库。

5、一定要保证UCenter的应用“通信成功”,且几个项目之间必须互相隔离开(尤其是整个项目复制的,注意配置文件里的设置区分)。

6、迁移之前,在源主机和目标主机上都做好备份和快照。

7、迁移之后,测试没问题之后,及时备份和快照。

8、整个过程中,注意关闭站点,方式中途的数据写入。

9、域名的解析,可以临时域名作为过渡,最好不要让线上正式环境的域名来回更换指向IP。

10、域名相关的,如果使用了临时域名,尤其涉及第三方的:要么先不改;要么及时改回来。

11、用户资源文件的迁移,可以稍微后置。注意UCenter的用户头像文件。

12、迁移之后,必须要首先测试的功能:用户注册、消息推送(IP白名单)、crontab自动执行、短信发送。

13、注意后来添加的目录或者第三方相关目录的读写权限的设置。

14、本次对PHP7.2环境的支持,稍微后置。注意观察不兼容性,尤其是不常用到的接口。

15、注意修改php.ini的配置,支持上传大文件(建议64M),需重启生效。

16、注意修改nginx.conf的配置,支持上传大文件(建议64M),需重启生效。

17、刚迁移完后的近一段时间,注意观察是否出现异常,保持高度警惕。

18、【注意】Nginx服务必须设置为开机自启动,否则从阿里云控制台重启之后,Nginx服务是未启动状态。

二、迁移服务器的通用操作流程

1、购买一套配置更高的阿里云ECS服务器(最好有热扩展性)。

2、配置相同的LNMP环境。

3、配置视频处理程序ffmpeg,并测试可用。

4、添加消息推送的白名单IP地址。(涉及多个App)

5、安装程序初步可用。

6、备份数据恢复数据。(数据库MySQL数据)

7、测试数据没有问题PC端(用户注册登录等)。

8、测试接口可用性(App和微信小程序)。

9、计划任务crontab的配置。(注意有脚本执行文件,可成功执行之后需删除掉原服务器的crontab的相关任务)

10、迁移其他非数据库MySQL数据的data资源文件(需分批处理,影响图片和视频等的显示,不影响数据处理)。

11、整体基本可用之后,再密切追踪至少一周,看是否有因为迁移造成的BUG或者需要修复的问题。

12、注意一些目录的可读权限,尤其是后来API中自定义或者第三方专用的目录。

13、注意服务器级别的安全组特定端口的设置。

14、注意SSL证书的迁移

三、几点要求

0、完美,服务器迁移几乎不影响前端访问,不需App停用。

1、最好,App可以平滑过渡,对服务器的迁移无感。除了迁移过程中无法使用,不影响用户的登录状态,账号和密码的可用性。

2、其次,让用户重新登录一次,但是账号和密码继续保持可用性。

3、再次,用户的账号不变,密码失效,需要重置密码才可以继续登录账号。

以上4种情况。至少做到1,争取做到0,绝不能出现2和3的情况。   

phpMyAdmin的安装

发表于 2020-11-21   |   分类于 Web构建

phpMyAdmin的安装

一、本次的服务器运行环境

Linux-CentOS版本:8.1.1911

Nginx版本:1.14.1

MySQL版本:5.7.32

PHP版本: 7.2.24

二、安装过程

1、在LNMP环境已经安装好,且可以正常运行的情况下。从phpMyAdmin的官网上下载最新的版本。现在2020年11月21日是5.0.4版本。

2、下载完zip的文案压缩包,直接解压缩到目标目录(可通过http远程访问的目录)。

3、把phpMyAdmin根目录下的config.sample.inc.php复制为config.inc.php,作为其正式的配置文件使用。

4、然后在nginx的conf配置文件中给phpmyadmin配置一个虚拟主机文件。如果不想使用域名访问,可以使用localhost和指定的端口(例如8080,8000等),然后使用IP+端口来访问。

5、重启Nginx服务,让虚拟主机配置文件生效。通过浏览器访问测试效果。

三、可通过浏览器访问之后的两个问题

1、提示把配置文件的配置生成到phpmyadmin数据中存储。

2、提示“ 配置文件现在需要一个短语密码。 ”,则打开上述的config.inc.php文件,找到“blowfish_secret”,把它的值设置为一个至少32位长度的字符串。

再之后,刷新浏览器页面,重新登录。OK。

以上过程所有步骤,由本人亲测有效。

阿里云内网打包传输较大文件的方法

发表于 2020-11-13   |   分类于 服务器

今天老夫遇到一个将其一台阿里云ECS服务器某个目录下的所有文件迁移到另外一台服务器,原本以为是一个普通的操作,熟料到一看数据有10GB左右,打包压缩之后基本没有小多少,所以正常的常规wget下载肯定是不行的,效率太低,最快只有500KB/s左右。因此,在这里我准备采用阿里云自带的内网IP地址,然后直接内网SCP拖过去。

第一、准备工作

1、登录阿里云账户看到ECS服务器对应的内网IP地址。(打包文件的服务器内网IP)

2、打包压缩需要备份的网站目录,因为这里我开始打包过了,其实我不应该打包的,直接SCP,因为数据较大,打包时间也很长,后面还要解压也需要时间。

第二、SCP命令传输

1、复制目录到本地

scp -r root@网站所在内网IP地址:/home/wwwroot/拷贝网站目录 /当前拷贝过来的网站目录

2、复制打包文件到本地

scp root@网站所在的内网IP:/home/wwwroot/拷贝网站目录/laozuo.tar.gz /当前拷贝过来的网站目录

这个执行是在我们转入进来的服务器SSH执行,然后会要求我们同意和输入转出服务器的密码后开始传输。看来速度比直接wget快很多了,达到46MB/s。

最后,稍等几分钟(这里10G大概不到5分钟),传输完毕之后我们再到服务器中解压和数据拷贝(移动)即可。

【注意】

如果当前用户登录在【目标主机】,从【源主机】拷贝到【目标主机】时,有问题的话(需要输入【源主机】用户SSH密码),

也可以反过来操作,即:用户登录到【源主机】,然后再从【源主机】拷贝到【目标主机】,需要输入【目标主机】的用户SSH密码。

scp /root/yasm-1.3.0.tar.gz root@111.66.66.888:/root/

以上为一条具体的示例。

  

CentOS8解决SSHSecureShellClient连接Linux报错Algorithm negotiation failes

发表于 2020-11-01   |   分类于 技术日记

解决SSHSecureShellClient连接Linux报错Algorithm negotiation failes

今天新服务器版本已经到了CentOS8,但是SSH Secure Shell还是多年前的3.2.9,所以在连服务器时遇到标题中的报错。这个问题很悲剧,浪费了我很多时间。

网上解决这个问题的博文非常非常多,都是这样的方案:

  1. 打开/etc/ssh文件目录下的文件sshd_config

    sudo vim /etc/ssh/sshd_config

  2. 在文件末尾添加以下信息

Ciphers aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc,arcfour128,arcfour256,arcfour,blowfish-cbc,cast128-cbc

MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96,hmac-md5-96  

KexAlgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group1-sha1,curve25519-sha256@libssh.org
  1. 保存后重启ssh服务

sudo /etc/init.d/ssh restart

大家都说好用,但是我试了之后悲剧了,增加了配置后重启ssh就启动不了了,会报错。

但是我依然没能解决问题,最终决定弃用落后的SSH Secure Shell Client了,换成【FileZilla】解决问题:FileZilla也支持ssh协议传输文件,而且操作稍微比SSH Secure Shell Client人性化。

还有一种方案是把CentOS8退回到CentOS6,这还有什么用呢?

因此,应该是CentOS8和SSH Secure File Transfer Client之前的冲突解决不了的问题。  

能写出来的河南话,你会写几个?

发表于 2020-07-29   |   分类于 文学

熰

[读音]ǒu

[释义]烤过度的东西出现碳化的迹象

[引自]《管子?侈靡篇》古之祭有时而熰。《注》熰,热甚也。

[举例]火上的东西快拿起来,都烤熰了。

熥

[读音]tēng

[释义]把凉了的物体再加热或烤热

[引自]《集韻》他東切,音通。以火煖物也。

[举例]你的衣服湿了,脱下来在火上熥熥。

缏

[读音]biǎn

[释义]卷起衣袖

[引自]《说文通训定声》缏,缝缉其边曰缏。这里用引申义,因为袖子或裤子挽起的部分很像衣服被缝纫形成的缏。

[举例]干活就把袖子缏起来,省的弄脏。

癔症

[读音]yi zheng

[释义]走神,发呆,说梦话

[引自]

[举例]晚上开车看着点,别发癔症。

撧

[读音]字典里读音juē,方言里变音quē

[释义]古同“绝”,折断;断绝。

[引自]元?佚名《盆儿鬼》:我待撧枝在头上插。

[举例]过来把这个树枝撧断了。

爒

[读音]liǎo

[释义]古同「燎」。火烧

[引自]

[举例]别靠火那么近,小心把衣服爒了。

吃起来可艮gen(食物坚硬而不松脆)

[读音]

[释义]食物坚硬而不松脆。也指为人特别执拗,过于认真或者行动缓慢。

[引自]

[举例]这个萝卜吃起来可艮。你这孩子怎么这么艮不听话。

薅

[读音]hāo

[释义]揪

[引自]《说文解字》拔去田艸也。

[举例]你俩打架不要薅头发。

冇

[读音]māo(河南地区发音:māo mōu mō mù 均有)

[释义]没有

[引自]

[举例](粤语中的冇也来自河南话)

抪拉

[读音]bu la

[释义]用手来回拨弄;用手擦。

[引自]

[举例]他在朋友进屋前赶紧抪拉了一下桌子上的灰。

哕

[读音]yuě

[释义]呕吐,或要吐而吐不出东西来。

[引自]明?张自烈《正字通》:方书有物无声曰吐,有声无物曰哕,有声有物曰呕。

[举例]吃得不舒服,想干哕。

搲

[读音]wǎ

[释义]以手或瓢状舀取。

[引自]宋?司马光《类篇》:吴俗谓手爬物曰搲。元人杂剧《陈州粜米》第一折:他那边又搲了些米去了。

[举例]没吃饱,再给我搲点儿米饭。

扽

[读音]dèn

[释义]拉,猛拉,使伸直或平整。

[引自]清?《康熙字典》:《唐韵》《集韵》都困切,音顿。撼也。又《博雅》引也。一曰摩也。

[举例]刚洗好的床单太皱,来,跟我一起扽平整。

鬻

[读音]yū

[释义]液体沸腾溢出。

[引自]宋?《广韵》:鬻,薄没切:说文吹釜溢也。清?《说文解字》段玉裁注:今江苏俗谓火盛水鬻溢出为铺出,鬻之转语也,正当作鬻字。

[举例]米汤煮得快鬻出来了。

醭

[读音]bú

[释义]酒﹑酱﹑醋等因败坏而生的白霉。亦泛指一切东西受潮而表面出现霉斑。

[引自]杨万里《风雨》:梅天笔墨都生醭,棐几文书懒拂尘。

[举例]这个菜赶快放冰箱里面,要不明天就出醭。

敹

[读音]liáo

[释义]粗线缝缀。

[引自]民国章炳麟《新方言》:凡非绽裂而粗率缝之曰敹。

[举例]袖口炸线了,给它敹几针就好了。

嬎

[读音]fàn

[释义]禽类下蛋;生子多而整齐划一,也是繁殖的意思。

[引自]清?《康熙字典》:同娩。息也。清?《说文解字》段玉裁注:谓生子多而如一也。

[举例]昨晚,他家的老母鸡又嬎了三个鸡蛋。

拌

[读音]bǎn

[释义]扔,丢弃。

[引自]西汉?杨雄《方言》卷十:拌,弃也。楚凡挥弃物谓之拌。

[举例]把这些垃圾拌出去。

谝

[读音]piǎn

[释义]炫耀、夸耀或骄傲地显示。

[引自]东汉?许慎《说文解字》:谝,便巧言也。清?蒲松龄《增补幸云曲》第十六回:这奴才不弹琵琶,光谝他的汗巾子,望我夸他。

[举例]他买了个戒指,老在我面前谝。

MySQL中文按首字母排序

发表于 2020-07-23   |   分类于 技术日记

一种分析

项目中有时候会遇到需要按照汉字拼音排序的需求。

如果要排序的字段编码使用的是GBK字符集,那就可以直接按照拼音排序。因为GBK内码编码时本身就采用了拼音排序的方法(常用一级汉字3755个采用拼音排序,二级汉字就不是了),直接在查询语句后面添加ORDER BY name ASC,查询结果将按照姓氏的升序排序。

如果存储姓名的字段采用的是utf-8字符集,需要在排序的时候对字段进行转码,对应的代码是ORDER BY convert(name using gbk) ASC,同样,查询的结果也是按照汉字拼音的升序排序。

怎样才能将编码转化为GBK呢?在MySQL中提供了函数CONVERT() ,该函数可用来获取一个类型的值。该函数的使用方式为 CONVERT(字段 USING GBK)。

例如:

SELECT * FROM table ORDER BY CONVERT(field USING GBK) ASC

如果字段的值中包含数字和字母也可以排序,因为数字和字母在gbk字符集中本身就是能排序的,数字<字母<汉字。

以上亲测有效。

另一种分析:

使用MySQL过程中,我们经常会对一个字段进行排序查询,我们一般都是想要按照中文拼音首字母进行依次排序,但mysql中进行中文排序的时候,对汉字的排序结果往往都是错误的。 这种情况在MySQL的很多版本中都存在。

如果这个问题不解决,那么MySQL将无法实际处理中文。 出现这个问题的原因是因为MySQL在查询字符串时是大小写不敏感的,在编绎MySQL时一般以ISO-8859字符集作为默认的字符集,因此在比较过程中中文编码字符大小写转换造成了这种现象。

查了资料有两种解决方法:
1.对于包含中文的字段加上”binary”属性,使之作为二进制比较,例如将”name varchar(10)”改成”name varchar(10)binary”。

  1. 如果不想对表结构进行修改或者重新编译MySQL,也可以在查询语句的 order by 部分使用 CONVERT 函数。

比如 name字段为中文,需要按其排序,则可以写select * from mytable order by CONVERT(name USING gbk);   

CA根证书过期的问题

发表于 2020-06-11   |   分类于 技术日记

上一篇文章提到过PHP的curl函数的证书错误

Peer certificate cannot be authenticated with known CA certificates

中文的意思“对等证书不能使用已知的CA证书进行身份验证”。

后来采用了在curl函数中不验证证书的临时解决方法。

虽然问题暂时解决了,但是并没有找到出问题的根本原因,当然也就没有从根本上解决问题。

紧接着,后续又出大问题了。

在linux服务器上的crontab中设置的计划任务也不执行了。里面都是使用的wget加https的URL执行的。
经核查发现:

1、crontab的计划任务是在定期执行的,只是没有执行wget+https的URL请求。

2、上述计划任务中https的URL请求,如果在浏览器执行或postman中执行,都是可以正常执行出结果的。

所以证明是wget在执行https的请求时出问题了。

联系亚狐科技的客服,询问他们的SSL证书是不是出问题了。

回复是,SSL证书本身没有过期,但是颁发SSL证书的CA机构的【根证书】过期了。

回复原话

是CA证书过期了, 您更新下CA证书即可。证书没问题,有问题的是COMODO的上级证书链。浏览器访问都没问题。我可以发您最新的根证书,您替换旧可以。4月30日后签发的证书就没这个问题了。这个问题是历史问题,没办法避免。这样,我全部更新下,您重新下载可以吧。这个我们会注意这个问题,如果再有类似,我通知您。应该不会再发生了。一般如果只是使用浏览器,不会存在问题。是的,我们接收意见,以后避免再发生此类问题。

当然中间有我的提问没有写出来,这是QQ聊天记录的对方回复的部分内容的合并。

之后重新颁发了新的SSL证书,然后更新到所有使用该SSL证书的Nginx服务器之后(重启Nginx),crontab的计划任务可以正常执行了。

总结:

1、CA的根证书快过期本应该提前处理好的,这个根证书时间应该不是每一年一次的。5年或10年吧,还不确定。

2、这个CA根证书过期导致的是一些程序的执行命令和系统方法出问题,在浏览器中使用并不会表现出BUG和错误。(目前已发现明显会受影响的就是PHP的CURL函数和Linux的crontab中的wget命令)

3、当一个问题出现时,必须及时准确地定位到问题的真正和根本原因,并迅速彻底解决;否则,可能会出现更严重的问题。

PHP的curl函数的证书错误 Peer certificate cannot be authenticated

发表于 2020-06-01   |   分类于 技术日记

系统的短信发送突然全部失败了。使用postman工具测试阿里云云通信的短信API可以正常发送。

经过一番仔细核查,原因已找到,是PHP系统自带的CURL函数中的证书验证问题。

错误提示:

Peer certificate cannot be authenticated with known CA certificates

中文的意思“对等证书不能使用已知的CA证书进行身份验证”。

解决方案:
curl的设置中加入这样一项

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);

即在请求中“信任任何证书”,不再进行CA证书验证。

但是至少耽误了一天半的短信发送,只是因为周末和月底,没被发现而已。从2020年05月30日 19:36之后到2020年06月01日10:30之前,都是失败的。

奇怪的就是:为什么之前可以用,突然在2020年05月30日晚上失败了,而且是在没有更改任何服务器配置和项目相关代码的情况。后来检测,其他项目中使用相同方法的也失败了。不得不逐一修复。

关于CURL函数可以参考官网说明
https://www.php.net/manual/en/function.curl-setopt.php

以下为php curl https ssl 证书相关的设置汇总:

$curl = curl_init();
curl_setopt($curl,CURLOPT_URL,$url);
curl_setopt($curl, CURLOPT_PORT, 443);
curl_setopt($curl, CURLOPT_SSLVERSION, 3);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false); //信任任何证书
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 0); // 检查证书中是否设置域名,0不验证
curl_setopt($curl, CURLOPT_VERBOSE, 1); //debug模式
curl_setopt($curl, CURLOPT_SSLCERT, "./keys/client.crt"); //client.crt文件路径
curl_setopt($curl, CURLOPT_SSLCERTPASSWD, "112358"); //client证书密码
curl_setopt($curl, CURLOPT_SSLKEY, "./keys/client.key");
curl_setopt($curl, CURLOPT_POST, 1);
curl_setopt($curl, CURLOPT_POSTFIELDS, $data);

所以,在最后总结三点:

1、怎么能及时地发现问题;(有没有报警机制)

2、怎么能快速地解决问题;(核查问题的能力)

3、怎么能避免问题不再发生。(预防可能遇到的坑)   

Linux系统inodes资源耗尽问题

发表于 2020-05-10   |   分类于 服务器

Linux系统inodes资源耗尽问题

1 inodes介绍

Linux系统下文件数据储存在”块”中,文件的元信息,例如文件的创建者、文件的创建日期、文件的大小等。这种储存文件元信息的区域就叫做inode,中文译名为”索引节点”。

inode也占用硬盘空间,硬盘格式化的时候,操作系统自动将硬盘分成两个区域。一个是数据区,存放文件数据;另一个是inode区(inode table),存放inode所包含的信息。

每个inode节点的大小,一般是128字节或256字节。inode节点的总数,在格式化时就给定,一般是每1KB或每2KB就设置一个inode。假定在一块1GB的硬盘中,每个inode节点的大小为128字节,每1KB就设置一个inode,那么inode table的大小就会达到128MB,占整块硬盘的12.8%。

2 inodes资源耗尽

inodes使用完与存储空间使用完相似,都是创建不了文件或无法正常执行一些命令。inodes使用完,存储空间可能还有,这种情况一般是生成了大量的小文件,把inode table占满。

一般情况下存储空间使用完,inodes往往才使用百分之几,所以容易忽视对inodes使用情况的监控。

借用网图来说明inodes用尽,而磁盘空间还未用完的情况:

查看磁盘空间使用情况,使用df命令

查看inodess使用情况,使用df -i命令

上述两个命令可以使用-h参数,命令为df -h和df -hi。从图中看见磁盘空间使用71%,但是inodes使用100%。

3 inodes耗尽解决

inodes的大小在磁盘格式化分区时确定,跟分区的大小相关,分区越大,inodes越大,反之亦然。

linux操作系统根目录一般分区比较小,如果有定时性的小文件产生而又未及时清理,则很容易造成inodes占满。

inodes占满解决步骤:

(1)查看文件最多的目录

for i in /*; do echo $i; find $i | wc -l; done

如果确定目录范围,把/*写的具体点

最终发现是/var/spool/postfix/maildrop目录下小文件过多,原因如下:

由于linux在执行cron时,会将cron执行脚本中的output和warning信息,都会以邮件的形式发送给cron所有者。由于客户环境中的sendmail和postfix没有正常运行,邮件发送不成功,导致全部小文件都堆积在maildrop目录下,另由于缺乏自动清理的机制,故此目录下堆积了大量的文件。

经过排查root用户下发现有个每分钟进行一次时钟同步的定时任务,该定时任务每分钟产生一个小文件。

(2)删除大量文件

ls | xargs -n 1000 rm -rf

需要使用xargs命令,不然会删除失败。

4 总结

(1)设置方面

在crontab -e 第一行增加MAILTO=”” ,就没有文件产生啦

(2)重定向

对定时任务设置定向输出文件,不需要日志输出的定时任务可以将日志重定向到/dev/null,如下:

*/10 * * * * /tmp/test.sh >/dev/null 2>&1

(3)定时清理文件

find 目录 -type f -mtime +30 | xargs -n 1000 rm -f

(4)监控inodes的使用

备注:应注意crontab的写法和产生的文件的定时清理


以下来自另一篇文章《查找和删除占用较多Inodes的目录》

1.df -h 显示磁盘使用未到52%,但 df -i 显示 100%,站点程序提示

Warning: session_start(): open(/tmp/sess_24q39g3sh8viclu4ok8nkl7nt7, O_RDWR) failed: No space left on device

2.先尝试删除/tmp目录的一个或多个临时文件

3.从少到多,显示目录占用的inodes数量【实测此条实用】

find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n

4.本例是 /var/spool/clientmqueue/ 目录占用的inodes数量最多

5.转到相应的目录,且删除该目录下的文件,请谨慎操作

cd /var/spool/clientmqueue && ls | xargs rm -f

6.再次查看inodes占用情况,降到10%了

Nginx access.log文件太大,自动释放清理

发表于 2020-05-10   |   分类于 服务器

Nginx access.log文件太大,自动释放清理

Nginx在涉及大流量时,会发生非常庞大的日志文件,包含access.log和error.log,日志会随着连接不断增加,到无限大。如果日志文件太大,会导致Nginx运行缓慢,卡顿,也是存储资源的浪费。

该文件为nginx的访问日志文件可以删除,删除后nginx启动还会产生
如果要关闭日志功能,在nginx配置文件中找到access_log一行,改为access_log off;

手动释放清理Nginx日志文件access.log

查看并查找相关信息及路径

# 查看空间占用
$ df -h

# 定位Nginx
$ which nginx
/usr/local/nginx/logs

# 列出日志文件
$ cd /usr/local/nginx/logs
ls

# 查看日志文件大小
$ du -sh ./*

# 暂停Nginx并删除日志文件
# nginx -s stop
rm -rf *.log

这里需要注意的是,看到网上有人说重启Nginx可以清除日志文件,这是错误的。重启并不会清空日志文件,你需要手动清理。

另外,你也可以使用覆盖日志的方法清理Nginx日志文件

echo "" > /usr/local/nginx/access.log

如果不需要日志文件就直接关闭(不建议),nginx.conf

access_log off; 

对Nginx access.log进行分割

通过shell脚本+linux的定时任务进行的一个平滑切分。不需要重启nginx进程。代码cut_logs.sh

#!/bin/bash
log_path=/usr/local/nginx/logs/access.log
save_path=/usr/local/nginx/logs/bak/access_$(date +%Y%m%d -d 'yesterday').log
cp $log_path $save_path && echo > $log_path

设置定时任务

$ crontab -e
#输入
0 0  * * * /usr/bin/sh cut_logs.sh #每天的00:00执行日志切分

$ crontab -l #查看定时任务是否添加成功
1234…10
isunman

isunman

love IT, love Movie, love Love

98 日志
12 分类
45 标签
RSS
github

Links

知乎
© 2011 - 2025 isunman
由 Hexo 强力驱动
主题 - NexT.Mist
PV -- UV