On Sun 10 Dec 2017 at 19:33:58 +0530, P V Mathew wrote:
On 2017-12-10 18:41, Brian Potkin wrote:
Part of your log has
DEBUG: envp[1]="CONTENT_TYPE=text/plain"
CUPS has identified the job as being a text file. All the filters
complete successfully and the output is a PostScript file. All is
well with the cupsfilters command - but now I am mystified.
cupsfilter does the same as CUPS except the final file is not sent
to a printer. 'lp -d <queue name> filename.ps' gives
Unsupported document-format "application/octet-stream"
and this is an indication of CUPS being unable to MIME type the
submitted file. But it has MIME typed it with cupsfilter!
I can reproduce your observation of the error message by moving
mime.types out of /usr/share/cups/mime, but then cupsfilter fails
to run to completion. I cannot reproduce the empty error_log you
get; mine records the error. That's using my cupsd.conf.
I take a further look at the issue later today. Meanwhile you could
check that the files in /usr/share/cups/mime are what is in the
cups-core-drivers and cups-daemon packages.
Have checked files in /usr/share/cups/mime.
Other than cups-core-drivers and cups-daemon packages
there are some more files in the directory.
attaching listing of the directory. Only issue is that some
.convs(cupsfilters-ghostscript, cupsfilters-mupdf, cupsfilters-poppler)
files do not have have the corresponding .types
files and command.types does not have any corresponding
command.convs.
Nothing to worry about there; I have the same.
Also the issue of connection getting reset on trying
http://localhost:631 stil remains. This will mean that
I will not be able to do any printer administration.
Has this been mentioned before? There are command line utilities to do
printer administration.