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

[Mauro Santos]

On 08/09/2010 01:20 PM, David C. Rankin wrote:
> 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?
> 

I'm not an expert but as I see it you should have seen it coming,
backgrounding the daemons is ok as long as the daemons you background
are independent.

On the listening port issue, you did that to yourself, you must have
explicitly configured cups to listen on port 443 and you configured
something else to listen on the same port, only two outcomes are
possible, either the applications fail gracefully and move on the best
wait they can or they will explode and refuse to work (which is always
lots of fun). Besides you should have noticed before that something
wasn't right, you did test your system to check if all the
functionalities you wanted to be working were actually working, right?

I guess now you know you can't have two programs listening on the same
port(s) and it's the sysadmin responsibility to assure that doesn't
happen or deal with it when the sticky smelly stuff hits the fan.

-- 
Mauro Santos