Bug 299092 - lpr/lpd does no longer print since D55399
Summary: lpr/lpd does no longer print since D55399
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 14.5-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: Dag-Erling Smørgrav
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2026-10-03 13:01 UTC by Peter Much
Modified: 2026-10-06 14:54 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Much 2026-10-03 13:01:50 UTC
After discussing the matter in the forum, I found interest in lpd being larger than I expected, so this warrants a PR.

D55399 started to replace the filename of the printjob spoolfile with the name of the actual authenticated remote interface name from which the job was sent.

Formerly the filename was decided by the remote sender, and it can be anything:
lpd itself uses the remote hostname (which is NOT an interface name, and by mixing both you will break any sites with more than one interface), CUPS uses some FQDN hostname that is truncated after 15 chars.

While I agree that it is a good idea to not simply believe in filenames coming from remote, it just doesn't work that way. Because the controlfile itself contains the same name, and this is then used to print and delete the job.
So, in order to change that name, we would need to parse the controlfile and replace all occurrences of the name - which is currently not done, and so the jobs do not print and accumulate in the spooldir.

For now I just reverted that part of the change, to get things working.

Discussion:
https://forums.freebsd.org/threads/lpr-lpd-is-now-really-broken-in-14-5.103981/
Comment 1 Greg Balfour 2026-10-06 14:54:42 UTC
I have the same problem.  My work around on a binary only system (no /usr/src) was to copy /usr/sbin/lp* from a 14.4 system.