3

In his article RESTful Casuistry, Tim Bray claims that rebooting a server is not idempotent:

But I don’t buy it, and here’s why. If I want to update some fields in an existing resource, I’m inclined to think about PUT. But that doesn’t work because it’s supposed to be idempotent, and rebooting a server sure isn’t. Well, OK, do it with POST I guess; no biggie.

Yet in comments Mike Kelly states that it is:

The problem I see here is that ’switching’ to reboot does, infact, seem like an idempotent action - the idea being that a ‘rebooting’ state would actually be a graceful shutdown, to an off state, and back to an on state immediately. Once this rebooting state was initiated any further updates to the rebooting state would be idempotent:

PUT /vm/test-machine/power

{ ’state’: ‘rebooting’ }

The definition of idempotence is given in RFC 7231, § 4.2.2. ‘Idempotent Methods’:

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request.

Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.

The intended effect in our situation is that the server has been rebooted. I think this will be the case after both a single or multiple reboot requests. So I am inclined to agree with Mike Kelly that rebooting a server is idempotent. But I don’t share his view that it is because subsequent reboot requests received during the rebooting phase have no effect; to me it is because subsequent reboot requests after the rebooting phase produce the same effect. Nor do I share his view that the PUT method should be used for this since the intended effect of the PUT method is to create or update the state of the target resource with the state defined by the representation enclosed in the request, reducing server reboot to a side effect.

Is rebooting a server idempotent or not?

7

The problem here is that Tim Bray doesn't explain why he thinks it's not idempotent. The concept of idempotency is somewhat subjective. When we call a PUT twice there are a number of things that aren't the same as when we call it once. For example, the server access logs will be different as well as other logging. There might be other side effects to the PUT call as well such as events that are generated. But we explicitly choose to ignore certain factors.

In a containerized, cloud-based solution (which was not really a thing in 2009), is restarting a container idempotent? Probably but if it's holding a local in-memory data that is not persisted anywhere, no, it's not. There are too many factors here to say it's always one or the other. Perhaps his point is that it's not, in general, the case that rebooting a server is idempotent. That doesn't mean it can't be, just that you can't assume it is.

9
  • Not to mention the case of these operating systems that install new patches at every reboot, the network address that might change on some interfaces, defragmentation that could have altered places of data on the disk, etc... :-)
    – Christophe
    Jun 10 at 21:59
  • 1
    @Christophe Yes those are all potential changes. But some of them might be ignorable such as disk fragmentation. It's also likely that if you restart the machine twice in a short period of time, the state of patching after each reboot is the same. So if your goal is to ensure patches are applied, rebooting twice e.g. in the same hour would be idempotent for that purpose.
    – JimmyJames
    Jun 10 at 22:11
  • 1
    I have just emailed Tim Bray and he confirms that the reason why he considers that rebooting a machine is not idempotent is because he includes the modification of the machine state as part of the intended effect, not as part of the side effect. So multiple machine reboots will not have the same intended effect as a single one.
    – Maggyero
    Jun 24 at 23:20
  • 1
    @Maggyero Interesting. That's not how I tend to think about servers that run my stateless applications though. Servers are restarted because patches were applied or because there wasn't enough load to need it until later, or because it's scheduled to restart every night. The state of the server is completely irrelevant to the application (as long as it's working, of course.) I have a hard time even considering that a side effect. It's like repaving a road. It's just maintenance. I don't even really care if it's the same host at any given moment.
    – JimmyJames
    Jun 25 at 13:43
  • 1
    @Maggyero I don't know if you want to reply back but I'm a little confused now that I think about it. Imdempotency doesn't mean no state changes, it just means the same update results in the same state. Let's say you were working in a datacenter and your boss told you to restart a server and later on, they ask if you did it but you can't remember. Can you restart it again without concern? The answer to that is what determines idempotency.
    – JimmyJames
    Jun 25 at 14:35
-1

After the server has rebooted, it isn't in state rebooting anymore, so another reboot action isn't really idempotent in the sense of leaving the resource in the desired state if it is already in that state.

One (admittedly contrived) solution would be to have a resource rebootCount that you'd change to cause a reboot. If the server has been booted 10 times, you PUT 11 into it to get it to reboot and into the "rebooted 11 times" state. If another request also puts 11 into that resource it's idempotent, it doesn't cause an additional reboot but leaves the server in that state.

2
  • 3
    It doesn't really make a lot of sense to say that we desire the server 'be rebooting'. Rebooting is (expected to be) a transitional state. If I want to make sure a machine has been rebooted, I reboot it 2 times because I never got confirmation of the first attempt, is the resulting state different than if I rebooted just once? That's the question, at least as the OP sees it.
    – JimmyJames
    Jun 9 at 19:48
  • @JimmyJames Exactly. Hans-Martin Mosner’s answer is interesting because it seems that Mike Kelly actually used that same transitional state as the intended effect of a reboot request, but during the reboot rather than after like Hans-Martin Mosner, to conclude that rebooting is idempotent! So we agree that both arguments based on transitional state are incorrect.
    – Maggyero
    Jun 9 at 22:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.