Bug#727708: tech-ctte: Decide which init system to default to in Debian.
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 - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: