The following error messages occurred while running yum list or yum update on a centos/rhel host:

[root@test-centos ~]# yum list
Loaded plugins: rhnplugin, security
This system is not registered with ULN.
ULN support will be disabled.
Segmentation fault

As always, I did a strace on this:

[root@test-centos ~]# strace yum list
open(“/var/cache/yum/el5_ga_base/primary.xml.gz”, O_RDONLY) = 6
lseek(6, 0, SEEK_CUR) = 0
read(6, “\37\213\10\10\0\0\0\0\2\377/u01/basecamp/www/el5_”…, 8192) = 8192
— SIGSEGV (Segmentation fault) @ 0 (0) —
+++ killed by SIGSEGV +++

And here’s the error messages from /var/log/messages:

[root@test-centos ~]# tail /var/log/messages
Jan 6 07:07:44 test-centos kernel: yum[5951]: segfault at 3500000000 ip 000000350cc79e0a sp 00007fff05633b78 error 4 in libc-2.5.so[350cc00000+14e000]

After some googling, I found the yum “Segmentation fault” was caused by the conflict between zlib and yum. To resolve this problem, we need use the older version of zlib. Here’s the detailed steps:

[root@test-centos ~]# cd /usr/lib
[root@test-centos lib]# ls -l libz*
-rw-r–r– 1 root root 125206 Jul 9 07:40 libz.a
lrwxrwxrwx 1 root root 22 Aug 2 07:10 libz.so -> /usr/lib/libz.so.1.2.7
lrwxrwxrwx 1 root root 22 Aug 2 07:10 libz.so.1 -> /usr/lib/libz.so.1.2.7
-rwxr-xr-x 1 root root 75028 Jun 7 2007 libz.so.1.2.3
-rwxr-xr-x 1 root root 99161 Jul 9 07:40 libz.so.1.2.7

[root@test-centos lib]# rm libz.so libz.so.1
rm: remove symbolic link `libz.so’? y
rm: remove symbolic link `libz.so.1′? y
[root@test-centos lib]# ln -s libz.so.1.2.3 libz.so
[root@test-centos lib]# ln -s libz.so.1.2.3 libz.so.1

After these steps, you should now able to run yum commands without any issue.

Also, after using yum, you should change back zlib to the newer version, and here’s the steps:

[root@test-centos ~]# cd /usr/lib
[root@test-centos lib]# rm libz.so libz.so.1
rm: remove symbolic link `libz.so’? y
rm: remove symbolic link `libz.so.1′? y
[root@test-centos lib]# ln -s libz.so.1.2.7 libz.so
[root@test-centos lib]# ln -s libz.so.1.2.7 libz.so.1

If you can log on the host but the home directory failed mouting with the following error message:

Could not chdir to home directory /home/xxx: No such file or directory

Then one method you can try is that:

1. Ensure the home directory for your username exists on the exported NFS server
2. Append /etc/auto_home on the host with text like the following:<username> <NFS server>:/export/home/&  #this assume the exported home directory is on /export/home, your environment may varies
3. At last, ensure automount is running on the host and then try log on again. You should now able to mount your home directory.

There’s a weird incident occurred on a linux box. The linux box turned not responsible to ping or ssh, although from ifconfig and /proc/net/bonding/bond0 file, the system said it’s running ok. After some google work, I found that the issue may related to the NIC driver. I tried bring down/bring up NICs one by one, but got error:

Bringing up loopback interface bond0: bnx2i: dev eth0 does not support iscsi

bnx2i: iSCSI not supported, dev=eth0

bonding: no command found in slaves file for bond bond0. Use +ifname or -ifname

At last, I tried restart the whole network i.e. /etc/init.d/network restart. And that did the trick, the networking was then running ok and can ping/ssh to it without problem.

When I tried resetting a local user’s password on a solaris host, I met the following error message:

root@doxer # passwd <username>
New Password:
Re-enter new Password:
Permission denied

This was very weird as I was logged on as root when doing this operation:

root@doxer # id
uid=0(root) gid=1(other)

After some searching I found that this was caused by passwd by default will try to reset LDAP password if the host is using ldap for authentication. Here’s excerpt from /etc/nsswitch.conf:

passwd: compat
passwd_compat: ldap

To resolve this, you need designate which authentication mechanism you want to use for resetting a password(here we should use files as this user was local one):

passwd -r files <username>

Have you ever met error like the following?

root@doxer# find /PRD/*/connectors/A01/QP*/*/logFiles/* -prune -name “*.log” -mtime +7 -type f |wc -l

bash: /usr/bin/find: Arg list too long

0

The cause of issue is kernel limitation for argument count which can be passed to find (as well as ls, and other utils). ARG_MAX defines

the maximum length of arguments for a new process. You can get the number of it using command:

root@doxer# getconf ARG_MAX
1048320

To quickly fix this, you can move your actions into the directory(replace * with subdir_NAME):

cd /PRD/subdir_NAME/connectors/A01/QP*/*/logFiles/;find . -prune -name “*.log” -mtime +7 -type f |wc -l

11382

PS:

1. you can get all configuration values with getconf -a.
2. For more solutions about the error “bash: /usr/bin/find: Arg list too long”, you can refer to http://www.in-ulm.de/~mascheck/various/argmax/

If you want to give some information on standard output when the user press ctrl+c on the bash script, or you want to print something when the script completes, then you should consider using trap to implement this.

Here’s an example which will print something to end user when the user print ctrl+c(SIGINT is equal to number 2):