5 ms·

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 ess

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.

pjc50 11y ago
I'm hearing "we need to build a version control system or a transactional database into our init daemon" here :)
- bad_user 11y ago
  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
  - efaref 11y ago
    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.
    - bad_user 11y ago
      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).
    - pjc50 11y ago
      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)
      - bad_user 11y ago
        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.
- efaref 11y ago
  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.

pjc50 11y ago

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

bad_user 11y ago
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
- efaref 11y ago
  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.
  - bad_user 11y ago
    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).
  - pjc50 11y ago
    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)
    - bad_user 11y ago
      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.
efaref 11y ago
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.