The issue appears to be that all of your TTY sessions are currently being used, you can run a few commands to see who is using those sessions, although why they are being used can varry.
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.
After cleaning up these stale PID's your now open to launch a program that uses a tty session. Hope this helps anyone else that runs into the issue, as the end result a reboot will kill your PID's but if it keeps happening, you need to find out the root cause.