On 10/31/2013 02:50 AM, Theodore Ts'o wrote: > 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).
Ted, I'm sorry, but it's very obvious you have no clue how systemd is supposed to be used. First of all, systemd - like udevd - supports two places where to place systemd service files. One is located below /usr/lib/systemd which is the directory where service files provided by the package are placed, and one is /etc/systemd where your own, custom service files are located. If systemd finds an appropriate service file in /etc/systemd it will ignore the appropriate service file in /usr/lib/systemd, always. So there is never a problem with service files being overwritten during an upgrade like you describe. The same holds true, btw, for udevd with it's rules files which are located in /lib/udev/rules.d and /etc/rules.d respectively. And everything that you might want change in the configuration of a service can be done by editing the service file and this in a much easier and consistent way. Editing a file in the .ini file format is a no-brainer which, in the worst mistake case, will probably lead to an error message from the daemon or systemd while messed up custom code may end up rendering your whole system unusable if you are smart enough to mess up an rm command. Just have a look at this wonderful bug in upstart [1]. > 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. No, System V Init scripts are not ideal on the long-term outcome since they are highly distribution-specific, error-prone and annoying to maintain. We have had tons of bugs in the bug tracker because of broken init scripts, like this one [2]. I don't understand why anyone would think that having to write a small piece of code to start another program is a sensible and good design, especially when this is done for dozens of programs (= daemons) in very much the same way. It absolutely makes sense to encode the logic to start and control a daemon through a single piece of C code rather than writing more-or-less the same bash script for every single daemon on your machine. Adrian > [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177 > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668890 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
