Gerard Seibert wrote:
> Matthew Seaman wrote:
> 
>> Ummm... given that there's no 'rm' capability in this printcap I guess you
>> must be using Samba to communicate with the remote windows printer.  If so,
>> then that printcap looks fine.  Well, setting lp=/dev/null seems to cause 
>> some complaints, but that should just be cosmetic.
>>
>> I'd start looking for problems in the Samba setup.  Can you use smbclient to
>> connect to the printserver machine via Samba using the credentials you gave
>> in the apsfilter setup?  Does it show that you have access to the shared
>> printer there?
>>
>> Double check the contents of /usr/local/etc/apsfilter/SETUP.cfg and the
>> apsfilterrc files in that directory and it's sub-directories.  
>>
>> Also, is there anything interesting in the log file /var/spool/lpd/lp/log ?
> 
> Nothing other than this from the lpd-errs file produced when
> 
>      'checkpc -fV' 
> 
> is run.
> 
> lpd-errs:
> 
> Aug  9 13:06:09 scorpio checkpc[6018]: lp: Checkwrite: fcntl F_SETFL of
> '/dev/null' failed - Inappropriate ioctl for device
> 
> Aug  9 17:18:57 scorpio checkpc[14219]: lp: Checkwrite: fcntl F_SETFL of
> '/dev/null' failed - Inappropriate ioctl for device
> 
> I can connect using smbclient without any problems. The problem is not
> there. The is just not connection with the print server, and that is
> what I cannot understand.
> 
> I had the same problem with an install of 5.4. One day that message
> started being printed in the log and I could no longer print. I was
> forced to do a total reinstall of the OS. I really believe that the
> '/dev/null' thing is the key to this, but I do not have a clue how to go
> about fixing it. I have a bad feeling that I am going to have to do a
> total reinstall of the OS. With KDE, OpenOffice etc., that will take
> awhile.
> 
> Unless you have a better idea Matthew, I will probably go that route
> this weekend. I do not need another over sized paper weight.
>

Woah! Reinstalling the whole OS to fix a printer problem is way overkill.

The /dev/null entry in /etc/printcap is just a place-holder.  Normally
that entry would contain the device used to communicate to a locally
attached printer.  However, because you're using samba, you've faked the
system into thinking you've got a local printer, while using a print
filter to divert the data via samba into the remote Windows printer.
It's a bit of a hack really.

However what it does mean is that no data should actually end up being
passed to /dev/null.  As the print system is complaining about not being
able to get an exclusive lock on that file, perhaps it would be worth
trying substituting some regular file that it could get a lock on.  Try
this.

    # touch /var/log/lpd.out
    # chmod 644 /var/log/lpd.out
    # chown root:daemon /var/log/lpd.out

Then edit /etc/printcap and substitute /var/log/lpd.out for /dev/null
and restart lpd.  lpd.out should just stay an empty file, but it might
end up with a copy of anything you send to the printer in it, in which
case siccing newsyslog(1) onto the file to keep it a manageable size
would be a good idea.

If this works, then reporting what happened to the port maintainer and
author of apsfilter would be indicated -- seems the behaviour of
/dev/null has changed in recent releases sufficient to put a spanner in
apsfilter's works.

        Cheers,

        Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       7 Priory Courtyard
                                                      Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey         Ramsgate
                                                      Kent, CT11 9PW

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to