Theodore Ts'o <ty...@mit.edu> writes: > On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
>> I suspect you and I have a root disagreement over the utility of >> exposing some of those degrees of freedom to every init script author, >> but if you have some more specific examples of policy that you wanted >> to change but couldn't, I'd be interested in examples. > It's not necessarily the init script author who might want the degrees > of freedom, but the local system administrator. > The most basic is the idea that whether you can control (via shell > scrpit fragments) whether or not a service should start at all, and what > options or environments should be enabled by pasing some file. The fact > that we can put that sort of thing in configuration files such as > /etc/default/*, for example. > Yes, yes, you can do this via if you use system V init scripts scripts > in backwards compatibility mode, but you've argued that we should be > moving briskly away from that. In which case system administrators will > need to hand-edit the services files by hand, which will no doubt > increase the chances of conflicts at package upgrade time, compared to > if the configuration options were isolated away in files such as > /etc/default/rsync (for example). Ah, I see. However, I do think this is mostly a solvable problem. We should provide meaningful flexibility in our init script configuration, which may include providing hooks so that local administrators have a place to put that local policy. You're right that some of this functionality will probably be lost in the initial conversion to something other than init scripts, but I would consider that to (usually) be a bug, and as people report problems, we can be sure it's added back in after understanding the issues involved. Yes, this may be a bit annoying for people in the short term, but I do think it gets us to a better place in the long run by way of supporting clean and documented interfaces for those policy settings. It is true that currently init scripts are full-blown programs, allowing anyone who is capable of programming in that language to make arbitrary policy modifications. We lose that by switching to a higher-level language, and only policy decisions anticipated by that language will be easily implemented. More complex policy decisions would have to be handled at a higher level, via selectively creating or removing the configuration files. It's certainly a disruptive change. I'm not convinced it's a net negative, but it will depend on how strong the available hooks are and what types of policy the local administrator wants to easily change. I do think that being able to treat the init scripts as real configuration files will make maintaining such local policy easier than it is currently. The prospect of modifying init scripts was already dire enough that we pushed most meaningful configuration into /etc/default instead of asking that people change the complicated init scripts and then handle merges on package upgrades. *Most* local changes are fairly simple, and would only require small and mergable changes to upstart configuration files, and small overrides to systemd files. I personally like upstart's model a little better, but systemd's model of /etc overrides /lib is, I think, workable as long as people remember to change only the setting they want and then include the original instead of making copies of the whole configuration. (That being said, I'm worried about how the systemd model handles the common case of wanting to change the command-line arguments to a daemon, and then having the package also change the command-line arguments in some orthogonal way.) > If the package does not ship a SysV init script (which is your ideal > long-term outcome), that may not be very practical option for a system > adminsitrator who may need to recreate a SysV init script, especially if > the service file is rather complicated, or is using some of the more > advanced feature of systemd/upstart. You can do quite a bit with the hooks that are part of the specification of both types of files. For example, logic that you may add to control whether the service should start at all can be implemented by adding a pre-start stanza to the upstart configuration. This particular action appears to be harder to do in systemd, which doesn't, at least from the documentation that I've found, support running arbitrary shell code to determine whether to start a unit, but there are a bunch of other possible built-in checks. I suppose one could also change the command started to wrap it and put the check there, although that feels quite ugly. In general, upstart's integration with arbitrary actions in shell fragments is considerably better than systemd's, at least based on the documentation I've read. upstart feels like it provides more useful flexibility. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
