Going to have to agree with James Howe here. What workflow is Core targeting by even offering "Take this node offline" if it just comes back 30 seconds later?

If the node has an issue causing all builds executed on it to fail, then I need to take it offline, so apparently this means I have to update its availability option and then take it offline? I could save a step by just updating the availability to use a schedule which is never available, which then prompts the question, why is there even a button to take offline in the first place if it doesn't really take it offline?

Running into the same issue. I need to set dedicated slaves offline for certain reasons and the should not come back online until an admin performs the corresponding action. 

Can we re-open this issue? I'm seeing the same problem and it's a really bad one, when I'm trying to block agents from getting jobs because of JENKINS-53810, I try to take the agents offline, and they try to reconnect soon after, which leaves me in a state of draining my queue by sending jobs to vms that aren't actually connected, which results in 100s of job failures.

+1. This is a bug, not a feature. If you click a button to disable a node, then a reasonable person would expect the node to stay disabled.  

This is a bug, not a feature. I want to keep my agent online as much as possible, so jobs don't have to wait even 1 minute before Jenkins considers that it should be connected. I also want to perform maintenance on the agent that requires no connection at all. For example, to change jenkins user ID, which  requires no process running under said user, including SSH connection from Jenkins master.

As much as I hate the word "obvious", because what is obvious for one is not necessary the same for the other... Obviously if I disconnect something, I expect it to stay disconnected.