So I have not yet had to use systemd in any serious way, so I may be misinterpreting here, but I think this:

> ... and config/daemon reloading as things that could be made automatic, I'm assuming with e.g. inotify change events.

is a misinterpretation of the author's complaint. It sounds like with systemd, if you tell it to restart a service it will continue to use the old definition until you run a separate command to 'reload' it (and, presumably, all other configurations). On top of that, it indicates its knowledge that you've changed the file by telling you to run the aforementioned reload command.

No inotify seems to be involved in what he wants, which is that the reload command use the new configuration. Hell, be clever and use the old configuration's stop mechanism and the new one's start mechanism or complain if the restart mechanism differs or something, but a message telling you you didn't do something you almost always want to do is a pretty obvious smell for a UI problem.

I deeply dislike the similar behaviour of upstart, fwiw. In order to reload an upstart init script you have to stop and start it, restart uses the old one. I have spent annoying amounts of time wondering why it was doing it wrong.

Because systemd is event-driven, you can't actually be sure the service file won't be re-used in the running configuration - or that it won't trigger other service reloads/starts/stops due to its dependency specifications. Ergo systemd requires an explicit reload to commit the state of the unit files once you're satisfied they are as intended.

This is very important when you consider that unit files can kill other units on their conditions - I've used this feature in particular to make sure nginx goes down if a mountpoint becomes unavailable or the servicing process dies (and systemd can't restart it). This is extremely useful because it means a load balancer won't send requests to a webserver in an improper state. But it also means that while editing those config files, I wouldn't want systemd auto-reloading everytime I saved.

And in the end i will gladly trade a few seconds longer boot for a system i can actually reason about rather than treat as some kind of black box voodoo. The latter is why i moved away from Windows in the first place.

It's definitely more then a few seconds (systemd boots fast), but more importantly reasoning about unit files is a lot easier then reasoning about the init-script ordering.

With a unit file I can just declare the conditions under which it should run or stop. If the system doesn't achieve those conditions, then I can solve that problem - rather then having my unit run before the system is ready to do so.

You're not really reasoning about your system because you can say "this runs after this" if you don't also express all the dependencies and failure conditions.

Aren't you confused with Upstart, which is event-driven? Systemd is mostly goal-driven (e.g. on startup it will start default.target, which involves recursively starting its dependencies).

You can also add 'crontab -e' and much other examples of commands that wrap an editor call already exising in linux userspace.

What I think your getting at is that essentially you need a mechanism to commit your changes before the thing that's reading those changes receives them. In essence, an atomic operation for the change. Completely agree.

I'm hearing "we need to build a version control system or a transactional database into our init daemon" here :)

Version control systems and transactional databases are built over atomic operations. Transactions in particular refer to having multiple operations that either succeed or fail all at once, making in essence atomic operations composable (they normally aren't).

Editing a file and saving it multiple times is not an atomic operation, but reading a file can be, so having the user issue a reload command only after he's finished editing a file is an entirely reasonable approach that has been used in Linux since forever and it only shares some basic building blocks with version control or transactions, but there's nothing fancy about the approach. Fancy and very error-prone would be to apply configuration changes automatically, which is what the article seems to suggest.

In other words the joke is lame :-P

Reading a file is not even atomic - you can race with concurrent writes.

The only safe way to update a config file of a running service is with POSIX atomic rename, and most editors don't do that by default.

If only the operating system maintained a tree-structured key-value configuration store with atomic updates, like the Windows registry.

(Even I'm not sure if this is sarcasm any more)

The Windows Registry is a dump on disk of some half-assed structures defined in a memory heap, poorly specified, being in essence a file-system as well. Also, only individual operations have been atomic and one update in the Windows Registry does not equal one update of an entire configuration file on Linux. Transactional support has been added, but late and interactions with it are still problematic. The Internet is filled with complaints and pieces of advice on corrupted registries.

And it is being obsoleted, with the elephant in the room being that the Windows Registry needs to be thread-safe because it's a central store of all settings and this was a really bad idea. I'll also have my nginx.conf over a registry entries file any day of the week.

That's true, that's why I said that it "can be". And if you have a special edit command, like "systemctl edit", then it can take care of the details for you, which is I presume the reason for its existence (much like visudo).

I assume the next version of systemd will include git.

Actually, it's not that bad an idea:

    cd /home/efaref/config/servername
    vim blahd.service
    git commit -m "Update blahd service file to increase widget count"
    git push live master

Then have something else watching the master branch of the live repo do a git pull, systemctl daemon-reload. It doesn't even have to live on the same server. If one of the config files is a puppet script, you can maintain everything.