I found a fix to clear up everything, as a reboot is only wasting my time :-)
If you have any open terminal sessions open, you can continue with one by running the command "ls -apl /dev/" this will show you who is using the ttys sessions. As all of my sessions were curerntly being used with the account "administrator". Next I was able to run the command top / or go into activity monitor and you can see there was an abundence amount of sudo commands. In my case it was sudo in yours it could be something different.
As with knowing that this direct error is related to open tty sessions we have to figure out why they are open and how they are stale.
As I was stating as above my example was the administartor account, and running a "ps -ax | grep tty" wasn't showing anythign other then the open tty sessions I had.
Once I was able to kill one of those sudo sessiosn by running top / activity monitor. I was able to open terminal or iTerm and run "ps -ax | grep sudo".
This lead to one of our internal devices that does network access control by remotly logging in via ssh. As you could see this was where all the tty sessions were going. I had my assumptions it was it before, but trying to prove it was another case. It appears that the network device was trying to chown the ownership of the file in the tmp directory, and was leaving a stale tty session open. It appears to be doing it my 10.8.2 and 10.7.5 machine. If i deleted the file or changed the ownership on what it was trying to do it just keeps doing it. Currently we have a ticket open with the provider on the issue as there may be a bug.
After cleaning up a few stale PID's your now open to launch a program that uses a tty session to inspect thigns more throughly. I was able to run the command "sudo killall -v -c sudo" as the sudo command was the one hanging my tty sessions while it kept having stale tty sessions from the chown it was trying to do.
After I was able to run "ps -ax | grep sudo" and find that either all PID's were killed after running the killall command a few times.
Now with knowing the issue, I can just throw an automated script together until a resolution has been addressed.
I will update reguarding if i find out if there was a bug with the network applicance we are using.
