Difference between revisions of "Shut down one server"
Jump to navigation
Jump to search
(Created page with "If you have one server you want to shut down and bring back up, make sure to keep the following in mind. Most of these points are non-technical. = Machines where this is okay...") |
m |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
If you have one server you want to shut down and bring back up, make sure to keep the following in mind. Most of these points are non-technical. | If you have one server you want to shut down and bring back up, make sure to keep the following in mind. Most of these points are non-technical. | ||
| + | |||
| + | Do not shut down a server unless you have exhausted all other reasonable options. | ||
= Machines where this is okay = | = Machines where this is okay = | ||
| Line 7: | Line 9: | ||
On the CS subdomain: | On the CS subdomain: | ||
* tools | * tools | ||
| − | * web | + | * web (save any wiki pages you may need; for instructions about that, see [[ShutdownProcedure]]) |
On the cluster subdomain: | On the cluster subdomain: | ||
| Line 13: | Line 15: | ||
* in rare cases, individual clusters, one at a time (note that this excludes hopper, which should rarely be shut down) | * in rare cases, individual clusters, one at a time (note that this excludes hopper, which should rarely be shut down) | ||
| − | For other machines, email the admin mailing list or talk to a faculty supervisor first. | + | For other machines, email the admin mailing list or talk to a faculty supervisor first. (This is good practice in any case, but *especially* do it for machines not listed here.) |
= Reminders = | = Reminders = | ||
| − | + | The process to restart one of our servers is as follows: | |
| + | # unmount file systems if applicable | ||
| + | # check on backups if applicable | ||
| + | # <code>sudo shutdown -h now</code> or <code>sudo reboot</code> when you're ready; you will immediately lose ssh connections | ||
| + | ## <code>shutdown</code> will require you to physically start the machine | ||
| + | ## <code>reboot</code> *should* automatically bring everything back up normally within a few minutes, though it may depend on your problem | ||
| + | |||
| + | Also remember these guidelines: | ||
# In an emergency (e.g. no services seem available, no one can log in to things), you can just restart the machine. | # In an emergency (e.g. no services seem available, no one can log in to things), you can just restart the machine. | ||
Latest revision as of 15:26, 23 January 2019
If you have one server you want to shut down and bring back up, make sure to keep the following in mind. Most of these points are non-technical.
Do not shut down a server unless you have exhausted all other reasonable options.
Machines where this is okay
You may restart any of these machines relatively quickly and non-disruptively most of the time.
On the CS subdomain:
- tools
- web (save any wiki pages you may need; for instructions about that, see ShutdownProcedure)
On the cluster subdomain:
- compute nodes
- in rare cases, individual clusters, one at a time (note that this excludes hopper, which should rarely be shut down)
For other machines, email the admin mailing list or talk to a faculty supervisor first. (This is good practice in any case, but *especially* do it for machines not listed here.)
Reminders
The process to restart one of our servers is as follows:
- unmount file systems if applicable
- check on backups if applicable
sudo shutdown -h noworsudo rebootwhen you're ready; you will immediately lose ssh connectionsshutdownwill require you to physically start the machinereboot*should* automatically bring everything back up normally within a few minutes, though it may depend on your problem
Also remember these guidelines:
- In an emergency (e.g. no services seem available, no one can log in to things), you can just restart the machine.
- That said, give at least a few hours' notice if possible. These servers aren't in use 100% of the time but when they *are* in use it's important that people can continue to use them.
- Be prepared to go to Noyes basement if there are problems restarting the server remotely. In other words, be on-campus and preferably in the science complex when you do this (or be in communication with an admin who is).
The point is to be courteous to the community for whom we run these servers.
