Re: upstart: please update to latest upstream version
On Mon, Feb 27, 2012 at 10:12:07AM -0800, Steve Langasek wrote:
> No disagreement with any of that. But how high is that price, in point of
> fact? If no one's measured it, then converting scripts to C programs to
> avoid the added exec() calls is premature optimization.
If it were just blindly converting shell scripts to C programs, I would agree
that it a premature optimization. What is more important is to provide the
infrastructure to avoid the need of scripting in first place. Like in upstart
where there are handy stanzas like umask, env, nice, limit, and so on.
Eg. taking the systematic approach of seeing what the sysvinit scripts *do* and
then making it possible to express those things declaratively. I nice example
is SystemD's tmpfiles.d. No more need to spagethi-wire scripts to ensure
files and directories exist under /run.
> One of the worst contributors to the use of 'script' in upstart jobs instead
> of 'exec' is the need for backwards-compatibility with pre-upstart
> /etc/default/* files. The options here are all fairly poor:
> - ignore the admin's /etc/default settings when switching init systems
> - migrate any local changes to /etc/default into the upstart job at upgrade
> time, by editing a conffile in a maintainer script
> - keep sourcing /etc/default at runtime
> I guess systemd has largely chosen option 1 (in part because there's a weird
> view in the systemd community that these jobs belong upstream, so Debian
> integration issues are entirely ignored). For many upstart jobs in Ubuntu,
> we've chosen option 3. Which do you think is the right solution? Are there
> other options I haven't seen?
The view is not silly at all (unless you need value-add to sell a distribution).
Only consultants win if daemons are configured in different files in different
distributions.
Generally speaking, the solution is to make daemons configurable by their own
configuration files. /etc/default style shell-scripts that wrangle their
distro-specific configuration format to command line arguments of the said
daemon is not good architecture.
/etc/default needs to be seen as a workaround to the fact that /etc/init.d/* is
shellscripts that dpkg marks as configuration files, not as an critical piece
of "Debian integration" that needs to be preserved.
Looking at ubuntu upstart jobs, this already seems to be case for many jobs:
-snip-
# if you used to set SSHD_OPTS in /etc/default/ssh, you can change the
# 'exec' line here instead
exec /usr/sbin/sshd -D
-snip-
Btw: the pre-start stanza of ssh is an great example of the earlier mentioned
shell-script induced crap (comments added by me).
pre-start script
test -x /usr/sbin/sshd || { stop; exit 0; }
# "exec" stanza already takes care if the daemon happens to be non-executable
test -e /etc/ssh/sshd_not_to_be_run && { stop; exit 0; }
# distro-specific custom method of disabling one specific daemon
test -c /dev/null || { stop; exit 0; }
# without /dev/null you are screwed anyway, why bother checking it here?
mkdir -p -m0755 /var/run/sshd
# tmpfiles.d my friend
end script
Reply to: