could not bind to address 0.0.0.0:443

moshem

Verified User
Joined
Nov 23, 2008
Messages
27
Hi,

I have a VPS on a FreeBSD 4.1 server w/Direct Admin

this week, on three seperate cases, I had my httpd service stop and I couldn't get it up again.

on the last time I had help from a friend, which I can't reach right now.

he told me he found out some other process is using the apache ports and he located it and killed it.

my questions are :

1. Does anyone know anything about this problem and why it occures ?

2. Is there a solution ?

3. How can I get the PID of the process holding the port ?

I tried :

210# netstat -na -S -f inet | grep .80 | grep LISTEN
tcp4 0 0 212.143.230.210.80 *.* LISTEN

this only gave me the fact that there is a process but not the PID, in my version of FreeBSD there seem to be no way for netstat to tell me what is the PID

I also tried:

210# sockstat -4l
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS


but got an empty list...


please help


thank you.
 
You should be able to find the PID of the listening process using "lsof -i TCP:443". Last time I checked (4.x), FreeBSD's netstat didn't have the very useful "-p" switch like the linux binary does... but I remember "sockstat -4l" working, you may have some kernel options issue.

I also know what the problem probably is: any process launched by mod_php (via mail(), or exec() etc) inherits Apache's open files, like logfiles and... sockets.
This is a very, very long-lasting problem that neither PHP developers or Apache developers are willing to solve; they have been fighting over this for years! See http://bugs.php.net/bug.php?id=38915

The only "easy" solution is to use PHP-CGI instead of mod_php. If you can't do it , make sure any process that has httpd as parent process is killed (that can cause other problems) when restarting Apache (DA restarts it every day, at midnight). You can do that directly in /etc/init.d/httpd.
 
Hi,

thanks for your help.

sadly, my system is not equipped with lsof command, any idea where I can pkg_add it from ?

any other way to get the PID ?


If I understand the PHP/Apache issue you described, that means I need to shutdown PHP before attempting to restart apache, right ? how do I shutdown PHP ?


thanks
 
Nope, I dont have the ports directory on my server.

I tried downloading it , got a lsof-4.82A,3.tbz

bzip2 it..

then got a tar

then...

tar -xvvzf lsof-4.82A,3.tar

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error exit delayed from previous errors
210#


so this is getting me no where...
 
4.10 is way old they probably wont even support it anymore. Good luck finding packages for it. Try to google to find lsof source and install it that way.
 
God, I remember 4.x being the last version of FreeBSD I deployed... a few years ago :D you should really think about upgrading your system, it probably is full of vulnerabilities...

Anyway, you can't "shutdown" PHP... mod_php is a module of Apache, which means that PHP is embedded in every "httpd" process.
What I suggested to do is to kill any process that has httpd as parent process, because it means that it was (probably) launched by PHP and it steals httpd's handlers. To do that, create a small script that searches the main httpd process PID, uses pstree to show any child of that process that hasn't the name "httpd" and kill them all between the "stop" and "start" funtions call in the apache init.d "restart" function.

If you don't know how to do that, I can try to do it... but I'll need access to your system :)
 
I got lsof source and compiled it..

I also pkg_add pstree from the freebsd FTP


both show the same problem, when run, then show nothing..

just return..

no matter what options I send to it, I get blank!


what could be wrong here ?
 
Your using an extremely outdated version of freebsd. What do you expect :)
 
well, yes, but I dont think it has anything to do with the fact that compiled commands or commands that have binaries available for this platform return with no output...

what can it be ?

BTW, I don't have a lot of choice, this is a server I rent, a virtual private server that suits my current needs in the budget, I get a VPS with SSH access and unlimited space or bandwidth for a low price..

one of the disadvantages is an outdated OS...
 
I'm not writing to solve your problem; I don't use FreeBSD and haven't used any BSD variant in years, so I don't know enough to help you solve the problem.

However I am writing to point out that the server really doesn't suit your current needs if it doesn't run.

I don't see that this has anything to do with DirectAdmin; it appears to be a FreeBSD issue unrelated to DirectAdmin. If that's the case, then of course the best place to request help will be a FreeBSD forum.

But of course you know that if you write to a FreeBSD forum the only help you're going to get (if you get any at all) is going to be to use a later version.

That's one of the disadvantages of using FreeBSD :).

Jeff
 
The only "easy" solution is to use PHP-CGI instead of mod_php.
Which breeds its own problems, as you can see in my private email to you.
If you can't do it , make sure any process that has httpd as parent process is killed (that can cause other problems) when restarting Apache (DA restarts it every day, at midnight). You can do that directly in /etc/init.d/httpd.
How?

Thanks.

Jeff
 
Which breeds its own problems, as you can see in my private email to you.
I'll receive your message as soon as it passes my greylisting system :)

For the killing question... If I find some free time I'm going to work on it this evening and give you the answer.

EDIT: well, I did it quite fast :)
  1. find the restart) case in your httpd init script
  2. put this just before the stop function:
    Code:
    httpd_childs=$(pstree -p $(ps u -C httpd |grep ^root |awk '{print $2}') |egrep -o '\([[:digit:]]+\)' |tr -d '()')
  3. put this just before the start function:
    Code:
    for pid in $httpd_childs; do kill -9 $pid 2>/dev/null; done

Use this code at your risk, I didn't test it too much but it should work :)

EDIT2: I also didn't receive your message yet, which is worrying... can you please tell me from which address you sent it so that I can check on my logs?
EDIT3: well, I found it... your MTA tried to deliver the message exactly one hour ago, hit the greylist and didn't try anymore... you should check your queue settings
EDIT4: ok, received and answered :) it took 1 and a half hours for your message to arrive, you should definitely check your queue settings; RFC says a few minutes should pass before the first retry
This is my conf snippet (of course a DA server with Exim):
Code:
######################################################################
#                      RETRY CONFIGURATION                           #
######################################################################

# This single retry rule applies to all domains and all errors. It specifies
# retries every 15 minutes for 2 hours, then increasing retry intervals,
# starting at 1 hour and increasing each time by a factor of 1.5, up to 16
# hours, then retries every 8 hours until 4 days have passed since the first
# failed delivery.

# Domain               Error       Retries
# ------               -----       -------


begin retry

*                      *           F,2h,15m; G,16h,1h,1.5; F,4d,8h
 
Last edited:
Bump, since I (hopefully) finished editing my previous post and I think that nobody noticed my edits. :)
 
I don't know about anybody else; I just got to the forum again now (and I notice your edits).

Are you using the changes to the script? I think perhaps maybe they should be in DirectAdmin as a standard, since they won't hurt anything, even for folk who use php as cgi. What do you think?

And now on to the mail delivery issue, which I'll keep short since it's only germane to the two of us under this topic.

My retry configuration is the same as yours; I use a personal release candidate of my SpamBlocker3 configuration.

Nevertheless it didn't retry for an hour and a half.

There's a greater than usual amount of email in my queue since about the same time as I sent my email yesterday:
Code:
$ exim -bpc
returns 870. Probably because there are a lot of bad addresses in the da-announcements list, which was being run at about the same time.

The queue-runn runs every 15 minutes:
Code:
usr/sbin/exim -bd -q15m -oP /var/run/exim.pid
and at this time there are three queue-runners running.

I don't know why it's happening. Do you have any ideas?

I've just sent you another email, from a different return address and through a different server; please let me know by email how it goes through your greylist.

Thanks.

Jeff
 
Are you using the changes to the script? I think perhaps maybe they should be in DirectAdmin as a standard, since they won't hurt anything, even for folk who use php as cgi. What do you think?
I'm not using it since I'm on PHP-CGI and don't need it.
It is true that it won't hurt anything, even with PHP-CGI, FastCGI or anything else, but I think that my script is not very cross-platform: while I'm sure grep, egrep, awk and tr are present in all BSD and linux distributions I know about by default, pstree may not be and ps may have different options in BSD.

But my script can be rewritten by a better programmer and yes, I suggest adding it to DA as a standard feature.

And now on to the mail delivery issue, which I'll keep short since it's only germane to the two of us under this topic.
[...]
I don't know why it's happening. Do you have any ideas?

I've just sent you another email, from a different return address and through a different server; please let me know by email how it goes through your greylist.
My guess is that Exim won't try to send more than X messages a minute, or that that system's load average was higher than the one set in the conf to prevent it from delivering messages: it's a little low by default in your conf, I had to modify it to permit delivery during backups and peak hours on my system.
Your second message was received with an accettable delay, as you can see in my reply :)
 
But my script can be rewritten by a better programmer
and yes, I suggest adding it to DA as a standard feature.
John, What do you think?
My guess is that Exim won't try to send more than X messages a minute, or that that system's load average was higher than the one set in the conf to prevent it from delivering messages: it's a little low by default in your conf, I had to modify it to permit delivery during backups and peak hours on my system.
I'm decidedly old school: email is least important compared to (for example, httpd), so I run it very conservatively.

And ... when I first wrote the file I had no experience with exim; I learned it so I could write the file.

However if you tell me what settings you use, I'll try them on the file I use, and possibly switch to them for the master.
Your second message was received with an acceptable delay, as you can see in my reply :)
Good!

Thanks for your input.

Jeff
 
I just modified "deliver_queue_load_max" (stops any running queue) from 3.0 to 50.0 and "queue_only_load" (puts any incoming message in queue instead of direct delivery) from 5.0 to 100.0; but I have a very high load system, and email delivery is quite critical for me because as a security analyst I've to follow strictly a few security mailing lists. It happened a couple of times that the server had a few problems, the load was high, I didn't notice that I wasn't receiving any email and of course security incidents happened. Murphy is a b*stard.

I guess a normal setting for a 2cores system would respectively be 10.0 and 15.0. This means that if the load is between 10.0 and 15.0 any incoming message is directly delivered but any queue won't run; if it's over 15.0 all is put in queue and stays there, no delivery is performed at all; if it's under 10.0 queues will run and delivery is normal.

This also depends on the number of CPUs/cores, because a load of 4.0 for a 1core means that there is 1 process using the CPU and three waiting, while for a 4cores it means that all processes are accessing the CPU and all is fine. This is also more complicated for linux over BSD, because the linux kernel lists in the load also processes waiting for IO access and not only CPU access... the subject is very complex.

Now I'm way OT, so if you want to discuss this further I suggest creating another thread or discussing it in private ;)
 
Last edited:
Hello,

Thanks tillo, that change looks promising. I did a quick look over it and it looks good. I'm wasn't farmiliar with the $(call) method of embedding, (I use `call`), but I learn something new every day ;) I'll leave this in the wild until it gets a bit of testing, before adding it as default (I'll keep an eye on it as well).

Thanks,
John
 
Back
Top