System :: CUPS

I have the same problem. The "...the connection was refused....localhost:631" (and equivalent if using Dillo) is, in my case, because the cupsd daemon is not running.The way to get it running SHOULD be (with root authority) /etc/init.d/cupsys start
but this doesn't work for me   .
Also the system should start cupsys anyway as I have the appropriate links in    /etc/rc4.d    and    /etc/rc5.d    but it doesn't start.
Yet the automatic start does work for the ekpd daemon for the ink monitoring of my Epson Printer
It may, or may not, be related to the fact that I am using CUPS from Debian Sarge 3.1release0 re-mastered in to the system. Perhaps somebody (better-informed than myself!)  could say whether some special DSL tweak is needed   .
My next step is to try cups.dsl instead of a re-mastered installation of Sarge CUPS.

OK - progress update:- Using the cups.dsl I find that it puts myDSL -> Cups ->  into the fluxbox menu, from which I successfully started the cupsd daemon, and then was able to get to printer administration via Cups Admin .
(Now we're getting out of scope of System, as distinct from Printer, forum topics but I'll mention some tricky following issues for completeness.)
The CUPS management in Dillo puts up an un-informative (see Eric S.Raymonds 'rant' on the subject !) authorisation login screen.
To let user dsl (rather than root) use this, add dsl to the lpadmin group thus using a root console

Code Sample

adduser dsl lpadmin

and define the dsl password thus

Code Sample

passwd dsl

Good luck  !

Correction to my previous post Dec.21 07:26 :-
Where I wrote "Dillo" I should have written "Firefox". (I was thinking of Feather Linux, where the permissions somewhere must be more relaxed and Dillo can be used as well as Firefox. The set-up in Damn Small Linux is more 'conventional' CUPS in this respect) .  

I've now noticed what may have been the cause of the original posted problem; after starting CUPS, for a few minutes the cupsd daemon uses almost 99% CPU.    During this time connections to localhost:631 are refused.
After leaving the system to settle for a while (I don't quantify how long as I expect that it will be dependent on the specific host system) CPU Usage falls back to normal levels, and CUPS Administration is possible.