Grow TEMPDB is another step where possible. I try to ensure I have enough disk space to allow for autogrowth and I try to monitor for abnormal autogrowth on all databases. If I absolutely need to free up disk space, restarting the SQL Server Service is one of the last things I would do as it impacts ALL databases and all running queries. If I can get into the system (sqlcmd or ssms), I will try to shrink tempdb before I would restart the instance.
And when you say the server won't let you connect, is that via SSMS (which is what I expect) or any method (sqlcmd for example)? I've had SQL instances that refused SSMS connections due to various things, but I've never had sqlcmd fail to connect.
I don't like shrinking mind you as tempdb grew to that size for a reason, and it may be a perfectly valid reason. If it is valid, it is likely to happen again, so I'd prefer to not tempt fate and shrink it or put a limit on how big it can get, but instead add more disk and allow tempdb to grow.
But that is just me. I've only had tempdb get out of hand a handful of times and each time I had enough disk for it to grow without filling the disk; just resulted in a bit of wasted space until the next scheduled update window when I rebooted the instance.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!