1.3-Beta2 cups problem

[scottro]

I was unable to add a printer through KDE (it went through the entire sequence, then at the end, said it was unable to connect to the print server.) I then tried with the cups web interface. This also failed, freezing when I filled in the IP address (I was using socket://<JetDirect address>.) At this point, it began sucking up processor time, and the system almost froze. After a painfully long wait, a terminal opened and I was able to kill the cups daemon.

After this, I added the printer from the command line with lpadmin. However, when I tried to print, I got an error message that the printer process was not running. I then began to suspect what had been a common error with CUPS and FreeBSD (though I believe the present port gives you an option to fix the issue.)

There is an lp and lpr command in /usr/bin. This would work for the Unix LPD daemon. CUPS uses /usr/local/bin/lp and /usr/local/bin/lpr. Doing

echo hello | /usr/local/bin/lp -d HPDJ (the name of the printer) enabled me to print.

In FreeBSD at present, when installing cups, there is an option to build the port with CUPS_OVERWRITE_BASE. This solves the problem. (It can also be put in /etc/make.conf )

Obviously, it will be a bug for any newcomers trying to print. If they are able to add a printer through one of the gui interfaces, it won't print.

Thanks.

[Charles]

Thanks, Scott, problem reported to the team: http://bugs.pcbsd.org/bug.php?op=show&bugid=271&pos=3

[scottro]

And thank you (as always) for all your work. I have done nothing to fix the problem right now in case you wish any sort of testing done. In general, the way I fixed it (before discovering the CUPS_OVERWRITE_BASE thing) was as root or with root privilege

cd /usr/bin
mv lp lp.bak
mv lpr lpr.bak
ln -s /usr/local/bin/lp
ln -s /usr/local/bin/lpr

However, this is simply a test box, so I can leave it alone, or quickly throw on a repaired beta 3. :)

[dracheflieger]

Another Thanks for finding this problem scottro. This is another big step toward an acceptable desktop replacement.

[Charles]

Thank you Scott, I updated the bug report with the fix.

[scottro]

I should add that I consider that workaround a kludge and nothing more. For one thing, it will be overwritten each time you upgrade world, unless you remember to add NO_LPR= to /etc/make.conf

As I said, the cups port--actually, /usr/ports/print/cups-base--has an option

CUPS_OVERWRITE_BASE

This will fix the problem and is probably the way to go. Unfortunately, I'm not skilled enough at Makefiles to figure out exactly how it works, but hopefully, someone with more programming or scripting knowledge can do that.

Of course, it should be done during installation, so that the user doesn't even know about it.

Charles (to salvage my reputation) please do add that I consider it a kludge, not a real solution to the bug report. :)

If I were running an actual workstation here, I would forcibly reinstall the port, probably using Doug Barton's portmaster which is fast becoming my favorite port manager, with the CUPS_OVERWRITE_BASE option.

I didn't do that last night because a) it was late and I was tired b) this is a test box and c) that I wanted to leave it in more or less pristine condition if you guys had some fixes you wished me to try.

(At this point, I haven't even moved /usr/bin/lp and lpr to lp.bak and lpr.bak.)

Thank you for your efforts. I think it is great the way you guys put so much of your energy into this, and it's one reason I'm happy to help when I have a little time.

[jdarnold]

But what other effects does that option have? Many people have gotten cups to work without that option. Is it an either / or, where it will work for some, but make it stop working for others? Or is it a reasonable widespread solution if you want a turnkey box? I got cups to work and I didn't define that option. At least I don't think I did!

[scottro]

Jonathan, are we talking the 1.3 beta2, as is, from first installation? In my case, I had a /usr/bin/lp and /usr/bin/lpr that were there upon first boot. Those are the files that will cause the problem.

Assuming the user wants to use cups, the CUPS_OVERWRITE_BASE option will do nothing that they can see.

IF the user wishes to use another Unix printing system, such as LPRNG, or something else, including the old standard lpd, yes, it would mess that up.

My feeling (I'm not a developer or part of the PCBSD team) is that PCBSD's intended audience will probably be happy with CUPS being the default. Hard cores who wish to use something else would (if the OVERWRITE_BASE thing was standard) have to do a bit of fairly easy hacking.

[TerryP]

IIRC doesn't cups by default place it's lp/lpr into /usr/local/bin ? hence the base overwrite.

I remember having to deal with some thing like that because my FreeBSD box would find the standard ones in the search path instead of the cups ones.

[scottro]

Terry P. exactly. That's what happened on this installation. (Which is why I am asking Jonathan if he installed beta-2 without having this problem. I don't think I chose anything weird during installation. However, it does intrigue me that I'm not seeing more "me too" posts, and it's making me wonder if, one way or another, something simply got b0rked during my installation..

As the basic install is, of course pretty quick, I'll probably install again and confirm that this is happening each time. (Right now, I couldn't resist--as it's a test box, I'm trying the upgrade to xorg-7.1 to see how many things get broken.) :)

[Charles]

Charles (to salvage my reputation) please do add that I consider it a kludge, not a real solution to the bug report. :)

No, I won't.
Just kiddin' I added a note: http://bugs.pcbsd.org/bug.php?op=show&bugid=271
;)

[rodonn]

So it's an inconsistent problem?

[scottro]

I don't know. Has anyone else had the problem? I think I should probably do another install and see if the problem reoccurs. However, I just put in xorg-7.1 so I want to test that first.

[TerryP]

cc

[rodonn]

cc?

[Charles]

cc!

[scottro]

I too wonder what cc is.

Ok, I just did a fresh reinstall.

Upon boot, cups is running.

If I try to add a printer from the cups web interface, it is normal until I get to adding the socket--where it asks for the type of connection, in this case a jetdirect--then, it takes literally 2-3 minutes to move to the next step, which was choosing manufacturer. Then, I chose HP, and at that point, it timed out.

I then tried the KDE interface. I put in the root password to run in admin mode. However, it says it couldn't reach the cups server, make sure cupsd is running (which a pgrep cupsd shows to be the case, cups is running.)

So, I did it the way I would normally do it, lpadmin -p HPDJ, -E -v socket://192.168.7.50 -m deskjet.ppd.
However, if I then try to print something, e.g. echo hello | lp -d I get the messages

lpr: Unable to connect to /var/run/printer: No such file or directory
lpr: Check to see if the master 'lpd' process is running.
jobs queued, but cannot start daemon.


If I do echo hello | /usr/local/bin/lp -d HPDJ it prints.


Now, once I have added the printer in that way, it will print from graphic applications successfully--not knowing that much about KDE, I'm guessing that KDE passes it correctly to cups.

If this were a workstation, then I would fix it by doing portupgrade -f -m -DCUPS_OVERWRITE_BASE cups-base. (That's untested on this install).

[TerryP]

"cc" is an ASCII repisentation of a communications thing in the Special Forces.

cc == click click && copy/roger that.

Some times you can't speak without giving away your position but need to ack. An some thing over the com, hence you click your throat mic twice so the other end heres it but the X-Ray walking 2 metres away won't so readily :-)

It's a thing that kinda got picked up by my team some how hehe, we do model our selfs after the British SAS and use CQB tactics ya know :-P


Now if only I'd stop trying to type in seamonkey like it was vim....

[ejh13m]

The following is from the error message I got trying to get CUPS to work on 1.3 "Unable to retrieve the printer list. Error message received from manager:
Connection to CUPS server failed. Check that the CUPS server is correctly installed and running. Error: localhost: read failed (14)."

I did not have this problem with 1.2 even with the latest port. This has happened with 3 different downloads. Except for this, I've experienced no problems with PCBSD 1.3 at all.

[jdarnold]

That cups error sounds like the same error I was getting before I got it set up write. You need to set up a printer via the cups web interface before you can connect to it via KDE. If you don't, you get that very mysterious error, because there isn't yet any printers for it to list.

[scottro]

Jonathan, what I have been finding is that I can't set up cups with the web interface. This is after reinstalling a few times, and the problem was consistent.

It works normally until I get to putting in the socket://<ipaddress>. At that point, it takes several minutes, literally, before moving on to the select printer part. At that point, I was only able to select HP, and again, it hung for several minutes. Eventually, it gave me a timeout error, so I used lpadmin.

lpadmin works quite well, and after that, as mentioned in my previous post, I can print from gui applications--at least from konqueror--I don't know what would happen if I try to print from another browser. I can't use lp at the command line however, unless I do something about the /usr/bin/lp $PATH.


Hrrm, as I write, I don't know if I changed my hostname on these installs. (As I've been doing several installs, testing different things, including the xorg-7.1 upgrade, I haven't set up each install as I would a workstation.)

I will doublecheck that tonight. I'm not sure if /etc/hosts would be a factor with that.

[TerryP]

I wonder if this could be related ? (http://forums.pcbsd.org/viewtopic.php?t=6437#39399)

[scottro]

I'm not sure. I now have /etc/hosts correctly setup for 127.0.0.1 but still get the same error--it gets very slow after entering the socket type and IP addie, and then times out when I'm trying to select the driver. I get as far as selecting HP, and, before opening the list of drivers, it does it's time out thing.

So for the moment, I would consider it a bug if a few people are having this problem, but that's more for the developers to decide.

I don't ~think~ I"ve missed anything obvious. Usually, on FreeBSD, I just set it up with lpadmin. (Which also works here, on PCBSD.)

[rodonn]

It ran like a dog on my 1.2 (Icy Steel) install... 1.3 seems about the same

I'm running on a PIII 400 with 256m Ram

[rodonn]

OK, I can configure my CUPS printer and (thanks to J Arnold) I can print via Samba to a Windows queue

Only thing I can suggest is make sure that there nothing heavy running in background.

[TerryP]

I guess that means killing KDE and going to a console :-)

Not to jab at lovely P3 that is.

[jdarnold]

Yeah, I don't know about those direct connect network printers. I've only used it (and been succesful) with printers connected on a Windows box. Not sure why that would be a problem though.

I haven't tried it with the 1.3 beta yet. Still playing with various installation options.

[rodonn]

Well, it's slowwww but it works... hence my other question about whit 1.2/1.3 both give me different CUPS versions between the CUPS localhost interface and the KDE printer test page...

and KDE, when it's doing nothing but repainitng the clock doesn't take up that much resource...

[jdarnold]

Okay, I've been playing with CUPS on my test machine (woo hoo what joy) and I'm pretty sure I know what one major problem is on a slow machine like mine (900mhz "overclocked" celeron) - there are just too damn many printers in the data file and it takes too long for cups to list them all via the browser and the browser times out. The ppds.dat file is over 22mb in size and the number of printers in it is a bunch. That's why when you first type in the URI for the printer it takes a god-forsaken long time to come back, as it is busy parsing the file.

I'd love to know of some way to trim that file. I certainly don't need to list every printer ever made in the last 10 years.

[rodonn]

Yet I get it up on my PIII 400...

[scottro]

However, comparing the web interface with CURRENT or 6.2-PRE-RELEASE, the only two things I have running X, I have got to say something is wrong here. It shouldn't be taking that long to go the local host, put in the socket and then time out when searching the ppd's.

Ok, I'm going to say I was right, there is definitely something wrong with cups in this beta.

I would say there are three problems, though only two will affect the newcomer.

Problem one, printers can't be added from KDE interface, the user gets a message, can't reach server, are you sure cups is running.

Problem two, if one does add a printer though cups, either by web or command line, the standard lp command doesn't work. (the typical newcomer probably won't be affected by this one though.) Reason:
The lp binary is in two places, /usr/bin/lp, which is the LPD daemon, and /usrlocal/lp which is the cups binary.

Workarounds are to adjust your $PATH to put /usr/local/bin before /usr/bin or to reinstall cups from ports and adding the CUPS_OVERWRITE_BASE option when installing cups-base. (That option is only, AFAIK, available in the cups-base port, not the cups port.)

The other option is to delete or rename /usr/bin/lp and /usr/bin/lpr, but this will be overwritten if you update world, unless (perhaps, this is untested) you add the option NO_LPR= in /etc/make.conf

Problem 3, with the web interface, it si very slow, often to the point of timing out.

[rodonn]

Doesn't the 6.2PR have a load of debugging code in it?

[scottro]

Probably on by default (I'm on a machine running CURRENT at the moment) however, I usually remove that with the custom kernel.

Regardless, (I'm not sure if this is the question) on CURRENT and PR, the cups web interface works at a normal speed, even if one has installed all the foomatic ppds.

[Rus]

If this is truly the case, then modularity is likely the key. Please follow along - it's a little wordy but might be a logical solution. I'd like feedback as to my logic.

Problems with CUPS (also across more than just BSD, includes Linux, etc.):
Too large of a data file.
One vendor listed as many (HP, Hewlett-Packard, Hewlett Packard, etc.)

It's somewhat annoying to find that a printer is listed under HP and not Hewlett-Packard, or otherwise. This isn't very easy for new users in particular.

Also - when the user is selecting a printer, large file sizes could be very easily fixed by having one file for each manufacturer. As more and more hardware items are added to any particular driver database, parsing large files becomes a problem, as noted. There is nothing preventing CUPS from having a Lexmark file, an HP file, and so on.

Further, no matter if the device identifies as HP or Hewlett-Packard, this process should be transparent to the end user. It's polishing these small details that make any particular operating system more attractive to the end user.

Also, since printers are only added one at a time, having multiple modular files should enable all to add their printers as needed.

There are other advantages to this sort of modularity.

Rus

Okay, I've been playing with CUPS on my test machine (woo hoo what joy) and I'm pretty sure I know what one major problem is on a slow machine like mine (900mhz "overclocked" celeron) - there are just too damn many printers in the data file and it takes too long for cups to list them all via the browser and the browser times out. The ppds.dat file is over 22mb in size and the number of printers in it is a bunch. That's why when you first type in the URI for the printer it takes a god-forsaken long time to come back, as it is busy parsing the file.

I'd love to know of some way to trim that file. I certainly don't need to list every printer ever made in the last 10 years.[/i]

[dracheflieger]

Good points all Rus...either modules or a relational database would fix many ills associated with the long load time and errors.

[magus1011]

Well, here's a Me To post.

I installed PC-BSD 1.3 RC1 and am having this exact problem. I have a HP LaserJet 1018 printer and this problem has been bothering me since I installed. I didn't know about lpadmin so I've just been trying the install on the menu's.

I noticed that Kahn is available so I'm going to download and burn the two CD's and reinstall. The reason I'm reinstalling is to clean up the mess I made in my last reinstall. :oops: I'm learning, but it takes time. :) I do hope the problem is fixed in Kahn, but if not then I can run lpadmin and hopefully fix the problem.

--
Regards,
Magus.