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: [email protected] -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
