linux时区设置 0x0 我们知道 TZ 环境变量可以设置机器时区，但是如果我们不想修改机器的profile等配置文件实现修改时区，那么也可使用以下办法： ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

常用的服务日志切割logrotate 定时任务 0 2 * * * /usr/sbin/logrotate -f /usr/local/nginx 虽然切割可以放到logrotate的目录下会自动调度,但是也可以自定义目录然后手动调用 nginx /usr/local/tengine/logs/*.log { compress daily copytruncate rotate 180 olddir /usr/local/tengine/oldlogs missingok dateext postrotate /bin/kill -HUP `cat /usr/local/tengine/logs/nginx.pid 2> /dev/null` 2> /dev/null || true endscript } nginx支持以下信号，感觉USER1更好，对nginx影响最小 TERM, INT fast shutdown QUIT graceful shutdown HUP changing configuration, keeping up with a changed time zone (only for FreeBSD and Linux), starting new worker processes with a new configuration, graceful shutdown of old worker processes USR1 re-opening log files USR2 upgrading an executable file WINCH graceful shutdown of worker processes tomcat /data/succezsoft/tomcat/logs/catalina.out { compress daily copytruncate create 0644 root root rotate 180 olddir /data/succezsoft/tomcat/oldlogs missingok dateext sharedscripts postrotate chmod 644 /data/succezsoft/tomcat/oldlogs/* endscript } 这里只切割了catalina.out,如果想要切割访问日志,可以通配或者写两个,另外执行了修改权限的命令,因为这里是调用的root执行切割,其他用户没有权限访问了,所以归档文件给读个权限 手动滚动 logrotate配置文件写好后，一般是logrotate服务来调度，但是此服务的默认调度时间是凌晨2点左右，要想验证成功肯定不能等到两点，所以可以通过命令的方式来立即执行： # --force 可以简写为 -f logrotate --force /etc/logrotate.d/nginx 有了手动触发滚动，那么我们甚至不需要把配置文件放入logrotate的配置目录下，可以选择使用命令配合crontab的方式定时执行 logrotate调度时间修改 sed -i 's/START_HOURS_RANGE=3-22/START_HOURS_RANGE=1-3/g' /etc/anacrontab sed -i 's/RANDOM_DELAY=45/RANDOM_DELAY=15/g' /etc/anacrontab

相同内容文件压缩后md5校验值不同的问题 0x1 奇怪的问题 一般我们经常使用md5来校验文件一致性，大多数时候都没有问题。但是最近在做压缩测试，想确认文件有无问题，先cp -a复制了一份目录为备份文件，再把两个目录使用相同命令压缩，校验md5却发现值不同 [root@localhost 123]# du -sb * 117569124 mat 75331667 mat.tar.gz 117569124 mmm 75333283 mmm.tar.gz [root@localhost 123]# ls -l total 147152 drwxrwxr-x 7 root root 4096 Jul 16 2021 mat -rw-r--r-- 1 root root 75331667 Jun 13 17:02 mat.tar.gz drwxrwxr-x 7 root root 4096 Jul 16 2021 mmm -rw-r--r-- 1 root root 75333283 Jun 13 17:03 mmm.tar.gz [root@localhost 123]# stat *gz File: ‘mat.tar.gz’ Size: 75331667 Blocks: 147144 IO Block: 4096 regular file Device: 803h/2051d Inode: 1853497 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2022-06-13 17:03:11.688382823 +0800 Modify: 2022-06-13 17:02:56.342809111 +0800 Change: 2022-06-13 17:02:56.342809111 +0800 Birth: - File: ‘mmm.tar.gz’ Size: 75333283 Blocks: 147144 IO Block: 4096 regular file Device: 803h/2051d Inode: 1853498 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2022-06-13 17:03:11.878389933 +0800 Modify: 2022-06-13 17:03:07.281218061 +0800 Change: 2022-06-13 17:03:07.281218061 +0800 Birth: - [root@localhost 123]# md5sum *gz e50a6873bbda5495395ca2bb810a01dc mat.tar.gz f087a1e58d12e2df5794126259b43ad5 mmm.tar.gz 可以看到复制目录和原目录本来大小是一致的，但压缩后大小不一样了，md5值变了 0x2 进一步测试 根据上面的问题，我们先后压缩同一份目录发现也可以复现，经过网上搜索后发现是跟时间有关系，目录access时间不同导致最后压缩后文件md5不一致，但是更有趣的是压缩过程会修改access的时间，导致每次打包后md5值都不一样

linux监控进程线程数 线程数监控 有需求监控jvm线程数，以下方式是否准确呢，可以跟实际jvm线程数对比一下 yum -y install psmisc pstree -p PID | wc -l

gitlab服务器中毒之一 中毒始末 gitlab服务经常用起来比较卡，通过排查发现cpu使用率持续较高，排查后发现中毒。为了保证排查准确度，需要结合top/ps/netstat来观察，单纯某个命令不一定能发现问题所在。 已通过top排查，并不能很好显示问题，继续查看监听情况 可以看到异常进程相当多，而且名字怪异，再继续根据得到的名字搜索 根据连接的ip可以知道是进入了国外矿池，基本上就是中了挖矿病毒了 挖矿病毒不可能只启动一个进程就完事了，必须要做自启的，所以需要检查每个用户的crontab任务还有/etc/cron.d/下的自动任务 根据进程号获取到了进程文件还有脚本等，但很多时候会分布多个目录做备用，要清理的话最好找出所有文件，可以根据md5搜索吧 查看相关的脚本吧，会下载挖矿程序等