2

I have an .rpm, which I created. In its %post part, I do some stuff, and in the end of this script, i call service httpd restart. It gives the following error:

+ service httpd restart
Stopping httpd: [FAILED]
Starting httpd: (98)Address already in use: make_sock: could not bind to address [::]:81
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:81
no listening sockets available, shutting down
Unable to open logs
[FAILED]

I got this from the rpm verbose installing (-vv). So I know its about httpd restart itself, nothing else. The according to netstat only one process (httpd) is listening on port 81.

$ sudo netstat -nlp | grep 81
tcp      0      0 :::81        :::*      LISTEN      29670/httpd

I don't understand, why running http FAILS at stop, and FAILS again in start.

Any ideas how to solve this?

0xmtn
  • 360
  • 3
  • 15

2 Answers2

2

The init.d scripting (invoked by the service command) depending on implementation is not as smart as you think it might be. What I see in many of these implementations, the execution of the "start" socks away the process number of the original httpd process (i.e. the one that runs as root). Then when you execute the 'stop' process, it is simply killing off (with the appropriate signal number) the root httpd process.

Sometimes, slave processes get orphaned and do not get killed (because they might be broken and not responding appropriately to the parents' signal). If this is the case, then the port is still attached by the slave processes and executing a 'restart' or a 'start' will fail.

What you need to do is to do a "ps -aef | grep httpd | grep -v grep" to find the broken slave processes, and kill them off directly (using the kill -9 pid#). There may well be more than one broken process.

Once all of the broken processes have been kilt, then you can 'start' up the apache server again.

0xmtn
  • 360
  • 3
  • 15
mdpc
  • 11,856
  • 28
  • 53
  • 67
  • Thanks for the answer.;) but I don't understand, why this only happens in installing or updating that specific RPM. There's nothing else relevant to this issue happenes in %post. No background jobs, nothing related to httpd server, just some minor rewrite rules only. – 0xmtn Dec 16 '12 at 15:46
  • 1
    @mdpc You can shorten that grep command to `ps -aef | grep [h]ttpd`, by putting the h between brackets you won't get the "grep" itself returned anymore. – Oldskool Dec 16 '12 at 17:08
1

This is sometimes an indication the host is compromised or is running a misbehaving process. I say compromised because lots of malware forks into the background and ignores signals. However they do not normally close open file descriptors that were present at the fork.

This leads to a situation where the socket that was held open by apache was inherited by the malware which ignores signals to finish. This causes the 'unable to bind to address' issue.

Try issuing the command pgrep -l -u apache and see if any processes show up that are not apache.

Matthew Ife
  • 23,357
  • 3
  • 55
  • 72
  • Well assuming that this command should show the httpd too, I got two httpd instances with different pids. And the interesting thing is, I get this error 90% of time, when I try to update (-Uvh) or install (-ivh) this rpm. – 0xmtn Dec 15 '12 at 13:27
  • 1
    If you have pages which are slow to process, the restart process may start the new daemon, before the old daemon has had time to finish. – BillThor Dec 15 '12 at 14:46
  • Based on what I see here this is not a compromise but the result of a broken http process failing to respond to the root parents' attempt to kill it off. – mdpc Dec 16 '12 at 05:57