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

[Kurt Pfeifle]

> 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.

Yes; that's what I seem to need head for.

(In my initial considerations I did stay apart from this idea exactly because of its "start-on-request" overhead....)

> 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.

Oh, it's simple as that? That would be a very cool thing.

> It behaves as expected and can be activated and
> deactivated by svcadm (and looked at by svcs).

I'm currently reading up some introductionary material about SMF, and was not very confident I could implement this very easily. Too much XML config file complication, too many new "weird" technical info and keywords...

But from what you say it seems to be very straightforward.

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

Yes.

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

Thanks, Helge.

[But I prefer a script language which I have a chance to understand each and every line; Perl isn't that comprehensible for me :-)  ]

Cheers,
Kurt