Hi again! Thanks for your suggestion: the problem does not appear if I *manually* stop cups before executing the update! Maybe the rpm-script does not shut down cups properly if a client is sending a job to the server at that moment... Anyway it's not a "packaging" problem I suppose :o)
Claudio > On Wed Jan 15, 2003 at 11:12:53AM +0100, Claudio wrote: [...] > [...] >> I [15/Jan/2003:10:16:07 +0100] Configured for up to 100 clients. I >> [15/Jan/2003:10:16:07 +0100] Allowing up to 10 client connections per >> host. I [15/Jan/2003:10:16:07 +0100] LoadPPDs: Read >> "/etc/cups/ppds.dat", 1021 PPDs... >> I [15/Jan/2003:10:16:08 +0100] LoadPPDs: Wrote "/etc/cups/ppds.dat", >> 1021 PPDs... >> E [15/Jan/2003:10:16:14 +0100] StartListening: Unable to bind socket - >> Cannot assign requested address. > > This looks to me like cups didn't stop clean before. If it's unable to > bind to the socket, that means something has got a hold of the socket > already, meaning that during the upgrade when cups was supposed to be > stopped, it didn't really stop. IIRC, the initscript tries to kill the > cupsd based on the pid in the /var/run/cupsd.pid (or whatever) file. If > that file is removed, you effectively have a cupsd that is not > controllable via the initscript (initscript thinks cupsd is already > stopped because the pid file is no longer present). > >> Downgrading to 8.2 "original" packages, server comes back working >> fine! > > Try what I suggested above. I'm quite certain there should be nothing > wrong with these cups packages as I tested them here and was able to run > them and print through them. IIRC, I didn't have cups previously > installed/configured, so there might be some strangeness with the > upgrade that I missed, but I don't think so. The bind socket error > tells me something different. --
