This kind of problem is usually related to a DNS timeout, which occurs outside kdeprint's code and is hence difficult to control. What you can try is to add the server name as en entry to /etc/hosts to avoid a full DNS lookup when you're offline. Does this help?

Yes, I added the print server to /etc/hosts and then kdeprint initialized ok. My complaint isn't that it should time out faster, but simply that while trying to initialize, I should still be able to change settings (such as the print server).

I know the problem, but the fact is that this happens outside KDE, somewhere in the CUPS library. Does "lpstat -h <server> -a" works OK when you're offline even if you don't have the additional entry in /etc/hosts (use the actual server name instead of <server>)?

Sorry it took me so long to get back to you. When I do an lpstat -h <server> 
-a, it just reports that it cannot connect to the server. As I've said 
before, just adding the entry to /etc/hosts as a local address fixed the 
problem, and I understand it's not really a KDE issue. However, isn't it 
possible to just spawn a thread that tries to connect to the print server 
while the rest of the module (at least the configuration buttons) carry on? 
Thanks for the help!

-James

On Tuesday 28 September 2004 01:18 am, Michael Goffioul wrote:
> ------- I know the problem, but the fact is that this happens outside KDE,
> somewhere in the CUPS library. Does "lpstat -h <server> -a" works OK when
> you're offline even if you don't have the additional entry in /etc/hosts
> (use the actual server name instead of <server>)?

I too have this problem but I'm not connected to any printers on a network, this is merely my home desktop.  I can not get print manager to stop initializing CUPS.  I kill the window and when I reopen it, it freezes again because it tries to initialize.  Any suggestions?  There should be a time out window that pops up...

UNCONFIRMED (batch reassigning messed this)

I have this problem too. After I disconnected physically from LAN  and installed a new printer for localhost, an other user is unable to print. When I start kcontrol/printer as this user, the "Initializing Managers" appears and "hangs for ever".
Looks like CUPS is searching the old printer, because there's <old-IP>:631 below.
After I changed the CUPS-Host in /home/<this user>/.kde/share/config/kdeprintrc  to 127.0.0.1 everthing works fine.

my suggestion, but it might be a stupid one: a "skip"-button
maybe this bug isn't the right place. Should we formulate a "wish"?

Yours Chrisch

I've started noticing this with KDE3.5 (it didn't happen before).

I have a remote print server (actually, in the same room, on the same subnet).  The host is declared in the /etc/hosts file.

The strange thing is that this only happens every other time.  It works once, and then the next time I try to print, it hangs.  I kill it, and try again, and it works.  Next time, it hangs.  Etc, ad nauseum.  It is, in this respect, reproducable.  I can even open three different Konqueror windows to the same document.  Opening the print dialog on the first is OK; opening it on the second hangs; opening it on the third is OK.  There are no errors being dumped to .xsession-errors relating to this.

In my case, it has nothing to do with the print server (AFAICT) being off-line -- I can always access the CUPS server via http://192.168.1.2:631, even while KDE is hanging, and as I said, while one process is hanging I can open print from a second Konqi instance -- and it has nothing to do with DNS, unless KDE is trying to route around the /etc/hosts file and get DNS info for my subnet entries every other time.

Again, I didn't see this problem with KDE3.4; the upgrade to 3.5 is the only thing that has changed in the equation.  There have been no software upgrades on the server; it is possible that CUPS on the client was upgraded, but why would that matter?

As an aside, I think the original poster had a point about the fact that the entire print system is off-line if something happens to the network.  This means that, even if all you want to do is print to a PDF, the KDE print system locks up if there is a network problem.

--- SER

Something else I've discovered: this hang-up, as I said, happens reliably, exactly, every other time.  For instance:

1) Open konqueror
2) Print (OK)
3) Print (hang)
4) Kill konqueror; open konqueror
5) Print (OK)
6) Print (hang)

But only if I print from the same instance of Konqueror.  If I do the following, I experience no hangs (yet):

1) Open konqueror
2) Print (OK)
3) Open a new instance of konqueror
4) Print (OK)
5) Repeat open, print (OK)
6) Print from an already printed instance (hang)

So, it appears that the second time a given Konqueror instance tries to initialize the print system, it hangs.

--- SER

One more point: it isn't just Konqueror that exhibits this behavior; KWord (1.4.2) also hangs exactly every other time, unless I exit and restart it.

Is anybody looking at this bug?

--- SER

Created attachment 14649 [details]
KDE freeze when you open print command without printer

I have this problem in KDE 3.5 too except it happens every time I try to print something while running KDE (i.e. I can't print while running KDE).  When I go to the Printer Settings, it hangs at "initializing manager ... " and I have to kill the application.  In Gnome printing is not a problem, cups and samba are working fine.  Are there any solutions to this problem?

Thanks!

Should you ever re-encounter that problem, then switch the print subsystem plugin away from CUPS (for instance to "Use external program" or "LPD").

To change it, there are different ways:

 * either expand the print dialog dialog fully and use the list selection on
   lower right corner of dialog; 

 * or edit your $(kde-config --localprefix)/share/config/kdeprintrc file to
   add a line "PrintSystem=ext" in the "[General]" section.

Cheers,
Kurt