Very Computer

A few days ago I posted an article about the inability to run Foxpro as
a daemon process. Since then I found out that Fox can be run under cron
so I tried this out. Aside from doing silly things like setting a TERM
type, just running Fox (no program, no database manipulations, no nothing)
causes the following behaviour:

OS: SCO Unix 3.2v4.2 in single user mode

Script started on Fri Jun 30 15:46:40 1995
# ps -aef
     UID   PID  PPID  C    STIME  TTY      TIME COMMAND
    root     0     0  0 15:17:47  ?        0:00 sched
    root     1     0  0 15:17:47  ?        0:00 /etc/init
    root     2     0  0 15:17:47  ?        0:00 vhand
    root     3     0  0 15:17:47  ?        0:00 bdflush
    root    31     1  0 15:17:53  console  0:00 -
    root    95    31  0 15:46:40  console  0:00 script
    root    96    95  2 15:46:40  console  0:00 script
    root    97    96  2 15:46:40  p0       0:00 sh -i
    root    98    97  2 15:46:43  p0       0:00 ps -aef
    root    66     1  0 15:44:24  ?        0:00 cron
# vmstat 5 5

PROCS     PAGING                                          SYSTEM  CPU
 r  b  w  frs dmd sw cch fil pft frp pos pif pis rso rsi  sy  cs  us su id

 0 10  0 30000   0   0   0   0   0   0   0   0   0   0   0    2   0   0  0 100
 0 10  0 30000   0   0   0   0   0   0   0   0   0   0   0    6   2   0  0 100
 0 10  0 30000   0   0   0   0   0   0   0   0   0   0   0    3   0   0  0 100
 0 10  0 30000   0   0   0   0   0   0   0   0   0   0   0    3   0   0  0 100
 0 10  0 30000   0   0   0   0   0   0   0   0   0   0   0    3   0   0  0 100
# at now + 1 minutes < foxstart
job 804545280.a at Fri Jun 30 15:48:00 CDT 1995
# at -l
user = root     804545280.a     Fri Jun 30 15:48:00 CDT 1995
# cat foxstart
#!/bin/sh

TERM=ansi; export TERM
exec fox -t >/dev/null 2>&1
# ps -aef
     UID   PID  PPID  C    STIME  TTY      TIME COMMAND
    root     0     0  0 15:17:47  ?        0:00 sched
    root     1     0  0 15:17:47  ?        0:00 /etc/init
    root     2     0  0 15:17:47  ?        0:00 vhand
    root     3     0  0 15:17:47  ?        0:00 bdflush
    root    31     1  0 15:17:53  console  0:00 -
    root    95    31  0 15:46:40  console  0:00 script
    root    96    95  1 15:46:40  console  0:00 script
    root    97    96  2 15:46:40  p0       0:00 sh -i
    root   106    66 65 15:48:00  ?        0:06 /usr/lib/foxpro/foxpro.pr -t
    root    66     1  0 15:44:24  ?        0:00 cron
    root   108    97  3 15:48:06  p0       0:00 ps -aef
# vmstat 5 5

PROCS     PAGING                                          SYSTEM  CPU
 r  b  w  frs dmd sw cch fil pft frp pos pif pis rso rsi  sy  cs  us su id

 1 10  0 30000   0   0   0   0   0   0   0   0   0   0   0 3111   4  89 10  1
 1 10  0 30000   0   0   0   0   0   0   0   0   0   0   0 3092   6  88 12  0
 1 10  0 30000   0   0   0   0   0   0   0   0   0   0   0 3098   4  88 12  0
 1 10  0 30000   0   0   0   0   0   0   0   0   0   0   0 3097   4  87 12  1
 1 10  0 30000   0   0   0   0   0   0   0   0   0   0   0 3097   4  88 12  0
# kill -9 106
# vmstat 5 5

PROCS     PAGING                                          SYSTEM  CPU
 r  b  w  frs dmd sw cch fil pft frp pos pif pis rso rsi  sy  cs  us su id

 0 10  0 30000   0   0   0   0   0   0   0   0   0   0   0    2   0   0  0 100
 0 10  0 30000   0   0   0   0   0   0   0   0   0   0   0    6   2   0  0 100
 0 10  0 30000   0   0   0   0   0   0   0   0   0   0   0    3   0   0  0 100
 0 10  0 30000   0   0   0   0   0   0   0   0   0   0   0    3   0   0  0 100
 0 10  0 30000   0   0   0   0   0   0   0   0   0   0   0    3   0   0  0 100
# exit

script done on Fri Jun 30 15:49:27 1995

As you can see, once Fox is running, it completely drains my processor with
needless CPU cycles looking for keyboard input (?). Now this behaviour does
NOT occur when just starting Fox after logging in. Whoever is responsible
for this program is clueless about what a bg job is. There is NO keyboard
input, you should not even look for any! My guess is that it is getting
bombarded with "fake" input. Try doing this for example:

$ fox -t < /dev/null

and see what kind of goofy behaviour you get. If you look at the output
of vmstat it looks about the same.

Anyway, I still don't really understand why this works at all under cron
but does not work under /etc/inittab as a daemon process. However, I do
know that it is really dumb not to provide a version of software that can
be run in the background correctly under a UNIX OS.

And this is an SCO Supported Product????

: A few days ago I posted an article about the inability to run Foxpro as
: a daemon process. Since then I found out that Fox can be run under cron
: so I tried this out. Aside from doing silly things like setting a TERM
: type, just running Fox (no program, no database manipulations, no nothing)
: causes the following behaviour:

[..snip..]

: As you can see, once Fox is running, it completely drains my processor with
: needless CPU cycles looking for keyboard input (?). Now this behaviour does
: NOT occur when just starting Fox after logging in. Whoever is responsible
: for this program is clueless about what a bg job is. There is NO keyboard
: input, you should not even look for any! My guess is that it is getting
: bombarded with "fake" input. Try doing this for example:

Try running a program instead.  If Foxpro is idle (just as with foxbase)
it will eat as much CPU as you give it.  Same thing happens when the
program encounters an error and stops execution waiting for input.  Try
it in Foxbase and the same thing will happen.  There really isn't
a problem here, why let fox sit idle at the command prompt anyway?

: And this is an SCO Supported Product????

Its not supported by SCO.  Its supported by Microsoft for use on the
SCO platform only.

Steve Wertz
Computer Literacy Bookshops, Inc.

Quote:>Try running a program instead.  If Foxpro is idle (just as with foxbase)
>it will eat as much CPU as you give it.  Same thing happens when the
>program encounters an error and stops execution waiting for input.  Try
>it in Foxbase and the same thing will happen.  There really isn't

Quote:>a problem here, why let fox sit idle at the command prompt anyway?

Are you mad? You call a process which spins my processor 100% of the
time not a problem? Would you care to elaborate on why this is not a
problem?

If I just type "fox" at the command line, it does *not* use any processing
cycles past its initial startup. This behaviour is easily accomplished
using either select() or poll() to monitor stdin, i.e. keyboard input.
The problem is that when run under cron, stdin is NOT connected to your
keyboard. Thus, as best I can tell, fox gets crushed with phantom events
which it takes to be keyboard input. The same thing happens if you do:

$ fox < /dev/null

Anyway, the point of all this is to have Fox watch for requests like
a daemon. These requests come in the form of files which supply instructions
for Fox to run reports on various databases. These instructions get created
at random times so it is not possible to run Fox at that exact moment.
In addition, this whole operation is supposed to be as transparent to the
user as possible. Fox is just supposed to be a database engine in the
background servicing requests. However, as I noted, running Fox via cron
is crushing my processor. And I completely don't understand why anyone
would design a program this way. Why would you require Foxpro be run
interactively when clearly people would want to run background processes?
This is exactly why there is such a thing as an interactive and non-interactive
shell.

P.S.
        I seem to have falsely stated that this is an SCO-Supported Product.
I was led to believe this was true but have since been corrected. Indeed
Foxbase is supported but Foxpro is not. Forgive my cruel depiction of SCO
having anything to do with this evil product.

feeling like throwing something out the window myself...

One of my customers runs Foxplus 2.1.2 in the background as
part of a telephone system diagnostic port logger.  It's
been running for quite a while in various evolutionary forms
since Fox 1.0 (dbase2 clone).  The customer has FoxPro 2.6
for Unix but has not replaced this particular program with
a FoxPro incantation.  However, it was tested by simply
runnning all their Foxplus applications under FoxPro when
2.6 inititally arrived.  I was told that it did work.
The system was NOT exessively busy or devoid of available memory.

Here's the basics.  Note that everything talks via a named
pipe called (cleverly) PHONE.PIPE.  To create a named pipe:
        mknod PHONE.PIPE p
        chmod 777 PHONE.PIPE

This is the shell script that controls the program and starts
up (and kills) foxplus.  Methinks there have been some changes
and improvements, but I can't seem to find them.

============
:

# start and stop the phone logger.
# Usage: phone start | stop

# if the PID of the cat process started by /etc/rc.d/7/phonelog
# exists, kill the stupid process because it's uncool to have 2 or
# more of them running at the same time.

# need to be in the same dir at the .prg file for foxplus
cd /v/fox/phone
if [ $1 = start ]
then
   ps -ef > /tmp/phonelog.ps # this weird mess to prevent grep self find
   if (cat /tmp/phonelog.ps | fgrep 'phlog' > /dev/null)
   then
        echo " Error: phonelog already running"
        exit 3
   else
        [ -r /tmp/phonelog.id ] && kill `cat /tmp/phonelog.id`
        (stty 1200 evenp -cstopb;nohup cat >/v/fox/phone/PHONE.PIPE)\
        </dev/ttyb7 &
        echo $! > /tmp/phonelog.id   # Save the PID of the cat command
        exec foxplus phlog  < PHONE.PIPE     # do it finally
   fi

elif [ $1 = stop ]
then
   [ -r /tmp/phonelog.id ] && kill `cat /tmp/phonelog.id`
   # convince foxplus to terminate by sending exit to the command line
   echo "EXIT" > /v/fox/phone/PHONE.PIPE

else                    # Test for command line screwups
   echo "Usage: `basename $0`   start|stop"
   echo "You must also be root to execute"
   exit 1
fi

=============

This is the startup program:

:

#
#       /etc/rc.d/7/phonelog - startup foxplus phonelogger
#       accepts input from the phone machine and processes the
#       output with a foxplus program.

TERM=ansi
export TERM     # required to get anything to talk to console.

echo "Starting the phone log.  Output is on /dev/tty10"

echo "Setting tty2a to 1200 baud"
(stty 1200 evenp -cstopb; nohup cat > /v/fox/phone/PHONE.PIPE) < /dev/tty2a &
# save the PID of the cat process
echo $! > /tmp/phonelog.id

cd /v/fox/phone         # foxplus needs the .prg file in the cwd.
/usr/bin/foxplus phlog < /v/fox/phone/PHONE.PIPE > /dev/tty10 &
cd /

# Things to do:
#       Install failsafe   [ -x blah ] && blah   form for executables
#       Send message to root indicating phone logger has started.

================

The actual foxplus program "phlog.prg" is proprietary to the customer
and not for public consumption.  Besides, I can't find a copy on my
machine.  The program collects phone system statistics for telemarketing
performance data.

--
# Jeff Liebermann   Box 272     1540 Jackson Ave     Ben Lomond    CA   95005

# 408.699.0483 digital_pager    73557,2074  cis [don't]

|: As you can see, once Fox is running, it completely drains my processor with
|: needless CPU cycles looking for keyboard input (?). Now this behaviour does
|: NOT occur when just starting Fox after logging in. Whoever is responsible
|: for this program is clueless about what a bg job is. There is NO keyboard
|: input, you should not even look for any! My guess is that it is getting
|: bombarded with "fake" input. Try doing this for example:

|Try running a program instead.  If Foxpro is idle (just as with foxbase)
|it will eat as much CPU as you give it.  Same thing happens when the
|program encounters an error and stops execution waiting for input.  Try
|it in Foxbase and the same thing will happen.  There really isn't
|a problem here, why let fox sit idle at the command prompt anyway?

Running a program doesn't help. We have a Foxpro program that sits idle
waiting for the name of a program to compile to come down a named pipe.
The approach that was taken here was to submit this program name via a
script that checks to see if the Foxpro program is running, then starts
it if it isn't.

This ends up attaching Foxpro to whichever terminal the user was logged in
from when they submitted the request. This seems to persist, even after
the user logs out, as long as another getty is respawned on the port.
If the port is disabled, Foxpro silently dies either right then, a little while
later, or when the port is enabled again (I can't find any repeatable
behavior).

Trying to run Foxpro in the background from cron results in exactly what
the original poster said - 100% CPU usage. I tried redirecting stdin and/or
stdout to/from a tty and /dev/null without resolution.

Fox+ will only do this if your program expects keyboard input (like GET...READ).

I'm beginning to understand the original posters emotion. Is there anyone at
Microsoft who 1) can understand the problem and 2) can do something about it?
My previous experience with reporting bugs/performance problems to them has
been frustrating in that it took a while to find someone with enough
knowledge to understand the problem, and then they couldn't do anything about
it anyway.
--
< Alan H. Mintz                                        | ...!netcom!mq!alan    >

: Are you mad? You call a process which spins my processor 100% of the
: time not a problem? Would you care to elaborate on why this is not a
: problem?

You *will not* have a problem if you run a Foxbase/Pro program via cron
unless it crashes.  You *will* have a problem if you let fox sit idle at
the command prompt without running anything or if it encounters a bug.
This *only* applies to at/cron.  Why run a cron job that lets fox
sit idle at a command prompt?  Seems absolutely senseless to me.  But,
if you insist on having a cron job that does absolutely nothing,
try an endless for/next loop to solve your CPU problem.  

And no, *I'm* not mad.

Steve Wertz

(.explicit_disclaimer)

Quote:>feeling like throwing something out the window myself...

Quote:>I'm beginning to understand the original posters emotion. Is there anyone at
>Microsoft who 1) can understand the problem and 2) can do something about it?
>My previous experience with reporting bugs/performance problems to them has
>been frustrating in that it took a while to find someone with enough
>knowledge to understand the problem, and then they couldn't do anything about
>it anyway.

Anyway, since this was their solution, I guess it ain't going to be
fixed anytime soon. I guess the guys at MicroSoft can't fathom the
implications of a true multitasking operating system.

$ fox   [ from the command prompt ]

now look at your processor stats. See them? They are fine and fox *is*
sitting idle doing nothing.

Now do run this script *under cron* [stress, under cron]:

$ cat foxstart
#!/bin/sh

TERM=ansi; export TERM
exec fox -t >/dev/null 2>&1

now look at your processor stats. See them? That are *not fine*. In fact,
they suck!

Quote:>This *only* applies to at/cron.  Why run a cron job that lets fox
>sit idle at a command prompt?  

This makes absolutely no sense. There is no such thing as a cron job
that can run another process at the command prompt. Having a command
prompt means that you are logged in! If I was logged in, I would have
a keyboard and then I wouldn't have this problem to begin with. This
is the point, the *entire point*.

Quote:>Seems absolutely senseless to me.  But,
>if you insist on having a cron job that does absolutely nothing,
>try an endless for/next loop to solve your CPU problem.  

Quote:>And no, *I'm* not mad.

: : Are you mad? You call a process which spins my processor 100% of the
: : time not a problem? Would you care to elaborate on why this is not a
: : problem?

: You *will not* have a problem if you run a Foxbase/Pro program via cron
: unless it crashes.  You *will* have a problem if you let fox sit idle at

[..snip the rest of my erroneous post...]

Let me stick my foot in my mouth here.  After ruinning some more tests this
time (the right way), foxbase and foxpro do act differently in this
circumstance.  I had run the test program originally under Foxbase instead
of PRO.  Unfortunatly I'm still running everything under Fox+, but
now this dilema has me wondering.  I have close to 100 cron jobs
running at night.  This is a *serious* disadvantage!

I'll put my tail between my legs and scurry away now.

Steve Wertz

Quote:>of PRO.  Unfortunatly I'm still running everything under Fox+, but
>now this dilema has me wondering.  I have close to 100 cron jobs
>running at night.  This is a *serious* disadvantage!

I had originally run things under Foxbase too using foxprun which *does*
allow me to do batch mode processing via /etc/inittab because it simply
runs a program and exits. Thus I can run a simple daemon like this:

$ cat simpledaemon
#!/bin/sh

while :
do
        if [ -f somefile ]; then
                foxprun myprog
        fi
        sleep 300;
done

Then every 5 minutes I can do a simple look for a request in the form of
a file, and if it exists, run myprog and exit. And this of course will
*not* kill my processor.

The real bogus part about all this is that all you have to do is take
out processing of keyboard events from the code and everything works fine.
It's not like any significant programming needs to be done.

Quote:>Trying to run Foxpro in the background from cron results in exactly what
>the original poster said - 100% CPU usage. I tried redirecting stdin and/or
>stdout to/from a tty and /dev/null without resolution.

Quote:> [flame mode off]

Seriously; hows this for a solution:  Perl allows you to run programs
under a psuedo tty using the chat2.pl library.

It would be a synch to have Perl feed ITS stdin and stdout through the
psuedo tty and into FoxPro.

If this sounds helpful, then email me.

+------------------------

|                                       you may NOT call me Sam-I-Am       |
| Campbell Scientific Ltd                                                  |
                                              -----------------------------+