News Group Posts

Main Index

From: Bela Lubkin <filbo@armory.com>
Subject: Re: Sleep command quitting
Date: 15 Sep 2005 16:43:00 -0400
Message-ID: <200509151342.aa23956@deepthought.armory.com> 
References: <432a9c89.26582515@giganews.nildram.co.uk> 

Rob S wrote:

> For many years we've used a little workaround to hold a serial port open, to
> allow us to cat large print jobs to a serial printer.
> 
> The command is put into /etc/rc.d/8/userdef:
> 
> (stty 9600 ixon ixoff -ixany ; while : ; do sleep 3600; done) < /dev/ttya1 &
> 
> It runs fine on bootup, but since OS507 (not sure which MP if any first showed
> the problem), the sleep command simply stops of its own accord after a time.
> 
> On all older versions of SCO OS from 500 upwards, this command stays running for
> as long as the system is up.
> 
> Any ideas what's causing it to terminate, or another way of doing the same
> thing?

It cannot be that the `sleep` command is terminating.  If that were the
case, the shell loop would just start another one.  It has to be that
the shell loop is somehow terminating.

That script was popular when I started working at SCO Support in 1989.
The reason for the loop was that the `sleep` binary in some old release
of Xenix (old in 1989) only supported sleep arguments up to some limited
number, probably 32767.  As I remember it, even in 1989, the then-
current Xenix `sleep` supported a 32-bit argument.

Try changing to:

  (stty 9600 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya1 &

2 billion seconds is about 63 years.  If the system stays up that long
and someone has to figure out why the ancient serial printer goes wrong,
I'll owe you a nice dinner.  ;-}

Taking out the loop simplifies things a lot.  The printer's continuing
settings no longer depend on the shell to keep waking up and executing
that loop.  In fact, the shell is smart enough in this situation to
"exec" the final sleep -- the shell process disappears, so you have one
less purposeless process (per printer) sitting around in the system.

<deep_background>

Another thing that might not be clear about this sort of holdopen
script: it doesn't really hold the settings you specify.  Holding a port
open prevents the driver from resetting its settings back to the driver
defaults.  But that initial `stty` command exerts no ongoing force.  If
anything else comes along and makes further changes, the holdopen script
holds _those_ settings.  That is:

  (stty 9600 < /dev/tty123; sleep 10000000) &
  # tty123 is now set to 9600 for the next 4 months
  # two hours later:
  stty 4800 < /dev/tty123
  # the `stty 4800` process ends immediately
  # but its effects remain: tty123 is now at 4800 for the next 4 months

Most of the OSR5 printer interface scripts do their own `stty` commands,
so the holdopen script is mainly serving to retain _those_ settings from
one printout to the next.  Without a holdopen script, the port would sit
at the driver's default settings most of the time, except when a
printout was in progress.

Some versions of the holdopen look more like this:

  (while :; do stty 9600 ixon ixoff -ixany; sleep 3600; done) < /dev/ttya1 &

Putting the `stty` inside the loop means that its settings _do_
occasionally get slammed onto the port -- whether or not a print job is
currently active.  This could either have no effect (if the interface
script is leaving those settings in effect, or if it's using compatible
ones); or disastrous effect (suppose the interface script -- and the
printer, of course -- is actually using 19200 bps).  Or it could have a
mysterious effect (maybe the interface script actually uses hardware
flow control, and the printer has buggy XON/XOFF that sends ^S to
throttle input but forgets to send ^Q to continue it.  The print jobs
will usually work OK, but once in a while the hour will be up, the
holdopen will poke in XON/XOFF settings, and the printer will suddenly
lock up...)

Finally, you don't need a separate holdopen script for each printer.
One process can hold open a large number of file descriptors.  It's
clumsy to hold more than 7 open in a single shell script, though, so
it's easier to reduce the number of holdopen processes by a factor of 7
than it is to drop all the way down to one system-wide holdopen process.

Change this:

  (stty 9600 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya1 &
  (stty 4800 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya2 &
  (stty 19200 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya3 &

to this:

  exec 3</dev/ttya1 4</dev/ttya2 5</dev/ttya3
  stty 9600 ixon ixoff -ixany  < /dev/ttya1
  stty 4800 ixon ixoff -ixany  < /dev/ttya2
  stty 19200 ixon ixoff -ixany < /dev/ttya3
  exec sleep 2000000000

The first line uses Bourne shell syntax to open the three ttys.  Those
file descriptors will remain open as long as the shell (or any child it
has passed them to) is running.  Then we apply the various initial
settings, knowing that they'll "stick" because we're holding open the
ports.  Finally, we go to sleep "forever".

The shell's syntax only allows single-digit file descriptor numbers
here, and it's simpler if we don't mess with fds 0-2.  That's why we're
limited to 7 per holdopen script.  A trivial C program could do
hundreds.

</deep_background>

>Bela<
 

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.