[offtopic] Incomplete data received withscripted netcat that emulates a JetDirect printjob receiver

[Helge Blischke]

Kurt Pfeifle wrote:
>>On Sat, Jun 07, 2008 at 08:41:24PM -0700, Kurt Pfeifle wrote:
>>
>>>If I remove the "&" from the listener-watchdog call in the "rc-listener" startup script, that script does not return the shell console to me. However, if I use "^Z;bg" to put it into the background, it works perfectly, and all data arrive without fail.
>>>
>>>I'm at my wits' end. It seems to be connected to the mentioned backgrounding of the "listener-watchdog" call inside the "rclistener" script.
>>>
>>>Why...
>>>   ...does putting that one line directly into the background inside
>>>      the script *not* work,
>>>   ...while calling it normally, but instead putting the whole script
>>>      manually into the background work
>>
>>Instead of using a script in /etc/init.d/, couldn't you edit your
>>/etc/inittab file and put this line at the bottom :
>>
>>--- CUT ---
>>lw:2345:respawn:/usr/local/bin/listener-wrapper >/tmp/log 2>/tmp/err
>>--- CUT ---
>>
>>Then do a :
>>
>>        telinit q
>>
>>This will replace both your rc-listener script and your watchdog,
>>elimintating in the process potential sources of problems.
>>
>>bye
>>
>>Jerome Alet
> 
> 
> 
> Thanks, Jerome,
> 
> for this valuable suggestion.
> 
> I need this to work on Solaris 10. So I will see if that OS can do it in the same or similar way as you suggested when I (tomorrow) again have access to such a system (Solaris 10 has a new way to handle services, called SMF: Service Management Facility, which I'm not too familiar with).
> 
> What I described above also happened in the same way last week when I tried it on Solaris 10. First I thought it was due to some weirdness in Solaris' /bin/sh.
> 
> That's why I started to look more closely at the problem this weekend by  using my Linux notebook... and was surprised that the same problem occurred here, even with /bin/bash.
> 
> 
> So, even when/if Jerome's suggestion works for me: I'm still interested in learning the cause of that weirdness I described in my initial posting.
> 
> Thanks for your help.
> 
> Cheers,
> Kurt
> 

I did something similar (a port 91xx listener) some years ago implementing it as
an inetd based service, which does not need any tricks for daemonizing etc.
If the "start-on-request" overhead caused by this is not an issue, this may be
a solution.

On Solaris 10, then simply set up a dummy inetd.conf file as usual (in an
arbitrary directory of your choice) and then run inetconf with that file
as commandline parameter. This transforms the inetd bases service to the
new SMF architecture. It behaves as expected and can be activated and
deactivated by svcadm (and looked at by svcs).

Note that in this scenario your "daemon" reads from STDIN (the source port data
are piped to that).

Helge

PS: if you really need a working example (a Perl script in this case), let me know.

-- 
Helge Blischke
Softwareentwicklung

H.Blischke at acm.org