Wednesday, November 6, 2013

Solution: must be owned by root and not group or world-writable

I started debugging this problem when I saw a connection refused for ssh.

This is the error that can be seen when you typically see that ssh is dead or some other service is dead and you are not able to remotely connect to your machine.

[root@ZZZZZZ~]# service sshd restart
Stopping sshd:                                             [FAILED]
Starting sshd: /var/empty/sshd must be owned by root and not group or world-writable.   [FAILED]

The solution to this problem is simple. You somehow mucked up the permissions on /var/empty. I fixed my problem by:
# sudo su
# chmod 750 -R /var
# service sshd restart

Solution for gcc makefile error: “No rule to make target”

This error happens when the file needed to make the target is not available.
"No rule to make target ttt.cpp', needed by tttp-ck.o'. Stop."
That's usually because you don't have a file called ttt.cpp available to make. Check that file exists and you are in the right path while running make.
This error can also take the form where it complains:
"No rule to make target ttt.o', needed by tttp-ck.o'. Stop."
In this case check the files needed to build ttt.o, they may be missing.
I migrated from one machine to the other, and I was facing the problem because perforce failed to checkout the file I needed on the new machine.

Quick tutorial: Debug segmentation faults with GDB

1. When you see a segmentation fault (segfault), the first thing you need to debug it is the ability to generate a core file. What is a core file? A core file is an image of a process that has crashed It contains all process information pertinent to debugging: contents of hardware registers, process status, and process data. Gdb will allow you use this file to determine where your program crashed. To ensure that you can generate a core, run the following command (if you are using bash):
ulimit -c unlimited
if using (tcsh):
limit coredumpsize unlimited
2. Once this is done, run the program again (which shows the segmentation fault). After the binary is run and it crashes, you should see a file with the name core.XXXX  in the same directory. Here XXXX is some number.

3. Read the core file using GDB. All you need to do now is run GDB with the program and the core file as gdb program core. So an example would be as shown below:
gdb path/to/the/binary path/to/the/core

4. Finally you can run the GDB backtrace command (bt) in the GDB shell to see the exact location where the program crashed. In the backtrace, each function call is assigned a  different number. These frame numbers can be used to select a particular stack frame. You can then use list to see code around that function, and info locals to see the local variables. You can also use print name_of_variable (replacing "name_of_variable" with a variable name) to see its value.