[arch-general] mayday - new updates killed httpd - make_sock: could not bind to address [::]:443

David C. Rankin drankinatty at suddenlinkmail.com
Mon Aug 9 08:20:28 EDT 2010


On 08/09/2010 05:00 AM, Jan de Groot wrote:
> First of all, why don't you fix that annoying error
> with /etc/rc.d/functions.d that pops up on every rc script invocation?
>

OK - you're on, don't keep me in suspense, just go ahead and tell me what notice 
I missed that says do X or Y to fix the very annoying /etc/rc.d/functions.d that 
pops up with every init...

I thought that was a side effect of the bashification of the init scrips and 
that an update would fix it? wrong?

> As for cups: the default cupsd.conf contains "Listen localhost:631" and
> "Listen /var/run/cups/cups.sock". I think your cupsd.conf contains an
> entry for 443 also there.

Damn, your clairvoyant:

#
# "$Id: cupsd.conf.in 8805 2009-08-31 16:34:06Z mike $"
#
# Sample configuration file for the CUPS scheduler.  See "man cupsd.conf" for a
# complete description of this file.
#

# Log general information in error_log - change "warn" to "debug"
# for troubleshooting...
ServerName nirvana.3111skyline.com
ServerAdmin david at 3111skyline.com
ServerAlias nirvana
ServerAlias www.3111skyline.com
ServerAlias localhost
# Allow remote access
Port 631
SSLPort 443
<snip>

now
#SSLPort 443

I have no recognition of making that change and don't know why I would have done 
that. Could that be a host:631 cups auto setting in response to some other 
selection?

The problem with your setup is that your setup
> relies on a failure: apache binds to https before cups can, so cups
> doesn't bind to 443 anymore.

(I see that)

Because you're using backgrounding, any
> update to your system can interfere with timing and cause issues like
> these if your configuration is not right.
>

Yes, I'm using backgrounding and my config hasn't changed since I first started 
using Arch and was done in response to a post here pointing out that it was 
recommended to bring up hal in the DAEMONS line and then background everything 
thereafter up to your display manager. Was that advise incorrect?

I have been running with the following:

DAEMONS=(syslog-ng network hal named @netfs @ntpd @sshd @dhcpd @crond 
@avahi-daemon @postfix @mysqld @dovecot @httpd @hylafax @samba @cups @sensors 
@upsd kdm)

What needs to be changed?  Or -- where is an Arch reference that provides the 
pros & cons of backgrouding the various processes?

I guess I have been lucky because Arch has been bullet-proof since April '09 as 
my primary server. Last night was the first DAEMONS issue I had run into except 
for the little 'display manager respawning too fast' nit.

What say the experts on the backgrounding issue?

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com


More information about the arch-general mailing list