/etc/default/X and upstart jobs

[Stephan Adig]

Hi Clint,

On Wed, 2011-03-16 at 09:21 -0700, Clint Byrum wrote:

> Even if you take out the speed of boot argument, we still have the issue
> where this data is in a separate file and doesn't necessarily need to
> be.

This depends ;)

Having a closer look at what some files in /etc/default are doing, I
think we need to make a difference.

Taking your sshd example, this default file will take some "startup"
options for the ssh service daemon.

Taking my tomcat6 example, there is a difference.

First, tomcat6 is not a "standalone" service daemon.
It's started via authbind and inside a headless jvm.

So having the /etc/default/tomcat6 examples, we do make configurations
of the JVM. There are no "startup" configurations for authbind (those
would belong to /etc/default/authbind, no?) 

Therefore, IMHO, we need to have a look at the purpose of those files
in /etc/default/.

While I was looking at it, I asked myself, if some of the files
in /etc/default are really necessary, or should we move them into some
other location.

Back to your sshd example, after startup of sshd, sshd
reads /etc/ssh/sshd_config for a proper configuration of the sshd
service.

Back to my tomcat6 example, in /etc/default/tomcat6 there should be only
a 'TOMCAT6_START_ON_BOOT="yes"' only option, and not the configuration
of the JVM or other parts of the tomcat6 needed stack.
The configuration of the JVM itself needs to move to another location,
which is then read after the decision was made (in sysv or upstart job)
to start tomcat6 or not.

So, what I say is, that we should first find out what the  the purpose
of the files in /etc/default/ are.
I think a lot of those files are to define the startup mode, which can
be moved into the correspondent upstart job, while others do have the
purpose of not only defining the startup mode, but also configure the
behaviour of the to be started service daemon.

Differences to the services included. Back to sshd, when it's started by
upstart it will go to /etc/ssh and read sshd_config, which is not read
entirely at startup when upstart wants to handle the job. 

So even when we move most of the /etc/default/<service daemon name>
options into upstart job config files, we always have another piece
which needs to be read from somewhere different then /etc/init.

 
> [...]
> Yeah, my hacky example code would probably choke on this. That doesn't
> mean we can't make a more robust converter that does handle all cases
> well, since we're only dealing with shell variables.

That I took already for granted :) 

regards,

\sh

-- 
Stephan '\sh' Adig
SysAdmin / Ubuntu Developer
xmpp: sh at sourcecode.de