Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 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.

share|improve this answer
    
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. –  mtndesign 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

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.

share|improve this answer
    
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. –  mtndesign 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 5:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.