Shut down one server - Revision history

Craigje at 20:26, 23 January 2019

2019-01-23T20:26:32Z

← Older revision		Revision as of 20:26, 23 January 2019
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 =

Craigje: /* Machines where this is okay */

2019-01-23T20:07:21Z

Machines where this is okay

← Older revision		Revision as of 20:07, 23 January 2019
Line 7:		Line 7:
	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:

Craigje: /* Machines where this is okay */

2019-01-23T20:05:19Z

Machines where this is okay

← Older revision		Revision as of 20:05, 23 January 2019
Line 13:		Line 13:
	* 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 =

Craigje: /* Reminders */

2019-01-23T20:03:11Z

Reminders

← Older revision		Revision as of 20:03, 23 January 2019
Line 20:		Line 20:
	# unmount file systems if applicable		# unmount file systems if applicable
	# check on backups 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>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>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		## <code>reboot</code> should automatically bring everything back up normally within a few minutes, though it may depend on your problem

Craigje: /* Reminders */

2019-01-23T20:02:53Z

Reminders

← Older revision		Revision as of 20:02, 23 January 2019
Line 20:		Line 20:
	# unmount file systems if applicable		# unmount file systems if applicable
	# check on backups if applicable		# check on backups if applicable
	# <code>shutdown -h now</code> when you're ready (you will immediately lose ssh connections)		# <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:		Also remember these guidelines:

Craigje: /* Reminders */

2019-01-23T20:00:28Z

Reminders

← Older revision		Revision as of 20:00, 23 January 2019
Line 17:		Line 17:
	= Reminders =		= Reminders =

	~~Shutting a machine down~~ is ~~simple (~~<code>shutdown -h now</code> will ~~do it, for the most part~~)~~, so there's no "process" for this. However, there are some things to keep in mind~~:		The process to restart one of our servers is as follows:
			# unmount file systems if applicable
			# check on backups if applicable
			# <code>shutdown -h now</code> when you're ready (you will immediately lose ssh connections)

			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.

Craigje: 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..."

2019-01-23T13:33:59Z

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..."

New page

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 =

You may restart any of these machines relatively quickly and non-disruptively most of the time.

On the CS subdomain:
* tools
* web

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.

= Reminders =

Shutting a machine down is simple (<code>shutdown -h now</code> will do it, for the most part), so there's no "process" for this. However, there are some things to keep in mind:

# 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.