# Best practice for shutting down a cluster
**URL:** https://dask.discourse.group/t/best-practice-for-shutting-down-a-cluster/1382
**Category:** Distributed
**Created:** [December 9, 2022, 7:59pm UTC](https://dask.discourse.group/t/best-practice-for-shutting-down-a-cluster/1382 "2022-12-09T19:59:48Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@rjplevin](https://dask.discourse.group/u/rjplevin)
#### Post date: [December 9, 2022, 7:59pm UTC](https://dask.discourse.group/t/best-practice-for-shutting-down-a-cluster/1382/1 "2022-12-09T19:59:48Z")
I’ve got a LocalCluster working well except for teardown. I’ve tried a number of functions, including:
- client.close()
- client.shutdown()
- client.scheduler.shutdown()
- client.retire\_workers()
- doing nothing
But I’ve found no combination that avoids a variety of errors on exit. All the examples I’ve found are interactive ipynb files that don’t ever terminate the cluster. So basic question:
What is the best practice for cleanly terminating a client / cluster?
Thanks.
---
### Author:  [@guillaumeeb](https://dask.discourse.group/u/guillaumeeb)
#### Post date: [January 16, 2023, 2:32pm UTC](https://dask.discourse.group/t/best-practice-for-shutting-down-a-cluster/1382/2 "2023-01-16T14:32:05Z")
Hi @rjplevin,
This is also something that I’ve experienced, and I’ve no good advice. I’d say the better to use is client.shutdown(), but it’s true in some workload you can get random errors… In general, you can safely ignore them, but I agree this isn’t really clean.
---
### Author:  [@byrom771](https://dask.discourse.group/u/byrom771)
#### Post date: [February 16, 2024, 3:00pm UTC](https://dask.discourse.group/t/best-practice-for-shutting-down-a-cluster/1382/3 "2024-02-16T15:00:08Z")
Is there any way to supress these errors or redirect them somewhere else?
I’ve tried:
- Redirecting stderr and stdout before calling client.shutdown();
- Changing the logging.distributed in the dask.config Configuration dictionary to error level;
- Using client.register\_worker\_callbacks() to call a function that silences logging everytime a worker is created.
However, I can’t seem to ever silence the WARNING messages I get when I shutdown the client. I am building an application using Dask and I would like the users to not see these “alarming” messages if they do not have to.
---
### Author:  [@guillaumeeb](https://dask.discourse.group/u/guillaumeeb)
#### Post date: [February 16, 2024, 9:14pm UTC](https://dask.discourse.group/t/best-practice-for-shutting-down-a-cluster/1382/4 "2024-02-16T21:14:23Z")
Hi @byrom771, welcome here!
Could you give us the errors you are seeing?
---
### Author:  [@byrom771](https://dask.discourse.group/u/byrom771)
#### Post date: [March 4, 2024, 6:11pm UTC](https://dask.discourse.group/t/best-practice-for-shutting-down-a-cluster/1382/5 "2024-03-04T18:11:44Z")
Hello @guillaumeeb ,
I am getting messages like this:
2024-03-04 18:02:56,695 - distributed.worker.state\_machine - WARNING - Async instruction for \\> ended with CancelledError
2024-03-04 18:02:59,891 - distributed.nanny - WARNING - Worker process still alive after 3.1999992370605472 seconds, killing
Several of each type, after I try to shutdown my client by doing client.cancel(futures) (where futures is the list of futures I have running) followed by client.shutdown().
So far the only way I have of suppressing these errors is to set the logging level to CRITICAL (with logging.getLogger(‘distributed’).setLevel(logging.CRITICAL)), both in the workers (by using client.register\_worker\_callbacks and calling a function that sets logging level) and in the client process (by simply setting the logging level to CRITICAL before I call client cancel and shutdown).
Is there any way to redirect these logging messages from the distributed logger to a file?
Is it possible to simply remove the console handler and add a file handler to the distributed logger manually? I have tried with no success, maybe I just don’t understand how the Python logging module works.
Should this be done through the dask config instead?
I appreciate the assistance.
---
### Author:  [@guillaumeeb](https://dask.discourse.group/u/guillaumeeb)
#### Post date: [March 6, 2024, 9:35am UTC](https://dask.discourse.group/t/best-practice-for-shutting-down-a-cluster/1382/6 "2024-03-06T09:35:16Z")
Those errors look normal in your case.
If you want to hide them, yes, you should configure logging, this can be done using the dask config: [Debug — Dask documentation](https://docs.dask.org/en/latest/how-to/debug.html#logs).
Do not hesitate to share your configuration if you come up with something, this could help other users.
---
### Author:  [@byrom771](https://dask.discourse.group/u/byrom771)
#### Post date: [March 13, 2024, 5:54pm UTC](https://dask.discourse.group/t/best-practice-for-shutting-down-a-cluster/1382/7 "2024-03-13T17:54:56Z")
I tried creating a config.yaml file in {sys.prefix}/etc/dask/ and calling dask.refresh(), but that didn’t work for certain warnings so in the end I simply did this:
from distributed.utils import silence\_logging\_cmgr
with silence\_logging\_cmgr(logging.CRITICAL):
client.cancel(futures)
client.shutdown()
Which resulted in a sucessful supression of messages below CRITICAL logging level when shutting down the client.