{"action":"created","issue":{"url":"https://api.github.com/repos/systemd/systemd/issues/4239","repository_url":"https://api.github.com/repos/systemd/systemd","labels_url":"https://api.github.com/repos/systemd/systemd/issues/4239/labels{/name}","comments_url":"https://api.github.com/repos/systemd/systemd/issues/4239/comments","events_url":"https://api.github.com/repos/systemd/systemd/issues/4239/events","html_url":"https://github.com/systemd/systemd/issues/4239","id":180006644,"number":4239,"title":"RFE: Track service config files","user":{"login":"purpleidea","id":135091,"avatar_url":"https://avatars.githubusercontent.com/u/135091?v=3","gravatar_id":"","url":"https://api.github.com/users/purpleidea","html_url":"https://github.com/purpleidea","followers_url":"https://api.github.com/users/purpleidea/followers","following_url":"https://api.github.com/users/purpleidea/following{/other_user}","gists_url":"https://api.github.com/users/purpleidea/gists{/gist_id}","starred_url":"https://api.github.com/users/purpleidea/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/purpleidea/subscriptions","organizations_url":"https://api.github.com/users/purpleidea/orgs","repos_url":"https://api.github.com/users/purpleidea/repos","events_url":"https://api.github.com/users/purpleidea/events{/privacy}","received_events_url":"https://api.github.com/users/purpleidea/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-09-29T10:07:19Z","updated_at":"2016-09-30T15:05:54Z","closed_at":null,"body":"### Submission type\r\n\r\n  - [ ] Bug report\r\n  - [X] Request for enhancement (RFE)\r\n\r\nThis is an RFE to extend systemd and the unit file (slightly) to improve the experience for the config management and automation communities.\r\n\r\n### Proposal\r\n\r\n1.) Add a field in the service unit file to declaratively list the config files which the service depends on. This could look something like the following:\r\n\r\n```\r\n[Config]\r\nConfigFile=/etc/foo.conf\r\nConfigDir=/etc/foo.d/\r\nConfigMatch=/etc/foo/*.conf\r\n```\r\n\r\nYou can specify as many of these directives as you'd like. I recommend being able to glob to match simple patterns. These could also all be mixed together under a single directive (eg: `ConfigPath`) if that is decided to be more aesthetically pleasing.\r\n\r\nLennart had mentioned that he would like these to be relative paths, and the absolute prefix (eg: /etc/) be passed in by systemd. This variant doesn't negatively impact this proposal in any way and is up to the systemd core team on which they prefer.\r\n\r\n2.) Provide an API to specifically get the last reloaded time of the service in particular. Currently it's possible to get `ExecMainStartTimestamp`, but not `ExecMainReloadTimestamp`. This would be an easy addition to the API.\r\n\r\n### Advantage to user\r\n\r\nBy combining these two concepts, the `systemctl status` command could tell a user if the last modified time of any of the listed config files is newer than the last modified time of reload and start. If so it's likely that the service needs a reload to be able to use the newest version of the configs and be running in the correct state as seen on disk.\r\n\r\n### Advantage to config management communities\r\n\r\n1.) Currently there's no guaranteed way to detect if a currently running service is in the correct state with respect to the configuration files specified. In particular, if the automation technology updates a configuration file, it will typically then run a reload of the service. However if an error occurs after the file update but before the reload, on a subsequent run, you will loose the information that the service needs reloading!\r\n\r\n2.) With the config file information listed in the service unit file, it will be easy for config management tools to automatically know the dependency relationship between the config file and the service. This means they can know to update the config file before starting or reloading the service. This would make everyone's life easier.\r\n\r\n### Getting these additions into distribution unit files.\r\n\r\nSince this would benefit the sysadmin and devops consumers greatly, and since these types of patches are quite easy to write, even non-programmers using these services will be able to send distribution and upstream patches to add these options. If they are not added, it doesn't hurt the status-quo.\r\n\r\n### More information\r\n\r\nI'll be presenting this information during my talk at [systemd conf](https://cfp.systemd.io/en/systemdconf_2016/public/events/1), during my [`mgmt`](https://github.com/purpleidea/mgmt/) presentation. I will post the video link once it is available.\r\n\r\nThank you for your consideration!"},"comment":{"url":"https://api.github.com/repos/systemd/systemd/issues/comments/250768797","html_url":"https://github.com/systemd/systemd/issues/4239#issuecomment-250768797","issue_url":"https://api.github.com/repos/systemd/systemd/issues/4239","id":250768797,"user":{"login":"johannbg","id":1309070,"avatar_url":"https://avatars.githubusercontent.com/u/1309070?v=3","gravatar_id":"","url":"https://api.github.com/users/johannbg","html_url":"https://github.com/johannbg","followers_url":"https://api.github.com/users/johannbg/followers","following_url":"https://api.github.com/users/johannbg/following{/other_user}","gists_url":"https://api.github.com/users/johannbg/gists{/gist_id}","starred_url":"https://api.github.com/users/johannbg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/johannbg/subscriptions","organizations_url":"https://api.github.com/users/johannbg/orgs","repos_url":"https://api.github.com/users/johannbg/repos","events_url":"https://api.github.com/users/johannbg/events{/privacy}","received_events_url":"https://api.github.com/users/johannbg/received_events","type":"User","site_admin":false},"created_at":"2016-09-30T15:05:54Z","updated_at":"2016-09-30T15:05:54Z","body":"@purpleidea well I would say systemd is not that one that should determine or tell anyone or anything it should be restarted let alone if an file changes in the server(s) but it should tell previous and current state of services etc . \r\n\r\nThe complex logic configuration management and associated triggers should reside entirely in the centralized configuration management system ( as well as monitoring systems etc alot of those systemd share similarity in what they do )\r\n\r\nIf you are managing machines in the thousands and containers in the hundreds of thousands you want a) have centralized configuration management in which the administrators logs in, configures the initial state of the machine(s) as in tells it how it should be partitioned, networked, which components is installed and what services should be running. ( create an template ) \r\n\r\nb) you want to manage the configuration of all those machine in that configuration management system and be able to associate these configuration profiles it to any given template and services within that template ( so you don't end up having to configure it per machine/containers and services on that machine/container as you are proposing in 1 ) \r\n\r\nc) you need to be able to keep track on the changes creation of the configuration(s) and template associated with each machine/container or cluster of containers as in who created/changed, what ( template/configuration ) when and why and what version these templates and configurations are in. \r\n\r\nd)  you want to be able to push and rollback configurations on the machine or container or cluster of machines or containers ( compare the checksum of the configuration file in the configuration management system with what has been deployed in the machine the, container or cluster of machines or containers). \r\n\r\nIf the configuration ( or even web applications or databases etc ) has been successfully deployed on the machine, the container or the cluster of machines or containers then start/reload/restart the service(s) ( or rollback encase the checksum does not match on those file(s) and do nothing as not start/reload/restart the service(s) ) or do so as a schedule task as in you might push all configuration changes to the machine(s)/container(s) during normal working hours but want to schedule start/restart/reload the services after hours or when ever the service you provide can be least disruptive to your customer base ( and that might mean one cluster in Germany and another cluster in Australia two different timezone which means two different schedule task to start/reload/restart the service(s)  ) all of which would be managed in the configuration management.\r\n\r\nThe above is roughly the scope of any modern configuration management system and as such you can view what systemd is lacking in that context as in what dbus interface or api are missing or should be extended to be to support configuration management system ( your number 2 ) but not try to act as one ( as your request 1 is doing which would undoubtedly be followed by some requesting the often requested of turning systemd into syntax checker for configuration files for poorly written daemon/services so it could prevent restarting services with broken configuration  )  "}}
{"actor":{"display_login":"johannbg"}}