On Fri, 15 Feb 2002, Garance A Drosihn wrote:
At 3:16 PM +0100 2/15/02, Konrad Heuer wrote:
Unfortunately, some changes in the lpd code that happened last year
(as far as I remember) are very disadvantageous for the operation
of our (heavily loaded) printer server which is based on FreeBSD
for years now.
Well, I'm willing to see what we can do to help you out.
Thank you very much for your reply and all your efforts. Please excuse my
delayed reply but I didn't read my mail yesterday and the day before.
Prior to the changes, we could observe the progress of print jobs
by a `tail -f /var/log/lpd-err/queue_log_file'. Now, all information
written by the filter programs to stderr gets catched by temporary
log files the names of which are created randomly. After a print
job has completed, the contents of the temporary file is appended
to the queue log file.
Hmm. I suspect that any change there is more than a year old. We
did change how the temporary-files were generated, but I think lpd
has used temporary files for stderr for a long time.
I didn't look into earlier versions of the code, I've to admit.
Nevertheless, the tail -f did work. Hmm, sounds strange.
For our purposes, that's often too late. Why have these changes
been made? And can the old behaviour be restored?
I think the reason it's done this way (with the temporary files) is
so multiple queues could point to a single log file, and so all the
lines for any one job would be added onto that log file in one shot.
I think there's a number of other reasons too. A quick look at
the history for lpd/printjob.c seems to indicate that it has
always behaved this way (or at least, it was always the *intention*
that it behave this way, perhaps there were some bugs fixed).
This may be. On the other hand, on a system with a large number of printer
queues (about 120 in our case) I'd never get the idea to use a single log
file ;-).
We really would like to see what happens during printing a job
(imagine a 300 mb postscript print job which may a lot of time
to execute completely).
Well, here we see 1-gig postscript files going to our plotters, so
it's pretty easy for me to imagine a 300-meg one... :-)
I see and I'm pleased you understand me!
It's obvious that you just changed to a new version of lpr. Did
you also change any of your scripts? In some of my scripts, what
I do is:
exec 2$LPD_LOG_dir/$pname/log
This causes the *script* to redirect stderr to where I want it.
Would that work in your situation?
I got this idea this morning in bathroom, too. I hope it will work in our
situation.
By the way, may I suggest some other modifications to the lpd code? I know
my suggestions might introduce problems with existing input filters, but I
apply these changes to printjob.c for years now and I'm very happy with
them:
*** /usr/src/usr.sbin/lpr/lpd/printjob.cFri Feb 15 14:42:18 2002
--- /usr/src/usr.sbin/lpr/lpd/printjob.c.orgThu Dec 20 05:14:26 2001
***
*** 600,606
register char *prog;
int fi, fo;
FILE *fp;
! char *av[20], buf[BUFSIZ]; /* GWDG: size of av increased */
int pid, p[2], stopped;
union wait status;
struct stat stb;
--- 600,606
register char *prog;
int fi, fo;
FILE *fp;
! char *av[15], buf[BUFSIZ];
int pid, p[2], stopped;
union wait status;
struct stat stb;
***
*** 757,763
pp-printer, format);
return(ERROR);
}
- prog = pp-filters[LPF_INPUT]; /* GWDG: quick dirty: always use if */
if (prog == NULL) {
(void) close(fi);
syslog(LOG_ERR,
--- 757,762
***
*** 772,782
av[n++] = -n;
av[n++] = logname;
av[n++] = -h;
! av[n++] = class; /* GWDG: use traditional class instead of origin_host */
! av[n++] = -f;
! av[n++] = origin_host; /* GWDG: pass origin_host to filter additionally */
! av[n++] = -j;
! av[n++] = jobname; /* GWDG: pass jobname to filter additionally */
av[n++] = pp-acct_file;
av[n] = 0;
fo = pfd;
--- 771,777
av[n++] = -n;
av[n++] = logname;
av[n++] = -h;
! av[n++] = origin_host;
av[n++] = pp-acct_file;
av[n] = 0;
fo = pfd;
We need the traditional possibility for users to enter a class
specification by the `-C' flag of lpr which is then passed to the filter
script. But we need a reliable information about the origin of a print job
in the script, too. Furthermore, it's very nice to know the name of the
job within the filter script not only for logging, but also for PostScript
header page generation. The quickdirty hack to force execution of the
input filter helps us since people tend to use lpr flags like `-d' or `-v'
accidently. Maybe one could turn this qd hack into an lpd command line
flag
