service: serialize information about currently executing command

Stored information will help us to resume execution after the
daemon-reload.

This commit implements following scheme,

* On serialization:
  - we count rank of the currently executing command
  - we store command type, its rank and command line arguments

* On deserialization:
  - configuration is parsed and loaded
  - we deserialize stored data, command type, rank and arguments
  - we look at the given rank in the list and if command there has same
    arguments then we restore execution at that point
  - otherwise we search respective command list and we look for command
    that has the same arguments
  - if both methods fail we do not do not resume execution at all

To better illustrate how does above scheme works, please consider
following cases (<<< denotes position where we resume execution after reload)

; Original unit file
[Service]
ExecStart=/bin/true <<<
ExecStart=/bin/false

; Swapped commands
; Second command is not going to be executed
[Service]
ExecStart=/bin/false
ExecStart=/bin/true <<<

; Commands added before
; Same commands are problematic and execution could be restarted at wrong place
[Service]
ExecStart=/bin/foo
ExecStart=/bin/bar
ExecStart=/bin/true <<<
ExecStart=/bin/false

; Commands added after
; Same commands are not an issue in this case
[Service]
ExecStart=/bin/true <<<
ExecStart=/bin/false
ExecStart=/bin/foo
ExecStart=/bin/bar

; New commands interleaved with old commands
; Some new commands will be executed while others won't
ExecStart=/bin/foo
ExecStart=/bin/true <<<
ExecStart=/bin/bar
ExecStart=/bin/false

As you can see, above scheme has some drawbacks. However, in most
cases (we assume that in most common case unit file command list is not
changed while some other command is running for the same unit) it
should cause that systemd does the right thing, which is restoring
execution exactly at the point we were before daemon-reload.

Fixes #518

0 files changed, 0 insertions, 0 deletions