Michal Sekletar e266c068b5 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
2017-04-11 09:22:25 +02:00
2017-02-21 18:21:13 +01:00
2017-02-21 18:18:24 +01:00
2017-04-04 08:47:30 +02:00
2017-04-04 12:08:46 +02:00
2015-08-31 18:12:37 +02:00
2017-03-01 11:21:29 -05:00
2015-06-03 00:22:53 +02:00
2016-10-06 11:53:58 -04:00
2017-02-28 17:22:14 +01:00

systemd - System and Service Manager

Count of open issues over time Count of open pull requests over time Build Status
Coverity Scan Status

Details

General information about systemd can be found in the systemd Wiki.

Information about build requirements are provided in the README file.

Consult our NEWS file for information about what's new in the most recent systemd versions.

Please see the HACKING file for information how to hack on systemd and test your modifications.

Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.

When preparing patches for systemd, please follow our Coding Style Guidelines.

If you are looking for support, please contact our mailing list or join our IRC channel.

S
Description
systemd patched fork
Readme
409 MiB
Languages
C 88.5%
Shell 5.7%
Python 4.6%
Meson 1.1%