It's likely that you have been bitten by
6526418 netpr dumps core when protocol is tcp and port number is missing
http://bugs.opensolaris.org/view_bug.do?bug_id=6526418
This doesn't appear to be fixed yet, but I will see if I can't
get it into the next
build. There is an easy workaround for this, specify the port
number to contact on
the printer. eg. "lpadmin -p C510 -o dest=192.168.0.100:9100"
and
6519396 netpr still requires @localhost to work properly
http://bugs.opensolaris.org/view_bug.do?bug_id=6519396
This is fixed in Nevada build 62, so it will be in the next SXDE
release. You can also
workaround this by editing the interface script
(/etc/lp/interfaces/C510) and changing line 180
user_name=$2
to
user_name=$2 at localhost
until the fixed netpr is available.
Also, since the queue is local, you don't need to use "lpadmin -p C510
-s ...", though if this system changes IP periodically, you might want
to use "lpadmin -p C510 -s localhost".
-Norm
Doug Smith wrote:
> [sorry for the length]
>
> I use a network printer and it sits on 192.168.0.100. I've been using this
> printer on Solaris 10 for some time. I usually configure the printer using
> these commands:
>
> // my old way of doing things:
> lpadmin -p C510 -v /dev/null -m netstandard
> lpadmin -p C510 -o protocol=tcp
> lpadmin -p C510 -T PS
> lpadmin -p C510 -I postscript
> lpadmin -p C510 -s 192.168.0.100
> lpadmin -d C510
> enable C510
> accept C510
>
> But with snv_b55 the lpadmin -s 192.168.0.100 command never returned. So,
> thinking that things may have changed I read the on-line docs for lpadmin.
> Sure enough, it looks like I should now be using a -o dest=192.168.0.100
> option instead of the -s option.
>
> So, I deleted the printer as follows:
> # cancel C510
> # lpadmin -x C510
> # lpstat -p C510 -l
> Failed to contact service for C510: not-found
>
> And then tried recreating the queue using these commands:
> # lpadmin -p C510 -v /dev/null -m netstandard -o protocol=tcp
> # lpadmin -p C510 -o dest=192.168.0.100 -T PS -I postscript
> # lpadmin -d C510
> # enable C510
> # accept C510
>
> # lpstat -t
> scheduler is running
> system default printer: C510
> device for C510: /dev/null
> C510 accepting requests since Fri Apr 13 11:53:17 2007
> printer C510 idle. enabled since Fri Apr 13 11:53:12 2007. available.
>
> $ lp -d C510 testfile
> C510: unable to send message to scheduler: Bad file number
>
> # lpstat -u des
> Failed to get job list: unable to send message to scheduler: Bad file number
>
> I'm guessing "Bad file number" is some sort of catch-all error message.
>
> Snooping around I find that /etc/lp/logs/lpsched is being written to with
> considerable frequency:
> # tail -f /etc/lp/logs/lpsched
> 04/13 11:55:16: Print services started.
> 04/13 11:55:20: Print services stopped.
> This repeats every four seconds..
>
> I believe the "bad file number" message happens when the print services are
> momentarily stopped. When I try to cancel everything in the queue I get that
> message and when I repeat the cancel command it will eventually succeed:
>
> # cancel C510
> PurgeJobs C510: unable to send message to scheduler: Bad file number
> # cancel C510
> PurgeJobs C510: ok-substitution
>
> The svc.startd and svc.configd daemons bubble to the top of the prstat list
> while all this starting and stopping is going on. So, for the moment, I've
> run:
> # cancel C510
> # lpadmin -x C510
> to stop the svc.startd loop.
>
> It seems I've hosed up something but I'm not sure what to look at next.
> Suggestions gratefully received.
>
> Thanks,
>
