Date: Mon, 18 Feb 2002 09:43:27 +0100 (CET) From: Konrad Heuer <kheuer@gwdg.de> To: Garance A Drosihn <drosih@rpi.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lpd & filter stderr & log files Message-ID: <20020218091439.M38497-100000@gwdu60.gwdg.de> In-Reply-To: <p05101403b893034f8043@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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.c=09Fri Feb 15 14:42:18 2002
--- /usr/src/usr.sbin/lpr/lpd/printjob.c.org=09Thu Dec 20 05:14:26 2001
***************
*** 600,606 ****
=09register char *prog;
=09int fi, fo;
=09FILE *fp;
! =09char *av[20], buf[BUFSIZ]; /* GWDG: size of av increased */
=09int pid, p[2], stopped;
=09union wait status;
=09struct stat stb;
--- 600,606 ----
=09register char *prog;
=09int fi, fo;
=09FILE *fp;
! =09char *av[15], buf[BUFSIZ];
=09int pid, p[2], stopped;
=09union wait status;
=09struct stat stb;
***************
*** 757,763 ****
=09=09=09pp->printer, format);
=09=09return(ERROR);
=09}
- =09prog =3D pp->filters[LPF_INPUT]; /* GWDG: quick & dirty: always use if=
*/
=09if (prog =3D=3D NULL) {
=09=09(void) close(fi);
=09=09syslog(LOG_ERR,
--- 757,762 ----
***************
*** 772,782 ****
=09av[n++] =3D "-n";
=09av[n++] =3D logname;
=09av[n++] =3D "-h";
! =09av[n++] =3D class; /* GWDG: use traditional class instead of origin_ho=
st */
! =09av[n++] =3D "-f";
! =09av[n++] =3D origin_host; /* GWDG: pass origin_host to filter additiona=
lly */
! =09av[n++] =3D "-j";
! =09av[n++] =3D jobname; /* GWDG: pass jobname to filter additionally */
=09av[n++] =3D pp->acct_file;
=09av[n] =3D 0;
=09fo =3D pfd;
--- 771,777 ----
=09av[n++] =3D "-n";
=09av[n++] =3D logname;
=09av[n++] =3D "-h";
! =09av[n++] =3D origin_host;
=09av[n++] =3D pp->acct_file;
=09av[n] =3D 0;
=09fo =3D 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 quick&dirty 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 q&d hack into an lpd command line
flag which enforces input filter execution independent of what the control
file says?
Thank you very much for your reply again; and please let me know if can
help in any way.
Best regards
Konrad Heuer Personal Bookmarks:
Gesellschaft f=FCr wissenschaftliche
Datenverarbeitung mbH G=D6ttingen http://www.freebsd.org
Am Fa=DFberg, D-37077 G=D6ttingen http://www.daemonnews.o=
rg
Deutschland (Germany)
kheuer@gwdg.de
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020218091439.M38497-100000>