My 3 months of fun with The Uniform Assassin

[Xcell]

Now to start off, I would like to say the odds of someone using the same configuration as I am is fairly slim.

Nonetheless I feel a cautionary tale / bug report is in order.

 

I have been running various versions of US for about a year now on systems running XP, Vista, and 7. Little did I know how violent this little program could be. I am currently in the process of writing a new POS/Inventory/Employee management program for my employer. I am pretty good with computers and would occasionally code for fun but, I am not a software engineer by any stretch. We are currently running a horrible little program called Filepro. This dinosaur hasn't changed much since its inception on the TRS-80 computer. We have been running it since 1987. Our biggest issue is the version we have MUST run on the old SCO Unix operating system. It CAN NOT run on Linux, only SCO. No one here knows much of anything about Unix, let alone a version from a company that bankrupted themselves 8 years ago trying to prove they invented Unix and profit from it. But we are stuck until I am done.

 

About 3 months ago I upgraded to the new Coral US. Around the same day, our old router died and needed to be replaced. And this is where the problems began. Every day at exactly 10AM the Unix server would crash with a kernel panic related to the network card driver. We tried everything, bought a new network card for the SCO box, bought yet another router, unhooked cables, and tweaked every setting imaginable.

 

And then came the day I decided to change my db_backup settings. I worried about losing data, so I changed it to backup every 2 hours instead of every 24.

 

DOH!!!

 

So I changed it to backup every 5 minutes. Guess what happened?

 

I still have no idea why running db_backup in cron would cause another computer on my network to crash. I have since changed to another backup solution.

 

Just a reminder to not spend too much time focusing on one possible cause of a problem. We were determined that the problem was the router. So much so that we went through 3 months of daily server crashes without really testing which device was truly causing the problem, a little Windows XP machine backing up some data.

[BobS]

A very engaging and instructive story. Just think how much longer this could have gone on if you hadn't changed the schedule.

 

Because of the connection to the backup, I assume that you want some explanation of how the db_backup could zap the SCO Unix system (even though you're not still using it).

 

However, without seeing just what your backup and cron config contained (not to mention all the other aspects of the offending machine), I don't have enough info to hazard a guess. I see nothing in the default settings that would send anything to another machine.

 

Regards,

BobS

[Xcell]

Like I said before, the odds of someone else running a SCO system in this day and age along side US are very low. Not to mention the US team probably will never have access to a system like this to test my issue. But if there is just one other person looking for that needle in the haystack, hopefully this tale can give them the tools to think outside the box to find it. I plan on leaving the backup turned off until the transition is complete, then re-enabling it for an added layer of protection, once the SCO box is off the system.

 

I also have to agree with you that I have no idea how this sent out a signal on our network that would kill the SCO system. Fortunately this system has never been accessible from the internet. And let me tell you this thing is ancient. The majority of the hardware is from the late 90s. Pentium 2, 40GB HD, 512MB RAM, an old Intel pro100b NIC, SCO 5.0.4. , no USB ports, and we are still using DDS-90 backup tapes. It's taken me 3 years to convince my boss to move on before the availability of hardware becomes nonexistent. A series of tape drive faults helped that argument considerably.

 

The joke around here is the hot new thing was jealous of the old hag and was trying to kill her off.

 

As far as my backup, I simply uncommented the default line in CRON and changed the time period.

 

 

 

;[db_backup]

;start = 2011-11-21 2:00:00

;period = 14400

;path = C:\UniServer\uni_con\db_backup\Run_db_backup.bat

;ref = 1330979552

 

 

and here is my db_backup config.

 

 

[FIFO]

Fifo_depth = 6

 

[LOG]

Logging = true

 

 

 

 

A very engaging and instructive story. Just think how much longer this could have gone on if you hadn't changed the schedule.

 

Because of the connection to the backup, I assume that you want some explanation of how the db_backup could zap the SCO Unix system (even though you're not still using it).

 

However, without seeing just what your backup and cron config contained (not to mention all the other aspects of the offending machine), I don't have enough info to hazard a guess. I see nothing in the default settings that would send anything to another machine.

 

Regards,

BobS