Focussing upon your first issue here (as the second is merely a symptom of your restarting the services as advised by Brian, "Thumbs Up" BTW), when you say you have the restart the services, can you confirm whether or not the services are actually stopped when you look at them? Also, are you using the Embedded DB or the SQL one?
You may also want to take a look at the below articles relating to the console hanging on logon:
http://www.symantec.com/docs/TECH169955
http://www.symantec.com/docs/TECH95764
http://www.symantec.com/docs/TECH157761
http://www.symantec.com/docs/TECH163614
Other similar articles exist, but these just recommend what you do already (restart the services):
http://www.symantec.com/docs/TECH161661
http://www.symantec.com/docs/TECH132302
#EDIT#
Incidentally, I'd be curious to find out if the clients actually believe the SEPM to be online while it is in this unreponsive state. To determine this, just wait until to encounter the issue whereby you cannot logon, then find/open a SEP Client via the Systray and client Help -> Troubleshooting and see what is says about the SEPM. This test is only really applicable if the SEPM services are still started when in the error state.
Assuming the clients believe the SEPM to be online, can you also try logging into the SEPM's reporting component and see if that is working? The reporting component can be accessed via the below kind of address:
https://<SEPM Hostname or IP Address>:8445/reporting/index.php
These tests are to help narrow down which part of the SEPM is encountering issues (Tomcat or Apache).