I've run into a number of bugs where on upgrade from an older release, the /etc/default files are no longer respected:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/557054 https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/570103 https://bugs.launchpad.net/ubuntu/+source/cron/+bug/486558 Essentially while porting things to upstart, the /etc/default files are being forgotten. Not all packages have forgotten them, but some have. Further, the format and location of these files is an anachronism from before we had upstart. Noted succinctly by Colin Watson here: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/531912/comments/6 We really shouldn't need these separate files because upstart jobs should be extremely simple. So this is only a partial fix: [ -f /etc/default/squid ] && . /etc/default/squid This also has a small effect on the system boot speed by forcing a random seek into /etc/default to read this tiny file. One of the ideas behind upstart was to alleviate these things by pulling all of this information into one place (the job config) which is read entirely in one sweep early in the boot. So I'd like to propose that we convert these values into env lines in upstart scripts upon installation. What I mean is that we should have a policy where upstart jobs define any pre-existing variables from /etc/deafult/foo with the same defaults: So, for instance, in the openssh-server package, we have this in /etc/default/ssh: # Options to pass to sshd SSHD_OPTS= This should become # Options to pass to sshd env SSHD_OPTS= (and the env var added to the exec line) Then the dh_installinit program should add code like this to the maintainer script for upgrades: service=ssh jobfile=/etc/init/$service.conf defaults=/etc/default/$service if [ -f "$defaults" -a -f "$jobfile" ] ; then for i in `awk -F"^env " '/^env / {print $2}' $jobfile` ; do name=`echo $i | cut -d= -f1` val=`echo $i | cut -d= -f2-` setvalue=`sh -c ". $defaults ; echo \\$\$name"` if [ "$setvalue" != "val" ] ; then finalvalue=`echo $setvalue | sed -e 's/,/\,/g'` sed -ie \ "s,^env $name=.*,#converted automatically from $default\, content saved in /var/backups/$service.default-deprecated\nenv $name=$finalvalue," \ $jobfile fi mv $defaults /var/backups/$service.default-deprecated done fi Right now we are breaking on upgrade because people may not remember that they modified /etc/default, and we're not stopping to tell them at any point that we're going to ignore the file. Even if we keep sourcing the file, this is less than ideal as one of the goals of moving a service to upstart should be to simplify its start configuration. This shouldn't count as a policy violation where a maintainer script is editing a conffile, because we're simply folding modifications to /etc/default/foo into /etc/init/foo.conf. They were going to get a conffile warning about /etc/default/foo .. so now they're going to get it about /etc/init/foo.conf, and it will include automatic configuration warnings so they know how it happened. Another less aggressive option would be to just warn the user that the values in /etc/default/foo need to be manually ported forward. I don't know if this warrants a full UDS discussion, but if it is a viable option, I would like to see this started very early in the oneiric cycle, and completed by a2 or at the very least a3. So, does anybody a) think we need a UDS session to discuss this and/or b) want to +1 on this so I can start filing wishlist bugs targetted at oneiric? Also this brings up another question.. where do we actually state our policy differences from Debian policy? -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
