This is a discussion on SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMwareworkstation - SCO ; On Jul 5, 7:03*am, ed wrote: > The accounting program "Synchronics" at one of my customers leaves > enough stuff open that it runs out of internal storage somewhere > around 2 weeks. I have it rebooting at 1 AM ...
On Jul 5, 7:03*am, ed
> The accounting program "Synchronics" at one of my customers leaves
> enough stuff open that it runs out of internal storage somewhere
> around 2 weeks. I have it rebooting at 1 AM every Sunday. The side
> benefit is having a record that it happened so the customer can't
> complain that the package failure is because it didn't reboot.
This is sort of a mind-boggling statement. I've been supporting
CounterPoint (used to be made by Synchronics, now it's owned by
Radiant Systems) for years and still do for several customers, mostly
on SCO, some on Linux and Windows. What 'stuff' gets left open and
where? Under the top-level program directory there will always be a
directory named TEMP (in caps). When every user has correctly exited
the program that directory will be empty. If every user *says* they
have exited but there are temp files left, they didn't exit
correctly. This could be caused by an unreliable network connection
which causes a session to drop, but it usually happens because they
are running an emulator from a Windows client, and are simply closing
the session by clicking the X on the window. This is incorrect, they
*must* hit the escape key in the application until they have
completely exited, and that will delete the temp files and properly
Other possibilities are that reports need to be archived, or that
they're running an extremely old, buggy version of CounterPoint and
are too cheap to upgrade. Even so this should not be happening, and
you should be able to run months or years without rebooting.
I would like a better description of the "stuff" you mention, also
what you mean by "internal storage". I suspect there are orphan
processes running. I would be happy to help you off-list, or start a
new thread since this one seems to be drifting a little.
> I have taken the boot timeout down to 5 seconds on several machines
> but mostly take them to 15 seconds. Gives me a pretty fast turnaround
> at a vet clinic chain that is required to reboot every night by their
> software supplier.