Re: Init system deba{te|cle}
On Sun, 3 Nov 2013 14:33:27 +0000
Jonathan Dowland <jmtd@debian.org> wrote:
> On Sun, Nov 03, 2013 at 10:23:02AM +0100, Marko Randjelovic wrote:
> > I find shell scripts the most efficient way to automate system adin
> > tasks. It could be because I am a programmer, but at least init
> > scripts are already provided, and small modifications should not be a
> > problem even for non-programmers. For new scripts you have 'skeleton'
> > file that can be easily adjusted for a particular work.
>
> Amongst other problems, how do you (or the package system) reconcile
> when you have made a local modification to an init script and the
> upstream package has made another in an update?
It depends, but if you could do it then I don't see why couldn't you do
anything that is needed later. Besides, configuration files can also
change, just like init scripts. A don't have a feeling that
upstart/systemd configuration is so simple (not so much about syntax,
I was looking at their documentation and there are things such as
'events' and such things have to be properly defined), so it can
also make problems, not just change in init scripts.
> > There is nothing more standard/portable in Unix-like systems then
> > POSIX shell.
>
> …which wasn't fully supported on Solaris 9 so you had to use a subset
> (e.g. no $(subshell) syntax). Writing truly portable shell scripts
> across multiple UNIX families was a terrible pain and one could not
> simply rely on the POSIX feature-set. I know this from bitter
> experience.
>
> I suspect C89 is/was more portable in practice, but the point OP is
> making here isn't the scripting language, for portability, it's the fact
> init scripts do little to abstract the differences between OSes, so
> portable init scripts are very hard to achieve. E.g. Debian uses
> /etc/default for overrides, Redhat-esque systems use various schemes
> under /etc/sysconfig;
We are talking about Debian init system. init scripts do not need to
support Red Hat because they are on systemd and Solaris is not a
Linux distro and it's not realistic to expect scripts could be
portable between Debian and Solaris.
> various init scripts are written with the
> assumption sh → bash which required a lot of fixing up when Debian and
> Ubuntu moved to a different default sh; and on and on.
We already moved to a different default shell.
> Such OS layout specifics being baked into init scripts also make it much
> harder to make changes, since you break a load of init scripts when the
> assumptions they rely on change.
It's because scripts are not correctly done. All scripts that use the
same resource should not reference that resource directly, but instead
by a common function. That way, when resource location change, you need
to change only relevant function. We could just correct such errors,
and make other corrections/improvements/enhancements instead of
going into vendor lock-in.
If Debian wants to take care about it's init scripts, I would
really be motivated to be involved. That's why I am not sure
makers of alternative init systems really very much care about users'
real benefit. They could add additional features as additional
software, not replacement software. Or they could work to improve
existing sysvinit. E.g. they could extend start-stop-daemon to return
only when service is ready, or if timeout exceeds to return with error
status. I'm sure it would be much simpler than making all that. I
primarily mean about systemd and upstart, I didn't have enough time to
learn about OpenRC, but at first glance it looks to me significantly
better. If it's development continues in good direction, Debian could
take OpenRC as replacement for sysvinit, so the worst mistake would be
if we now, without enough vision about eventual consequences, take
systemd or upstart as default init system.
> This is why it's not just systemd that is trying to replace shell
> scripts: nearly all the next-gen init systems do (launchd, upstart,
> openrc… even smf with its XML).
>
> > I do not see 'start daemons when they are first used' is quite an
> > important benefit and start in parallel is already supported by
> > sysvinit (startpar).
>
> Some people like socket activation a lot (which is why inetd was used
> to achieve this in the past)
Then it's again a lack of feature in server software (lack of initd
support), and not init system.
> > I don't think UNIX philosophy is not so important. First of all, the
> > principle of all-might is by nature authoritarian. All-in-one
> > "solutions" are a characteristic of big companies that want to impress
> > their users, while not giving them enough real benefit.
>
> It's a principle near and dear to much of the rest of our F/OSS stack,
> however. The Linux kernel is monolithic (and enormous) rather than
> a microkernel. GLibc is enormous rather than a family of smaller
> libraries. And so on.
I agree with it, but it's because people choose to join existing
projects instead of to start a new one. We are lacking entrepreneur
spirit :) .
--
http://mr.flossdaily.org
Reply to: