Re: Netcat question

Brian K. White wrote:
Then have your virtual device send the data it collects to "|lp -d printer" instead of "|netcat host port"


Thanks, I'll try that, didn't get it the first time. The reason I tried with netcat was because all the horror stories with the Unix spooler and network printing that I have been reading about.


OK, just did. I do have an hp print server in house so I Setup the hpnp on my SCO server, got it working and changed the virtual device to " | lp -d printer".
It works, sometimes. When I send something to the lpRem device, sometimes I get error:

UX:lp: ERROR: No (or empty) input files.

and sure enough, in the /usr/spool/lp/temp, there are one or more files with 0 size, just like you said before. I have to find a way to clean (or even better, not create) those files. I am working on that and any help would be appreciated.

Thanks again,


Is this error harmful?
If you write the virtual device script to simply throw out all output from the lp cmmand, what are the outward effects? Are you losing print jobs? Is the application hanging up? Is the spooler hanging up or disabling the printer?
Maybe just add -s to the lp conmmand line and live happily ever after? :) (actually you want that anyways beause you don't want normal lp messages going through to the applications display either most likely.

If the problem has at least changed to being only cosmetic then thats something.

Also, I apologize since I think you might have provided this already, but can we see the virtual device script?
Now that we're convinced or at least accepting that you really need it, maybe it could benefit from some scrutiny.

Maybe a quick & dirty hack fix is to have the virtual device script always append something unobtrusive to the collected print data for no other reason than to garuntee that the print jobs are always at least a few bytes. Maybe once in a while the printer wastes a *** of paper doing a form feed or printer reset escape code with no payload, but at lest the printer always works.

I just set up a similar test myself on a sco 506 box.
To start with, I have a working reliable network printer already.
It uses a cheap-o single port print server that snaps onto the centronics plug just like that netgear ps101.
In my case the printer is an HP laserjet 3015 and the spooler is configured with my Net printer interface script which in turn is configured to use rlpr and the hplaser model script for this printer.
This printer is named "brian" in the spooler.
So, as a starting point, I can say echo this is a test | lp -d brian and that all works fine.

You need to get to this same point first too. Forget about the virtual device for a minute and get this working and verify that it's solid. Hammer it with print jobs. If it's in any way flaky then theres no point even thinking about anything else yet.
You may already have this with the hp print server and the hpnp config, but, I never used hpnp once in my life, I have fixed, cleaned up, or removed it a few times, have seen a few, admittedly rare, reports of problems with it here. The main problem with it is probably no problem for you, which has to do with multiple port print servers and using the 2nd and 3rd ports. But, I personally won't vouch for it as a dependable system since I never use it. But I know how it works and basically it just sends data to port 9100 and so you need a print server that is reliable doing that, and hp's all are, so you should be good.

Now, to start emulating your situation I created a fifo:
mkfifo -m 666 /dev/brian

Then created a loop script to monitor the fifo:
---snip---
#!/bin/sh
while : ; do
lp -s -d brian < /dev/brian
done
---snip---

Then I launch the loop and put it in the background and nohup it:
nohup ./fakelpmon >/dev/null 2>&1 &

Now I try to use the new fake device:
echo this is a test >/dev/brian

voila it works

Now I try to swamp it with many jobs, empty jobs, etc...

# this includes some syntax that only works in ksh or bash or zsh , don't do it in sco's sh
# the sh version would need n=`expr $n + 1`
# but that would slow it down and the point is to try to feed jobs fast
n=1 ; while [ $n -lt 50 ] ; do echo $n >/dev/brian ;n=$((n+1)) ;done

....
interesting... it didn't fail, or even blink, but it also didn't do what I think it should have.
all 49 lines printed on one ***.
This would be no problem for an application that always sends printer init and printer reset escape codes at the beginnings and ends of jobs. Those init and reset control codes would ensure that pages ejected when they are supposed to and page seperation happened where it's supposed to.
But if you were relying on the system to do that for simple plain text jobs like above, well, it didn't. It did actually for the whole job. The only reason the page ejected after line 49 was because the hplaser interface script that "lp -d brian" uses did it.
Perhaps the while command kept the fifo open the whole time as one session, where I had thought each individual echo command would open and close the fifo? Maybe the print server has some timing code that just decrees line-feeds that arrive close enough together are part of the same job? Changing 50 to 300 made no difference. It spilled onto 3 sheets but it was all one job.

anyways, moving on, I don't know how to test a 0 byte job.
I mean, this had no adverse effect:

/dev/brian

It didn't make any error, it didn't print a blank ***, it didn't c.reate 0byte junk in /var/spool/lp
As far as I can tell it didn't trigger lp into running when it shouldn't have.
this is a test >/dev/brian still works afterwards so it didn't disrupt the looping script

Maybe try duplicating my example above using the loop script I have above, and see if it is reliable with your app?
I can't seem to make this fail, but I also don't have your app or users. These are only simple light tests.
It's hard to say what little details might be important so do try to do it all exactly the same.
Like, maybe the fact that I used nohup and >/dev/null 2>&1 instead of capturing messages to some log file actually matters etc...

Oh in case you're worried about that loop script impacting the system, don't.
when there is no data being sent to the fifo, there are just two processes in sleep state
load avg stays 0
# ps -elf |grep fake |grep -v grep
20 S root 16684 15682 0 76 24 fb120528 88 fc7c3758 14:51:58 ttyp7 00:00:00 ./fakelpmon
20 S root 15682 14945 0 73 24 fb120d38 88 fb120d38 14:14:09 ttyp7 00:00:00 ./fakelpmon
#
# top
qlast pid: 17523; load averages: 0.00, 0.00, 0.00 15:26:53
115 processes: 114 sleeping, 1 onproc
CPU states: 100% idle, 0.0% user, 0.0% system, 0.0% wait, 0.0% sxbrk
Memory: 1024M phys, 501M max, 442M free, 481M locked, K unlocked, 1953M swap

PID USERNAME PRI NICE SIZE RES STATE TIME COMMAND
17520 root 26 0 764K 764K onpr 0:00 top
617 root 56 0 1284K 1284K sleep 0:00 fct_remprt
328 root 51 4 884K 884K sleep 0:00 rwalld
511 root 51 0 21M 21136K sleep 0:00 httpd
16355 root 51 0 3156K 3156K sleep 0:00 mc
15256 root 51 0 2916K 2916K sleep 0:00 sshd
391 root 51 4 1496K 1496K sleep 0:00 lpd
309 root 51 0 1424K 1424K sleep 0:00 lpsched
441 root 51 -6 1404K 1404K sleep 0:04 drpd
365 root 51 0 1132K 1132K sleep 0:00 pppd
...


The pid of the child process changes every time I write data to the fifo so I guess the "do" command must set up a subshell to do its' thing.

Brian K. White -- brian@xxxxxxxxx -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

The error just hangs the spooler.

The script in question is:

In the /usr/bin directory I created a script (lpRem) as follows:

while true
do cat /dev/lpRem | lp -d Oki320
done

Any print command sent to the spooler, like
'cat Textfile | lp -d Oki320'
will work and all is ok. I configured it with no banner and ff at the end only. I can repeat that many times.
But if I
'cat Textfile > /dev/lpRem'
then I get the error, because it creates 0 size files in the /usr/spool/lp/temp directory named 16-0, 16-1, (the numbers change with the job #) etc. I erase them and repeat the cat command and the same thing happens. So it is the script that creates the problem.
I see that you use:

#!/bin/sh
while : ; do <-- Would the ':' make a difference?
lp -s -d brian < /dev/brian
done

and:

nohup ./fakelpmon >/dev/null 2>&1 &

I will certainly try these and let you know.

Thanks,


--

Ygnacio Moreno.

Please remove TheObvious from my email address to respond.
.