Linux häufige Problemlösung

1. How to remove ^M in a shell script

Lösung:

sed -i ‘s/^M//g’ script.sh (Eingabe “^M” mit Strg+v, Ctrl+m)

 

2.crontab输出结果控制 问题

Wenn das Skript unter dem Root-Benutzer ausgeführt werden kann,Die geplante Aufgabe wird nicht ausgeführt,Sie müssen die Umgebungsvariable überprüfen。

/var/spool/clientmqueue目录占用空间超过100G

原因:Das in Cron ausgeführte Programm hat Ausgabeinhalt,Die Ausgabe wird per E-Mail an den Cron-Benutzer gesendet,

而sendmail没有启动所以就产生了/var/spool/clientmqueue目录下的那些文件

日积月累可能撑破磁盘

解决

1)直接手动删除:ls |xargs rm -f

2)彻底解决在cron的自动执行语句后加上 >/dev / null 2>&1 ——————————————————————————————————————————

3.telnet很慢/ssh很慢

问题某天研发某同事说10.50访问10.52memcached服务异 常

让我们检查下看网络/服务/系统是否有异常检查发现系统正常

服务正常,10.50ping10.52也正常但10.50telnet10.52 很慢

同时发现该机器的namesever是不起作用的

原因because your PC doesn’t do a reverse DNS lookup on your IP then…

when you telnet/ftp into your linux box, it’ll do a dns lookup on you

解决

1)修改/etc/hosts使hostname和ip对应

2)在/etc/resolv.conf注释掉nameserver或者找一个“活的”nameserver——————————————————————————————————————————

4.Read-only file system

问题同事在mysql里建表建不成功提示如下

MySQL>create table wosontest (colddname1 char(1));

ERROR 1005 (HY000): Can’t create table ‘wosontest’ (errno: 30)

经检查mysql用户权限以及相关目录权限没问题用perror 30提示信息为

OS error code 30: Read-only file system

可能原因

1)文件系统损坏

2)磁盘又坏道

3)fstab文件配置错误如分区格式错误错误(将ntfs写成了fat)、配置指令拼写错误等

解决

1)由于是测试机重启机器后恢复

2)网上说用mount可解决

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

5.文件删了磁盘空间没释放 问题

某天发现某台机器df -h已用磁盘空间为90G而du -sh /*显示所有使用空间加起来才30G

原因可能某人直接用rm删除某个正在写的文件导致文件删了但磁盘空间没释放的问题

解决

1)最简单重启系统或者重启相关服务

2)干掉进程 /usr/sbin/lsof|grep deleted ora 25575 data 33u REG

65,65 4294983680 /oradata/DATAPRE/UNDOTBS009.dbf (gelöscht)

从lsof的输出中我们可以发现pid为25575的进程持有着以文件描述号(fd)

为 33打开的文件/oradata/DATAPRE/UNDOTBS009.dbf在我们找到了

这个文件之后可以通过结束进程的方式来释放被占用的空 间

Echo > /proc/25575/fd/33 3)删除正在写的文件一般用 cat /dev/null > file ——————————————————————————————————————————

6.find文件提升性能

问题在tmp目录下有大量包含picture_*的临时文件每天晚上2:30对一天前的

文件进行清理之前在crontab下跑如下脚本但是发现脚本效率很低每次执行时

负载猛涨影响到其他服务

#!/bin/sh find /tmp -name “picture_*” -mtime +1 -exec rm -f {} ;

原因目录下有大量文件用find很耗资源

解决: #!/bin/sh cd /tmp time=`date -d “2 day ago” “+

%b %d”` ls -l|grep “picture” |grep “$time”|awk ‘{print $NF}’|xargs rm -rf

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

7.获取不了网关mac地址 问题从2.14到3.65(映射地址2.141)网络不通

但是从3端的其他机器到3.65网络OK

原因: # arp Address HWtype HWaddress Flags Mask Iface 192.168.3.254

ether incomplet CM

bond0 表面现象是机器自动获取不了网关MAC地址网络工程师说是网络设备的问题

具体不清

解决arp绑定arp -i bond0 -s 192.168.3.254 00:00:5e:00:01:64 ——————————————————————————————————————————

8.http服务无法启动一例 问题某天研发某同事说网站前端环境http无法启动

我上去看了下

报如下错

/etc/init.d/httpd start Starting httpd: [Sat Jan 29 17:49:00 2011] [warnen] module

antibot_module is already loaded, skipping Use proxy forward as remote ip :

wahr. Antibot exclude pattern : .*.[(js|CSS|jpg|gif|png)] Antibot seed check pattern

: Anmeldung (98)Address already in use: make_sock: could not bind to address [::]:7080

(98)Address already in use: make_sock: could not bind to address 0.0.0.0:7080

no listening sockets available, shutting down Unable to open log [FAILED]

原因

1)端口被占用表面看是7080端口被占用于是netstat -npl|grep 7080看了下

发现7080没有占用; 2)在配置文件中重复写了端口如果在以下两个文件同时写了

Listen 7080 /etc/httpd/conf/http.conf /etc/httpd/conf.d/t.10086.cn.conf

解决注释掉/etc/httpd/conf.d/t.10086.cn.conf的Listen 7080,重启OK——————————————————————————————————————————

9.too many open file

问题报too many open file错误

解决终极解决方案

echo “” >> /etc/security/limits.conf

echo “* soft nproc 65535″ >> /etc/security/limits.conf

echo “* hard nproc 65535″ >> /etc/security/limits.conf

echo “* soft nofile 65535″ >> /etc/security/limits.conf

echo “* hard nofile 65535″ >> /etc/security/limits.conf

echo “” >> /root/.bash_profile

echo “ulimit -n 65535″ >> /root/.bash_profile

echo “ulimit -u 65535″ >> /root/.bash_profile

最后重启机器 或者执行 ulimit -u 655345 && ulimit -n 65535 ——————————————————————————————————————————

 

10. overwrite file without prompt

you can realize it by input the following command directly

[root@linuxtest ~]# \cp -rf zongguofeng linuxzgf

[root@linuxtest ~]#

 

11.ibdata1和mysql-bin致磁盘空间问题 问题:2.51磁盘空间报警经查发现ibdata1

和mysql-bin日志占用空间太多(其中ibdata1超过120Gmysql-bin超过80G)

原因ibdata1是存储格式在INNODB类型数据状态下ibdata1用来存储文件的数据和索引

而库名的文件夹里的那些表文件只是结构而已

innodb存储引擎有两种表空间的管理方式

分别是

1)共享表空间(可拆分为多个小的表空间文件)这个是我们目前多数数据库使用的方法

2)独立表空间每一个表有一个独立的表空间(磁盘文件)

对于两种管理方式各有优劣

具体如下

①共享表空间优点可以将表空间分成多个文件存放到不同的磁盘上(表空间文件大小

不受表大小的限制一个表可以分布在不同步的文件上)缺点所有数据和索引存放在

一个文件中则随着数据的增加将会有一个很大的文件虽然可以把一个大文件分成多

个小文件但是多个表及索引在表空间中混合存储这样如果对于一个表做了大量删除

操作后表空间中将有大量空隙对于共享表空间管理的方式下一旦表空间被 分配就不

能再回缩了当出现临时建索引或是创建一个临时表的操作表空间扩大后就是删除相关

的表也没办法回缩那部分空间了

②独立表空间在配置文件(my.cnf)中设置innodb_file_per_table

特点每个表都有自已独立的表空间每个表的数据和索引都会存在自已的表空间中

优点表空间对应的磁盘空间可以被收回(Drop table操作自动回收表空间如果对于

删除大量数据后的表可以通过:alter table tbl_name engine=innodb;回缩不用的空间

缺点如果单表增加过大如超过100G性能也会受到影响在这种情况下如果使用

共享表空间可以把文件分 开但有同样有一个问题如果访问的范围过大同样会访问

多个文件一样会比较慢如果使用独立表空间可以考虑使用分区表的方法在一定

程度上缓解问题。 Auch,当启用独立表空间模式时需要合理调整innodb_open_files

参数的设置解决: 1)ibdata1数据太大只能通过dump导出建库的sql语句

重建的方法

2)mysql-bin Log太大

①手动删除删除某个日志:MySQL>PURGE MASTER LOGS TO ‘mysql-bin.010;

删除某天前的日志:MySQL>PURGE MASTER LOGS BEFORE ’2010-12-22 13:00:00;

②在/etc/my.cnf里设置只保存N天的bin-log日志 expire_logs_days = 30 //Binary Log

自动删除的天数 ———————

本文来自 KISSING_hu 的CSDN 博客

全文地址请点击:https://blog.csdn.net/KISSING_hu/article/details/42113261?utm_source=copy

Hinterlasse eine Antwort